On the value of open source
One of the more interesting parts of my career as a software developer has been the realisation that I, you, and vast chunks of the world…
One of the more interesting parts of my career as a software developer has been the realisation that I, you, and vast chunks of the world are in the privileged position that we are thanks to the kindness of strangers.
This line of thinking was brought to the forebear of my mind with the following tweet:
Matt, at the time of writing the “head of the developer ecosystem” for Adobe has recently stumbled into the lives of myself and my colleagues following Adobes acquisition of the eCommerce framework in which we specialise, Magento. Finding myself at a loss to unpack the magic of open source in the 280 characters that twitter allots, I feel it’s worth unpicking this topic in a little more depth.
Solving the same problems many times over
Invariably as part of our work lives we’re destined to solve the same problems many times over. It is how we’re able to best leverage our skills, to develop some speciality and exploit efficiencies and insights that we gain through the course of our employment for higher relative rates over time.
Unfortunately within the IT sector, and particularly within the development of software itself there is still a significant skills shortage. Try as we might, there is not enough developers to help articulate the complex and mutable business requirements that we have into software, which puts a premium on those who do. This means that we, as software developers are always desperately searching for gains in efficiency.
Perhaps the largest gift to us in developing software is “Open Source”. Google defines it as:
denoting software for which the original source code is made freely available and may be redistributed and modified.
however, it is not quite all that captures the magic for me of open source. Instead, I would offer another definition:
Solving problems collaboratively and expressing the solutions as software, made freely available to be redistributed and modified.
Or simply, giving our hard work away for free. Intuitively, as a business owner (or indeed, as a software engineer) giving away hard work seems quite insane. However, because of the vastness of the talent pool open source offers (literally the entire world) and the dramatic gains in efficiency using open source software can give us, it makes sense to both consume and collaborate on solving problems as a community. Practically speaking, these problem will be solved regardless — it behoves us to be a part of developing the solution.
Low cost of entry
Perhaps the simplest reason to invest in open source is its extremely low price point — free. For an engineer, open source is the fastest, easiest and often most effective way of prototyping a solution.
Consider the example of eCommerce; I can create and deploy a fully functional eCommerce system (Magento) in about ~5–10 minutes. It is free, well supported by the community and will likely continue to work for many years to come. This ability to quickly and cheaply prototype allows businesses to trial ideas in a fairly complete way before investing significant capital.
For businesses it may not be such a simple tradeoff as they must retain and maintain the engineering teams, but I am still confident open source is a good solution.
Following along from the low cost of entry is the ease in which it’s possible to take open source software and customise it for your own use. Indeed, I specialise in taking the (mostly) open source application Magento and modifying it to suit a particular business case.
In my time as a developer I have worked in perhaps 20 stores trading millions of dollars worth of goods. The modifications have occasionally been quite extreme, ripping out and replacing large chunks of the stores in question — but all based on the same fundamental technology.
Collaborative solutions to similar problems
Nice though it would be to think ourselves special and our work a unique art that cannot be replaced, I have found practically that most problems have already at least one good solution (and, more often, many good solutions).
Consider the example of managing servers. A notoriously complex, arcane art of ensuring software compatibility made dramatically simpler with the use of new packaging technologies espoused by Docker.
An extremely high total of hours has been poured into Docker and the surrounding technologies by talented engineers — people to whom the vast majority of the market normally has no access. Their work, solutions and justifications are all online — free.
Lastly, and perhaps most excitingly of all those engineers are all supremely generous with their time. They painstakingly document their work, provide open design proposals for solution and will happily discuss bugs or features that you’d like to contribute to the project.
Standard, inter-operable solutions
Perhaps most excitingly of all, open source paves the way for inter-operable solutions.
There are occasionally idea that are so compelling they cause us to fundamentally reevaluate our approach to solving problems. However, often these ideas are implemented in a specific way — making some assumptions that the author needed to make for brevity, time, or simply because they didn’t feel the need to examine them further.
Given these new ideas others may take and present their own views of this problem, modifying them slightly to suit another use case. In these cases, projects may get together and establish what are the common understandings that both projects can benefit from, and provide a mechanism for other applications to consume each of those projects in a transparent way — without needing to implement a given project.
Over time, these abstractions become more complete and new projects will build on top of those intero-perable components. This story repeats from all the way down to the Linux kernel to the web components that are starting to appear to extend the HTML that makes up web pages itself, and many layers in between.
Such inter-operability even further lowers the cost of solving issues, often by orders of magnitude. Such standards are rarely implemented by closed source providers due to a lack of incentives to work with competing services.
Whether to use open source technologies is a complex question, though I hope I’ve at least encouraged you to take a look. However, the open source collaborative model is fundamental to our software infrastructure, and it has been proven a viable approach many times over. I strongly encourage your engineers to consider collaborating on their solutions instead of attempting to monopolise some particular problem.
There really is enough work to go around.