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.

 

[ChorasDen]

While a fun idea I suppose, I think you are aware that there is a lot of work required to get to this point. Couple things off the top of my head.

1) Who builds/maintains the backend (kootmart interface)?
2) If this truly is a group of small developers under one umbrella, how do you determine who has the best software that then gets distributed, what are the metrics? Correct output, time of computation, reporting to user and cleanliness of output? Some combination of this and more?
3) What language and interface is standard? I predominately write in .NET languages, but I see a lot of people on here like python, what happens when each developer is using a different language?
4) What if one of the developers wants out, do they take their source code and application with it, or is it all baked into kootmart through some sort of sellers agreement?

The advantage I see here is the validation stages, multiple individuals testing new/improved software can be beneficial to establish issues with design edge cases and any bugs that might develop.

 

[KootK]

@ChorasDen: thanks for your comments. My personal answers to your question are shown below. Really, these would be issues that would need to be resolved collectively by the members of the federation.

1) Who builds/maintains the backend (kootmart interface)?

At the risk of being trite, whoever decides to. That could be:

1) The federation itself, taking it on collectively.

2) Somebody getting paid for the undertaking.

3) Somebody excited about the potential for eventually getting paid for the undertaking.

As I see it, any individual developer wanting to make a go of it will have to create something similar. And therein lies the problem. So why not aggregate the boring shit?

2) If this truly is a group of small developers under one umbrella, how do you determine who has the best software that then gets distributed, what are the metrics?

All of the software gets distributed, even if it's redundant, unless there is a reason to seriously doubt the validity of the results of a particular application. Developers earn revenue based on the number of times their application gets used by a paying customer. The end. This is meant to be a survival of the fittest kind of thing specifically designed to encourage the evolution of the best tools and discourage stagnation.

3) What language and interface is standard? I predominately write in .NET languages, but I see a lot of people on here like python, what happens when each developer is using a different language?

Flexibility rules. At the extreme ends of it:

1) If one wants to make use of the pre-developed templates etc, they use the languages in which those templates were deveoped.

2) If one wants to go rogue, they develop with whatever stack they wish and their stuff becomes, effectively, a site within a site. So long as usage can be tracked somehow, the system still works in my opinion.

3) What if one of the developers wants out, do they take their source code and application with it, or is it all baked into kootmart through some sort of sellers agreement?

If someone wants out, they take their stuff and run. Nobody is required to share anything that they deem proprietary unless the spirit of collaboration motivates them to do so.

 

[ChorasDen]

Thanks for making this post. I think these ideas are fun to discuss and to get a feel for what 'could work', even if nothing ever does become of it. With that said, I hope that this does indeed go somewhere.

Developers earn revenue based on the number of times their application gets used by a paying customer.

Sounds like you still have the thought of KookWare in your head, where each application is actually a hosted webpage, where the developers have significant control, and it's easy to track site visits. Using myself as an example, I prefer to develop desktop apps, and thus, the concept of "number of times application gets used by a paying customer" seems a bit nebulous. Sure, there's easy ways to determine how many times a program is opened and phone that back home, but not sure such telemetry makes sense, and if I were purchasing the software, I wouldn't necessarily want to see such a feature.

I do like your thoughts here, but I think to be successful, it would probably need a bit more structure and control, not sure if it's user friendly to have a wild west marketplace where who knows what you'll find?

 

[driftLimiter]

I envision perhaps a bit more collaboration between individual developers. I know personally that If I was able to learn some of the basics of UI and UX that several of you guys have already discovered then I could easily start pitching in. I love writing programs but I have never taken the deep dive into packaging it up into something that is useful for others. This could provide some cohesion to the softwares being delivered in language used, the style of input/output. I know that it sort of breaks with the idea of a network of small individual developers but I think some teamwork might be necessary to offer a set of complete solutions.

I am really glad you guys are talking about this and TBH I'd love to collaborate with someone if they ever need a hand (mostly because I want to learn your ways).

 

