Open Source Introspection
Looking back on years of Contribs
Open Source Software has revolutionised how software is viewed in pretty much every industry. No longer is the power concentrated in the hands of large, monolithic, corporate ventures synonymous with expense, intransigence and “innovation stifle”.
Yet, for all the impact OSS has had on the industry, some attitudes to OSS are met with as much resistance as it was the case in the late 1990s. Banking in particular is perhaps rightly concerned about the risks associated with Open Source platforms and worse, the OSS community has done itself little favour by the level of abandonware and poor documentation ubiquitous in the field but somewhat symbolic of the nature of part-time or hobbyist OSS development.
Reflecting on the Rise
I look back on my first foray into the OSS world with the use of Slackware Linux 3.3 in 1998. Back then, Linux was a beast to set up and use. X11 was not as common as it is now and there certainly wasn’t an easy way to configure and use Linux. There was little in the way of setup applications bar a few configuration apps on XTerm. Gathering and handling all dependencies was all manual and it was pretty common to involve yourself heavily in the compilation, modification and recompilation of the Linux Kernel. Whilst this is still common in some arena, Linux very definitely has come a long way form those days.
Yet, it was the work of Richard Stallman (aka RMS) and others, which brought the idea of Free Software and the GNU ethos to the masses. Richard Stallman isn’t someone I have a lot of time for, since his life seems to be a funny form of “blended realities”, yet his role of Software Freedom Fighter is in no way an ignoble cause. The principles of that movement is very definitely laudable and correct, even though his approach isn’t always a substantively useful one.
The rise of Linux to become the world’s most dominant server operating systems brought in its wake an important shift in the minds of those responsible for the development of the software systems the rest of the enterprise concerns itself with. Yet, it also exposed a level of hypocrisy stretching beyond the bounds of IT. We can use PHP but not SpecFlow; use Git, but not Selenium. The arbitrary nature of this moving boundary is symbolic of an organic evolution of an industry wide, disparate mindset between the old, established, classical world and a new world order based on community tendencies.
Largely, enterprises have valid concerns. Yet, as with Cloud and even Brexit, those concerns are blamed and misdirected at the wrong target. A large proportion of the OSS community is better than incumbent developers. They are more used to building quality systems. Yet, with the focus on recruiting through GitHub or StackOverflow now being much higher than before, some individuals of poor repute and skill have contaminated OSS contributions with poor code for short term, recruitment gain. Much of which is abandoned when they have served their purpose. Whatever your view on this approach to their responsibility of live software, intended or not, this gives a bad impression to the intended targets for “conversion” if that is your aim.
Yet OSS isn’t about “converting” people. OSS is naturally about people coming together for a comon cause and to solve common problems. Their investment of time, money, energy and skill happens because they believe passionately in the cause and making the world a better place. Unlike Software-as-a-Salary roles, you can’t buy that personal… personnel… investment.
Fire in Belly, Fire out Mouth
With that investment comes a package of passion. OSS developers are often so invested in the problems and solutions they provide, they are also innocently brutal in their responses. Do not expect that passion to come with a high degree of inhibition. If they think you’re being stupid, they’ll tell you! Can you handle the truth?
However, the question then becomes, would you rather pay for a large corporate group tell you you are right, drag it out for months, even if the solution is wrong, subjecting your project to failure pre and post-deployment, or would you rather someone tell you it straight early? Saving you time, heartache and money? Live to fight another day? Or is that perception of someone to blame worth the extra several million?
E
Like this? Don’t forget to hit-the-heart to share this with others.
