How to Support Our Smalltime Software Developers - THE KOOTMARKET 3

[KootK]

TLDR

I believe that the future of structural engineering software is this spit:

a) Some big dog(s) create general purpose FEM engines that are I/O accessible in standardized ways by external, 3rd party applications.

b) A bunch of small dogs create 3rd party applications that access the exposed architecture of the FEM engines and use that output to deal with the design of individual elements. etc.[/quote]

That said, I see problems with how we manage the transition from where we're at now to such a future. The purpose of this thread is twofold:

c) I've proposed a potential solution that I'd like to discuss / vet. The diagram at the bottom summarizes that.

d) I'd like to open the floor to other proposals that may be better than my own.

THE BACKGROUND

It is common knowledge that I have a long standing interest in being a developer of structural software: Kootware.

I occasionally get asked how that is coming along: New Thread.

Other folks, including some of our own MVP's, have begun to do similar things including Celt83's excellent project: StructuralToolbox.

THE STATUS OF KOOTWARE

I haven't done a damn thing with KootWare. I knew that KootWare would be a monumental undertaking so I decided to hang back and try to evaluate the market viability of such a project before diving in. I regret to report that what I've observed to date leads me to believe that a project such as KootWare is not currently viable. Moreover, I feel that similar efforts by other members here are also doomed to fail. Heck, I've seen it happen repeatedly already. The typical lifecycle for these efforts usually goes something like this:

1) Develop a kick ass tool of some sort.
2) Softly advertise the tool on Eng-Tips via an introduction, a signature hyperlink and, often, a dubious request for "beta testing" help.
3) Quickly fade away and die.

THE PROBLEM AS I SEE IT

1) The tools cannot be monetized simply or quickly enough. I don't give a rat's ass what anyone says about "just doing it for the love of programming" etc. I feel that most everyone is either doing this stuff in the hope of making a little spare change off of it or, at the least, requires that spare change in order to be able to keep going. And I begrudge no one their right to some compensation for their efforts. I view all of these things as, effectively, R&D. And all R&D needs funding to succeed. As a community, I feel that is our collective responsibility to find some way to provide such funding if we want the tools to get developed, as I do. We pay small fortunes for our big dog software toys. We can spare some pocket change to feed the little dogs.

2) Simply building the infrastructure to collect payment is a massive undertaking. And the premium structures of canned solutions favor larger scale operations in many cases.

3) Everybody has one tool or a small number of tools to offer. I think that it takes many more tools that this to create a "critical mass" suite of tools that consumers would be willing to pay for.

4) For the most part, application developers are working independently, in vacuums, rather than pooling their knowledge and resources.

5) I feel that it is difficult for engineers to trust small time software solutions. Are they well vetted? Have they been developed by reputable organizations?

6) No one application developer seems to possess enough "presence" to be able to advertise effectively.

MY PROPOSED SOLUTION

As shown in the diagram below, I propose that the small time developers ban together into a federation of sorts in order to accomplish what none of them seems to be able to manage on their own. Developers would contribute applications to the marketplace in a competitive sprit. Whomever has the best steel beam design app would garner the most traffic to their tool and, commensurately, earn the most revenue in the "steel beam design" space. Rinse & reapeat.

 

[WinelandV]

when will we get to the point where the analysis model will include every bar and every bolt. All 3D brick elements with links of all sorts between them. It runs in less than a minute and captures all failure criterions every imagined. Oh and it should produce a nice PDF report at the end of the day too.

And a chicken in every pot! Er.... An iPad pro in each everyone's hands!

All kidding aside, maybe that could happen when we all have today's super-computers in the palm of our hands.

KootK,

I can't really speak from the development side, as I'm syntax deficient in pretty much all the languages being bandied about. However, I can add the perspective of a engineer at a company that has 40-50 employees spread out over 5 (maybe 6?) state offices.

