A couple of weeks ago I ended up here and it occurred to me that for the last year or so I had published posts ranging from WSO2 product related how to’s(what this site was initially supposed to be about), linux how to’s that bordered on immaturity to opinionated tech event reviews from my local community. This thought led to me changing the blog’s name to "The FOSS Merchant".
FOSS stands for Free Open Source Software, think Apache(no, not this guy[1]) and Ubuntu. “Free” in in this context mean something closer to “free speech” than “free beer”. Exercise your linguistic demons here, if you must[2]. Since “FOSS Merchant” sounds like an oxymoron, I thought I should write a few words on the matter.
…..
Open Source Software, as it’s name suggests is free to be used and worked on by anyone. Meaning, most open source software projects are maintained by a community spanning organizations and geographical boundaries. This facet of open source software makes it more sensitive to industry demands and needs, it makes it evolve faster. In brief, organizations that tap into this quality of open source could, in turn, use it to increase their technological agility.
The days when open source software was considered a plaything for the geeky and not a contender for the professional is far behind us. At present 1 in 3 servers[2] powering the internet is run on Linux and the number keeps rising every year. In fact one survey found Linux to be preferred by 78% of participants(including some fortune 500 companies) for their cloud-based endeavors[3], this figure makes sense considering the popularity of server crafting tools such as docker and the extended support it provides to Linux. Furthermore, there are plenty of examples of product companies that have successfully worked open source into their business models, from Red Hat estimated to be worth 14 billion USD, Oracle’s acquisition of MySQL at 1 billion USD, last week’s news of MuleSoft’s 100 million IPO to WSO2’s 11 year track record of providing leading middleware solutions and driving digital transformation[3] for organizations.
A common accusation made against FOSS is that it is not as polished or as user friendly as it’s closed source counterpart. Although this is true on occasion it is my personal opinion that this characteristic of open source software attracts the kind of engineer that end up having a bigger say in technological decisions at ground level, thus they drive organizational changes in terms of technology in the long run(common sense dictates its better to ride this wave than to expend energy redirecting it). This hypothesis is backed by some empirical evidence. In one survey done by The Linux Foundation[4] 52.7% participants cited in house expertise as a key driver for OSS adoption. In another study done on the adoption and transition from closed to open source software, based on the Technology Acceptance Model(an information theory dealing with technology adoption) found a negative correlation between the perceived ease of use and adoption of OSS in the public sector[5]. It is also easy to assume this hypothesis, as one of the factors for the phenomenal success of GIT version control system, when one takes into account the fact that it was considerably different(conceptually and in usage) from other version control systems of the time and was often accused of not being user friendly.
Other than the agility and ground level traction that can be expected by selecting OSS(as discussed in preceding paragraphs), organizations may also take comfort in knowing they have complete access to the code base of the software they are procuring, this may not even be an option with some proprietary vendors. This disclosure coupled with in house expertise on the code base which can be cultivated, in time can amount to technological independence and assurance for the organization.
However, OSS posses its own novel set of concerns which organizations should address before making the transition. As most open source projects are maintained by volunteers, they lack documentation and other knowledge resources which organizations need to make informed decisions on suitability. Tailoring the software to exact organizational needs and maintenance afterwards may prove to be difficult, as expertise on the software cannot be readily accessed. As this is the case for many open source projects, it is of paramount importance that organizations select a commercial OSS vendor/partner that can bring in value by addressing these concerns. Furthermore, commercial OSS vendor/partner’s more often than not provide useful features that cannot be found in the original projects.
