Why Open Source Wins in the Long Run
Let's start with a fictional piece of software. Let's call it GooberJunk.
There's a dedicated group of computer science students who spend a really long time working on this because they feel like the established software in the space is no longer innovating, and they have ideas.
After some period of time, GooberJunk is released to the world. Some folks notice that it has this one feature that nothing else has. The kids sell the crap out of it, and get some sales, and quickly realize that GooberJunk isn't quite ready for Prime Time. So they quickly patch in a few much needed features, and the quick turnaround gets them some goodwill.
GooberJunk has a successful launch. Their web-page gets a recognizable company name on their Our Customers section.
The team is working hard, but they have a business that didn't fall on its face at launch (as most software does). Because they are young and willing to do whatever changes needed to support the customer's needs, they are getting a good reputation. They have come to the realization that they are being put into enterprise spaces, but they don't have the resiliancy or feature-set that is needed outside of "it works on my computer."
By whatever mechanism, someone in tech media notices the software and decides to write it up. Reaching out to some customers, there's a story around this great feature that nothing else has. As tech media does, within a few months, there's some blurbs about this software and its future potential in some business magazines.
GooberJunk management, that initial group of developers, realizes that with the expanding sales, they need to really get ahead of the feature requests, and think out the architecture needs of their customers and stablize the product.
So, the company expands, and buckles down. About a year later, they announce a new Enterprise-Ready version. It isn't, not really, but it's closer, and better suited for future growth.
All those reporters that prognosticated future success a year back, are now pitching feature articles to both boost the product (and their own ability to see winners early).
GooberJunk is getting sales, but are also getting complaints. Enterprise ready only goes so far, when dealing with actually big companies.
Now this group is ramping up more, and working directly with customers to improve the product. New customers are still coming in, and old customers .. over time .. stop taking updates once they've found their own use case.
The high point is high. The company is based on this one product, and at a certain point, the software gets really good. That said, most of the big customers that need it, already have it, and maintenance costs won't sustain the size of the org.
As new software sales slow down, layoffs follow. The software is great now, and doesn't need the massive mobilization to make it better, so it makes sense to downsize.
New sales still happen, of course, and new features are still being introduced. However, new features don't break decisions made to support older versions. This means that a customer only needs to upgrade if they want or need a new feature.
Ultimately, casual observers see the company shrinking, and decide that GooberJunk is in trouble.
The Tech Media starts talking about a new startup that will compete in this space, and does things in a new, different, more innovative way. And, that software is being created by a group of college students. Lots of blurbs about success potential.
Seeing these news articles, GooberJunk sales start to dry up. Most likely, the new feature has been added anyway, but nobody takes notice. The software has already been declared dead.
A new cycle of layoffs, and GooberJunk comes to a reflection point.
If GooberJunk management does nothing, the company will simply die, and the software will be lost to time.
If GooberJunk had the foresight (and lack of self-confidence) to do aggressive layoffs on the downturn, they might have become attractive enough to be bought out. Maybe they'll end up in the catalog of a larger compatitor, some private equity group, or a software catalog company like Computer Associates.
Otherwise, they could convert into a maintenance organization. Maintenance organizations, in general, are only taken seriously when the software is also open source. If the change and open sourcing happens at the same time, there may even be a bit of a press boost on the announcement.
If the software isn't open source, then a compatitor will be, and the new innovations from several years ago have become commonplace anyway. When, even a proprietary company is looking for something that fills a need, that company is likely to think of Open Source as a safer bet from the perspective of ongoing support from somewhere.
If never open sourced, the software may "live on", but will never again be taken seriously.
While writing this, I was thinking of computer languages like Java and Perl. I was thinking of once ubiquitous software like WinZip and WinAmp. Along with spun-off software like Netscape=>Mozilla=>Firefox, or StarOffice=>OpenOffice or Interbase=>Firebird.
Mostly, my inspiration for writing this is watching the current state of hybrid corporate/open source projects in the Infrastructure Management spaces. I've recently been told that Puppet is dead, while in my view, Puppet is finally viable for actual corporate use. Configs made past, say, version 5 are generally going to work with few changes in the latest version. That wasn't true just a few short years ago. So, of course it been labeled dead. The truth is, it's finally done.
Meanwhile, the Press is busy talking about Kubernetes and Ansible.