My "branch" is in the ag/industrial field, predominately - think grain, bins, support structures, coops, PEMBs, ethanol plants, and the like. We pretty much uses RISA programs -> 3D, Foundation, and Connection. The company pays for all the licenses associated with these programs, so the cost isn't a concern to me (this means that I understand that the cost is a concern to others).

Far be it from me to tell someone to not make the FEM program of their dreams, but, as anyone who's followed RISA's own release notes knows, there's a long way from "we can accurately analyze your stick model" to "Hey, we added bending to single angle design checks!"

So... for those developing the tools, are you going to try to create your own FEM program for analysis and design? Are you looking to interface with their output files (for say, a stiffened seated connection, which I'm 80% sure that neither RAMConn or RISAConn handles [yet[)? Or is each tool going to require the user (me) to do a full input of geometry and loads every time I use it?

On the documentation side, since these are web-based, do I just get a print-off of the results? Do I get to save the file on the cloud, or even locally?

I anticipate that your answer to most of these questions will be "it's up to the tool developer". And that's fine. It's just food for thought. Just thought I'd put this out here as I like the idea of what you're proposing, but didn't want the piece of "will others that aren't developers drop in and use the tools?"

I didn't mean to ramble on. tl;dr-> Developing is hard, and getting people to use your program is also hard.

Please note that is a "v" (as in Violin) not a "y".

 

[skeletron]

Definitely Rabbit Hole Territory, but I love it. I am a rare young dinosaur that doesn't do programming beyond an excel spreadsheet, which is unfortunate because it also means I don't run/use a lot of the little tools kicking around (re: python or others via GitHub). It's on my list of things to do, but realistically my practice area is so small that it is mainly a personal growth item on the list not a practice-necessary item.

Here is my input as a user:
1a. I kind of forget to bookmark all the individual web-app type sites, so having (1) list/site/portal would improve my use.
1b. Similar to AISC's steelTools.org is helpful to lure me in.
1c. I really @#$@ing can't stand having to pay for more software/subscription/etc. but also realize that it's probably a necessary thing to get developers over the hump and also the tools in a position to actually be usable. Make the payment process easy and straightforward: I'm in. Make the payment process tiered or in some way cause me to evaluate whether I need to be a Bronze, Silver, Gold subscribed-user: I'm less likely to be in.

2a. Beyond a few established developers (e.g. Alex Tomanovich spreadsheets) or really niche, but checkable, calculations (ie. instantaneous center of rotation), I'm still leery of random downloadable programs as a final design tool.
2b. This is why I don't believe anonymity (whether in the developer or the checker) is beneficial.
2c. This may also be why simplified tools (see: calcs.app) are quite useful. They do one thing, they present it, that's it.
2d. Documentation, worked examples, and checking/verification make it all better for the more complex stuff. Sometimes this can also be substituted for really good graphical representation (see: StructuralToolbox bi-linear interpolation).

3. It would be interesting to know what the best way to start would be. I could see one website with a list of links to tools being a nearly cost-free method to at least start the gathering process. Measure traffic, gather feedback, see slow momentum, allow organization of the developers/checkers in the background.

 

[WinelandV]

FYI, for all the aspiring programmers, over at humble bundle (

http://www.humblebundle.com)

there is a bundle where you can get 27 books on the python language for $25. I have no idea if the books are any good, but thought I'd make mention of it.

Please note that is a "v" (as in Violin) not a "y".

 

[squir999]

I am absolutely zero help from a programming perspective...but I can describe website behavior maybe.

I wonder if the marketplace could be set up like an e-commerce catalog of sorts, with each tool having a page and a price (and thus, categories and subcategories and associations with tags/keywords therefore searchable). I believe Paypal doesn't charge fees for payments under $10 or something which would help the small payments both add up and be effective for hobby programmers. Background--I worked for an e-commerce SaaS website provider for 4 years as a client manager, project manager and eventually the Director of Project Management. So like, instead of searching for "wiper blades 2017 STI" on a Subaru dealer's parts website, I search for, "Steel Column biaxial bending torsion" on the Kootware homepage and all "pages" (aka calculators) that match those keywords show up. Then I click one and it allows me to preview it but not enter anything (repeat for as many as I want to preview; maybe even allow me to see a sample calculation PDF as a "related file"--the ecommerce website for parts has related files for installation and sometimes fitment lists, diagrams etc) then when I get to one I want to try, I pay some small fee ($2-5?) which I am now willing to pay since I saw the sample file document/output and a real world example problem (that I can do back of envelope calcs for if I so choose to verify quickly). I don't know how you, on the back end, get the right $$ to the right developer but it's probably easy using a database and the webpage address.

Site addresses for pages could look something like: kootware.com/structural/steel/ASD/Colum/Squir999AxialLoading

In theory everyone's tools should be able to pull from the same database of sections and materials so that no one is having to recreate that within their tool. I remember when I was in college many years ago AISC had an excel version of every single steel shape and it was awesome--and would be easy to stick in a database.

We would probably have to agree on languages, or somehow make it such that any language could spit out the right things to a SQL or some other database to display correctly on the screen and when printed. But idk if that statement even makes sense because like I said I am NOT a programmer. I just manage projects. And do structural engineering. Ha.

 

[Trenno]

Has the KootMarket already lost it's steam?

 

[TLHS]

The below kind of wandered off in a random direction.

I don't know. Honestly, the hobbyist/part time/whatever structural engineering software as an income stream is tricky and for me I don't think it's really the logistics.

Value either comes from automating computationally intensive things, or providing information in a way that's easier to use. The problem is that the former is hard to do in a generalist sense that is verifiable, and it isn't approachable to develop as an individual. The latter is scary because you are making a black box for people.

There are very few things where you've can necessarily say there's a right answer, and those things tend to have tools.

I can make a tool to determine seismic anchorage for vertical stacks or tanks that's better than anything I've seen out there, but what do I do with that?

1. Do what the existing products do, and use a conservative value for things like anchorage neutral axis and anchorage failure mechanisms?

This isn't helpful to people who know what they're doing, isn't necessarily better than what's out there, and will likely just end up being uses that don't know what it means because the people who are experienced will do it different ways. But if people don't know what it means, will they be able to use it safely?

2. Provide more aggressive options with commentary

This starts getting complicated because you have to figure out how to bake your own judgement into the software. How do you make it so people aren't blindly doing dumb stuff? I don't actually know. You still likely have unknowledgeable people using it.

3. Just make it a calculator with references to all the sources and don't tell people when they should use the different bits

This seems terrifying

Every small thing I look at, I end up hitting this problem.

As a personal project, I started making something that could take the mapped environmental values from the NBCC and spit out contour maps of the different values and maybe giving values for specific locations. There's lots of times you're doing work in rural Canada and have no inputs in the code. Environment Canada takes forever to provide data and it isn't practical all the time. I started wondering if this was something I could make a website of. But I know how it would work. Even if I understood all the limitations I should put on it, people are just going to use it. I know lots of engineers who would just happily grab design info from an unknown website and you can't make it universally conservative. This is why the code committees don't do those maps any more.

It'd be super useful for preliminary studies, but nobody's paying for this information, and if they did the liability on it would be more than the potential income would be worth.

As an individual, I don't understand how I'd ever feeling okay widely distribute anything that isn't just an implementation of a well documented procedure, or a code procedure.

If I could somehow guarantee that the people using things would understand the context of my work, it'd be different.

Maybe this is just me, but the understanding that engineering problems are often very specific and context sensitive makes it really hard to figure out how to provide tools that will be used for generalized projects outside of my control.

How do you 'finish' this type of thing so you're comfortable releasing it generally.

Now take this and multiply it by a hundred if you're looking at a single supplier of tools from multiple sources. Is the website responsible for verifying accuracy, usability and documentation. If you're providing web interfaces, I think it's pretty hard to act like you aren't the supplier of the service.