[KootK]

Using myself as an example, I prefer to develop desktop apps...

Yeah, I pretty much see the KootMarket applying only to apps that are delivered as web apps. I agree, trying to incorporate desktop software would be a nightmare.

...not sure if it's user friendly to have a wild west marketplace where who knows what you'll find?

In my opinion, we already have a wild west marketplace. One that's mostly dysfunctional as I mentioned at the top. The only question in my mind is how we're going to steer & improve that towards something more satisfactory and conducive to the success of smalltime developers. I get that some engineers probably won't ever trust software created by small time devleopers.

 

[phamENG]

not sure if it's user friendly to have a wild west marketplace where who knows what you'll find?

I think that's a good point. While I like the free flow of ideas we have here on eng-tips, and in an abstract way I'm all for the freedom of the marketplace, when it comes to productivity apps I not only want to know what, why, and how it's doing, I want it to at least do what I want it to be doing.

Maybe the marketplace could be structured based on topics - analysis (with sub groups for seismic analysis, wind analysis, snow loading, etc.), wood design, steel design, etc. Obviously many will straddle the boundaries, but selecting tags and ranking them (like Steam does for game devs) helps with sorting and finding the right tool when you need it.

Interoperability is another important factor with these sorts of setups. Now maybe this isn't where you're going with it (though I think it should be, otherwise you're just curating a slightly different/better steelTOOLS). So while allowing partner devs to post what they want, pushing a core template that provides some sort of native API for each app to communicate will be key. That way I can run a wind analysis once, and then call it up in my steel portal frame design app, my wood shear wall app, my roof framing planner, etc.

 

[phamENG]

I get that some engineers probably won't ever trust software created by small time devleopers.

I don't think this matters as much here. For some, sure. But for most, it'll be a question of trusting the KootMarket. I'm sure it's more prevalent in our community since our livelihoods tend to hang in the balance when considering the validity of a piece of analysis software, but generally people don't know who developed any given piece of software. They might know the company, or maybe they know the publisher, but apart from the original Easter Eggs and people board enough to watch credits or dig into documentations, who knows who wrote the code? But for us it's not who wrote the code that matters. It's the rigor, scope, and accuracy of the validation results. And if that's part of the community, then it's the community that has to be trusted.

 

[Celt83]

Sounds like your suggesting something of a mix between Twitch (the business model not the means of content delivery) and BuyMeACoffee / Patreon in so much as KootMarket would perhaps do some mild curation of the content and send you to the respective tool. The Buy Me A Coffee and Patreon models are interesting in that they allow for monthly subscriptions but don't provide any marketing.




I'm making a thing:

http://www.thestructuraltoolbox.com

(It's no Kootware and it will probably break but it's alive!)

 

[KootK]

They might know the company, or maybe they know the publisher, but apart from the original Easter Eggs and people board enough to watch credits or dig into documentations, who knows who wrote the code?

I was always referring to the corporate entity that sponsored the development rather than the individual developers that did the coding themselves. And it's difficult to discuss this honestly without admitting the truth as I see it: almost nobody does any meaningful checking of the software that they use. In that context, I myself feel much better relying on Bentley's products than Celt's products. I'd like to see that change, however, and that's part of why I feel that some kind of collective effort in the validation dimension might help with consumer trust issues. I think this is pretty much what ChorasDen was getting at in his original post.

So while allowing partner devs to post what they want, pushing a core template that provides some sort of native API for each app to communicate will be key. That way I can run a wind analysis once, and then call it up in my steel portal frame design app, my wood shear wall app, my roof framing planner, etc.

I agree. Kootware was always intended to be, and may yet be, built upon a database system and comprised of a suite of tools that work together. And I could still do that even if none of the other KootMarket developers got on board with the interoperability. Naturally, I expect that market forces would tend to encourage cooperation on the interoperability front. Therein lies much of the power of something that functions as I would intend for it to: as a true marketplace, not a monolithic corporate entity.

Your comment has been very valuable to me in that I now see that accidentally left out something very important that I'll revise.

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.

I feel that setup also would help with trust issues. Imagine a scenario where:

1) I really trust RAM's FEM engine so I use that for analysis.

