There never weren’t going to be problems with Open Source software

That doesn’t mean, of course, that Open Source projects are useless — rather, it is an acknowledgement that nothing is perfect.

There was a time when software was, like documentation, a complementary if proprietary add-on to a hardware purchase. Software was free of charge in that its development costs got baked in with the price of the hardware on which the mission-critical software was to run. Those were the early decades of computing, before the term “personal” became a market-expanding prefix and software gained a wider audience for more commodified hardware.

Then the inevitable happened: software also started to become somewhat commodified, as languages and frameworks and libraries and protocols attained their own reputations among developers as de facto standards. There were and are plenty of areas remaining for innovative differentiation and even niche applications/utilities, but the profit margins for software have been approaching zero for businesses that lack a diverse product line of interoperable functionality which extends across vertical or horizontal market boundaries.

Plenty of innovation — during the dawn of personal computing in the 1970s and 1980s as well as during the internet era — has come from developers committed to delivering what is known as freeware or shareware or, more recently, the amalgamated Open Source movement. Disparate Open Source projects hoping to maximize their software’s interoperability with other projects will often turn toward established cross-platform standards as well as middleware products which enable EAI (Enterprise Application Integration) mapping and ETL (Extract/Transform/Load) data compatibility.

Business managers themselves like to extract what they can from this or that Open Source software project, especially if they can get away with not contributing anything back to the codebase (Aleph Infotinuum Services will leave it to the individual to decide whether such tactics lack ethics — AIS comes down on the “no” side with a caveat that Open Source ideals are mostly of the commune-style misguided type whose inherent inefficiencies are easier to hide within virtual marketplaces featuring intangible products).

As with any typical commune, delivering quality products at regularly scheduled intervals proves to be difficult if not impossible. As with any typical commune, the concept of success becomes warped toward feeling rewarded for self sacrifice. As with any typical commune, things get bureaucratic instead of entrepreneurial. Most Open Source projects lack proper incentives, or at least they did until a band aid solution came about in the form of bounties for effort (e.g. for creating new features or hunting down existing bugs).

One big problem with that, and with Open Source in general (and if you’re going to be even more general: with any kind of collectivism), is that developers without defined compensation for defined duties tend to put much more work into creating new features than they put into hunting & fixing bugs. Be sure to follow the link below for more Open Source shortcomings.