2) I really trust Celt's tool for the design of slender columns with can talk to RAM's FEM engine. Maybe I've validated Celt's thing in the past or, more likely, I just trust him in spades.

3) Because of this setup, I have the option to use Celt's slender column app with RAM's FEM engine if I like. Moreover, if I want to switch to SAP for my FEM, I can take Celt's app with me and not have to vet something new.

 

[KootK]

...in so much as KootMarket would perhaps do some mild curation of the content and send you to the respective tool.

I've been imagining something like this:

1) Baring serious, known deficiencies, folks accessing the KootMarket would have access to anything that contributors elected to share. The only curation would be the culling of software known to have serious issues. The KootMarket wouldn't send anybody anything. Everyone would have to browse the market and shop for themselves. Alternately, perhaps it would be best to have some, minimal, bar for quality that must be met by each applicatoin.

2) Whether or not a particular developer wanted to participate in a communal validation exercise would be at their discretion. It would be optional.

3) If a particular developer chose to avail themselves of communal validation -- which would not be free -- they would use this in the advertising for their tools. "The KootMarket validated the output of this using four independent reviewers who studied 32 different design examples. Those design example can be found [here]. Here are the code updates that resulted."

4) The validation work might even be part of the marketplace. If I ran four validation examples for CeltWare, perhaps that could earn me credits that I could then use to have my own tools validated by AtkinsWare. Some thought would need to be given to maintaining independence and professional integrity with that setup of course.

 

[sticksandtriangles]

Getting the right person to build/oversee this site will be critical.
I built my website to expand my coding hobby and a place to throw up some my rants/ideas for the internet enjoy.

I've sunk more time into the site than I would like to admit and I am still at the amateur level of full stack development. Taking on a site like KootMarket would be a big undertaking.

2) Simply building the infrastructure to collect payment is a massive undertaking.

From my research, I do not think this is too big of a task. I think I could relatively quickly get a payment infrastructure up and running for my site (seems like every youtube video I watch is how to get an e-commerce site up and running). The main task is setting up the backend and tracking free-users, paid-users etc.

I propose that the small time developers ban together into a federation of sorts in order to accomplish

I envision perhaps a bit more collaboration between individual developers.

I would be down to help out if this gets pulled together. I would enjoy working through deployment hell with others rather than having to consult my dog for sanity .

One thing that I have learned from making the website, simply getting the code up and running locally is usually 1/4 of my battle. The majority of the work is pushing the code and dependencies up to the hosting platform. Coordinating this with multiple developers sounds even more painful, but I guess software companies do this all the time.

All in all, I am doubtful there is a huge market/bucket of gold for these one off tools. It's fun to code up these tools, but I doubt we will be quitting our day jobs anytime soon.

S&T -

http://www.re-tug.com

 

[Craig_H]

I fully respect the goals and virtues of what you are proposing. I'd really love to have the final product at my fingertips, too. I can't help feel like I've seen this before... Queue the "autonomous collective" scene from Monty Python and the Holy Grail. You'll need a formal structure to handle governing the "Kootmarket", some system to deal with the inevitable spamming (recall the account from Greece a year or so ago?), some sort of judicial system to decide if a tool is really flawed enough and it needs to be culled (and not just built by someone who I carry a grudge about), some sort of auditing process so that my software gizmo isn't buying KootK a mansion on Lake Windermere, and oh boy so many other things that make my stomach turn just thinking of them.

By all means go for it! I do think that it's a monumental undertaking and that the upfront costs may be substantially larger than just setting up the same as a "one person shop". That all being said, it's easy to be critical. I would love to be proven wrong.

 

[Lomarandil]

Let me slightly reframe the central problems for small calculation programs, as I see them
[ol 1]
[li]Marketing/Recognition/Critical Mass[/li]
I've spent a large part of my engineering career collecting a library of well-developed and documented calculation tools. As a "jack-of-all-trades" structural engineer, that's a large part of my value proposition to a team/employer (and I suspect the same for many of our self-selected ET cadre) -- I can connect the current problem to this method or this article, draw the appropriate analogy or assumption, and come up with a good enough approximate solution quickly.

Twelve years in, and I still find hidden repositories of information or nifty tools somewhat regularly. The variety of our work, the breadth of the internet, engineers being generally poor at self-promotion -- for whatever reason, there are many obscure but deeply useful tools out there. (Not counting the hundreds or thousands of partially finished online steel beam calculators).

At the risk of the universal standards paradox, this is one of the most promising benefits of a collective marketplace, once it reaches maturity. Otherwise niche tools which would be doomed to internet obscurity can have their time in the sun. And small developers get the chance to gain some recognition -- which I see as a primary tier motivation. Engineers and academics widely revere the great names like Terzaghi and Freyssinet, but it seems practicing engineers tend to put nearly as much respect behind SK Ghosh and Alex T, even though their contributions would never make it into a world history book.

While I've ranked this as the first problem, the factors below have to be solved before there is any real chance to solve this one.

[li]UI/Ease of Use[/li]
Structural engineers are an efficient (also read: lazy) bunch. That's why we're programming and automating things in the first place. Worse, we're a judgemental bunch -- each with our own conventions and preferences. So if a tool is not presented intuitively (!?) and in a manner that meets the project needs -- we're just as happy to whip together our own version, even if that is a one-off messy calc that would be difficult to hand to another engineer or package into a submittal. (And let's face it, a lot of the problems our tools solve are not inherently that difficult).

Having a standardized internal (API) and external (style/formatting) convention is a critical part of solving this. We'll never come up with a solution that is intuitive to everyone (although having group validation will help) -- so it will be important to develop a consistent system that is easy to learn over one or two tools, with return on investment when applied across the marketplace suite.

[ol a]
[li]Quality of Output[/li]
A subset of this is providing quality output -- whether that is output that is directly read (PDF reporting), directly input into other modules/software (API) or easily post-processed by the user (csv/Excel friendly).

Where calculation tools can reasonably be paired with parametric (or even generic) details to be dropped into drawing sets -- ah, that's the dream.

[/ol]


[li]Validation/Trust[/li]
Whether or not any actual validation is occurring at the large software developers (or as appears to be more commonly occurring, some are relying on their user base to sniff out bugs), trust is a huge issue. Much like security, it's a little bit of theater, honestly. For better or worse, put together a reasonably organized and visually attractive calculation package, where at least a few of the results line up with a basic rules-of-thumb or simplified FBDs, and you're most of the way there. I'd love to see the "WhiteBox" concept fully applied, but that takes a huge amount of effort to implement (maybe easier through handcalcs/Jupyter/readthedocs?), and I wonder whether users care that much.

Limitations and assumptions simply must be listed, exhaustively. No way around that.

I think that a robust validation/approval stamp could be a huge differentiator in this space. If each tool carried a light version of a StructurePoint design example plus the approval of 4-5 registered practicing engineers (anonymized?) behind it... I think even skeptical engineers would find that equal or superior to a big brand name.

Unfortunately, I think that items 2 & 3 require some gatekeeping, not necessarily Koot's free market utopia solution. Maybe opt-in could work... but I share some of the concerns about spam/quality/etc affecting the brand strength.

[li]Monetization & Sustainability[/li]
I agree with KootK's point that software is R&D, and that R&D needs funding to succeed. Some of us are actually crazy enough to do it out of personal interest or "love of coding" -- how much further would we go if the time spent was financially sustainable? If we put Celt, Medeek, Agent and IDS together in a room for three months, what could they come up with?

While coming up with a monetization model is a tough nut to crack, I agree with some of the others that the payment implementation may not be as onerous as suggested. I do think that rather than protecting the IP strictly (which may be a task for Sisyphus), a shareware/buy-me-a-coffee model may be much more achievable. That also potentially takes some bite out of needing "critical mass" on a 'software suite', at least at the beginning.
[/ol]


Competitors and Differentiation
Below are a list of competing providers (of which I'm aware), and their relative strengths

Tedds/ClearCalcs/RisaCalc
+ Financial and marketing backing of the big boys
? Validation (at least through the user base?)
? Critical mass of (useful) calculations -- many seem they could be programmed by fresh university grads?
- Quality of UI (in my opinion/experience)
- Expensive (relatively)

SteelTools/Engineer's Edge/etc
+ Have "critical mass" of unique content
+ Yields name recognition for marketing
- Validation/trust questionable
- Monetization and sustainability not apparent

Benevolent Contributors (AlexT, IDS, etc)
+ Quality of UI
+ Reputation for trustworthiness
- Marketing/critical mass
- Sustained by their goodwill

 

[Celt83]

The conversation has me remembering an old xkcd comic.

Found it: Link

I'm making a thing:

http://www.thestructuraltoolbox.com

(It's no Kootware and it will probably break but it's alive!)

 

[KootK]

All in all, I am doubtful there is a huge market/bucket of gold for these one off tools.

I also do not think that there is a bucket of gold available to reward the developers of one off tools. I'm inclined to think of the setup more as an incubator of sorts.

Some plausible outcomes that I envision include:

1) Maybe Celt contributes a single app and monetizes it. In terms of the time that he invests in that project and it's ROI, it will almost certainly remain a money loser forever. That said, in my opinion, finding a way to make some amount of money off of that one app puts Celt light years ahead of where he was when he made no money off of it at all. A little thing called... hope.

2) Maybe Celt contributes five apps to the marketplace that are successful. He doesn't buy a new boat or quit his day job but, at the least, it represents enough revenue that he's able to justify spending evening/weekend time on future app development that he might otherwise spend more wisely with his family. Passive future income can be a pretty great thing, even when the remuneration is modest. In effect, this is the R&D funding that I mentioned at the top.

3) Maybe five years from now, Celt finds that he has twenty apps in the market place and all of them are kicking ass. At that time, perhaps Celt decides to pull his stuff out of the market place, create an independent offering, and do his best to offer a meaningful alternative to Enercalc or RAM Elements. Now it's time to buy the boat and consider partial retirement from the day job. And, under this scenario, it would be my hope that the KootMarket would celebrate Celt's exit from the system because that would be indicative that Celt had been successful within the system. And that's the name of the game. Catch, incubate, release.

4) More than anything, I feel that it would be great to simply have a space where one could upload a new app to test it's market viability. Build your tool, add it to the hive, and let the KootMarket do the rest with respect to advertising, payment collection etc. If the thing takes off, invest more of your personal resources in it. It it flops, find something more rewarding to do. If this infrastructure existed right now, KootWare probably would too in some fashion.

 

[KootK]

...some sort of auditing process so that my software gizmo isn't buying KootK a mansion on Lake Windermere...

Mmm... Lake Windermere. It would be Moyie for me if I could swing it.

Some options with respect to your concern.

1) Ideally, I'd like to see the KootMarket be developed by the same group of developers that would eventually use it as an incubator. In this instance, we might set it up non-profit, run at cost +/-

2) Ideally, we'd write into the constitution of the thing that the accounting be transparent. This way, individual developers would retain some sense of whether or not they'd be better off on their own.

3) Since developers would be free to cut an run when it suits them, they would simply cut and run as soon as they determined that it would be in their best, fiscal interest to do so.

As I mentioned at the top, I don't really want to be the douchey overseer of the thing. Rather, I want to be the hipster developer that makes the apps. However, without a douchey overseer to make the marketplace, I fear that I'll never actually have the opportunity to be the hipster developer. And that sucks.

 

[ggcdn]

It's an interesting idea. I mostly agree with Koot's outlook on the future of SE software. I don't see monolith web-based tools taking off in the FEM space or unseating ETABS et al. You just cant get around the fact that a modern FEM takes tremendous computing resources. But web-based tools are pretty neat for element design and quick calcs.

I'm not sure if this federated solution is better than just joining forces with some interested folks and creating a startup. The federation idea has parallels to open-source software, where anyone (in theory) can make contributions, but with the added complication that you now need to somehow track their contributions against others and proportion the rewards fairly, as well as not rely too heavily on their contribution lest they decide to leave. And like open-source contributions, there will be a big range of quality from contributors, and it will require significant effort to review, comment on, approve, and facilitate those contributions. Open source projects often evolve into a core group of maintainers doing the vast majority of the work.

TL;DR - In my mind, the fundamental question to ask is this: Does the increased utility from outsider contributions outweigh the increased effort in facilitating those contributions?

Some examples of the effort I'm referring to:
- creating all the documentation and prerequisite code (ie the marketplace) to accept contributions.
- reviewing, approving, and maintaining contributions.
- enforcing styling guidelines
- legal / licensing / IP rights.
- handling payment to contributors.
- handling disputes, governance of the marketplace
- chasing down contributors to fix bugs, adjust to new codes, etc.

If you found a good group of partners for a startup, you could instead divert a lot of that effort into building the product and adding your own tools, verifications, marketing etc, rather than curating contributions. I think that curation would be vital to the marketplace product success, because as a paying user you have expectations for quality, consistency between modules, trust in the results, etc. In fact, a lot of the problems Koot identified in the original post could also be solved by just partnering up. But for one reason or another, those partnerships are so rare and difficult to form. I've tried a few times and they often fizzle out or fail to launch.

The tools cannot be monetized simply or quickly enough.

I cant deny it would be attractive to be able to plug your calc module into an already established system with paying customers, if such a thing existed. But the same issue applies to the marketplace entity as for any individual company. Need paying customers to attract toolmakers, but need tools to attract paying customers. Setting up infrastructure for user accounts and payment processing isn't that big of a deal anymore, but it still is an effort that every developer has to repeat for their products. So getting rid of that would be nice. To be clear, if such a marketplace existed, I would probably be using it as a developer.

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.

There is some savings here, but also more complication due to having to pay a lot more people as well. Perhaps I'm cavalier about it but I estimate I could wire up basic user accounts and paid subscription options in a couple weekend work sessions if I really had to.

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.

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

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?

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

Also solved by partnering up.



-JA
try [link calcs.app]Calcs.app[/url] and let me know what you think

 

[Trenno]

What you propose sounds similar to the Food4Rhino environment. You can see how many people have upvoted and downloaded each app etc. There are currently 105 Structural Engineering tagged apps.

I've been wanting to create a thread recently and vent my frustration and my belief that when the big software houses expose their API on their software they are then putting onus of genuine development, progress and innovation onto the poor old structural engineers who know a thing or two about writing code. When's the last time a new ETABS feature has pleasantly surprised you? Why should we (the sort of people who would contribute to KootMarket) be the ones to pick up the slack and carry the burden?

On the topic of the future of structural software - 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 ever imagined. Oh and it should produce a nice PDF report at the end of the day too.

 

[NorthCivil]

Just dropping my 2¢ here.

My business would be so severely disrupted if SMath stopped working one day.

Like it used to be disrupted, every time I bought a new computer, and I had to buy the latest mathcad, but none of the previous versions sheets would function in the next version. If it wasn't for that silly lack of portability, PTC would still be raking in tons of my money.

Just reminded now, I need to make another donation to the SMath team