The Risks and Benefits of Open Source

The Risks and Benefits of Open Source

Chris EvansCloud, Code, Enterprise, Open Source, Opinion

In many respects, the open-source movement has been a fantastic success.  However, as we move towards a world where the public cloud dominates, is the current open-source model still fit for purpose or do we need to rethink how free and open software is licensed?

Background

The idea of open-source software goes back decades.  In my early mainframe days in the late 1980s, for example, printed magazines like SHARE were used literally to share code for system utilities and tools.  I spent many hours either typing these programs into an ISPF editor or taking code fragments as examples to learn how to write in assembler and other languages.  The modern equivalent today is to google for examples on Stack Overflow.

Modern open-source development is a collaborative experience that enables developers to work with their peers and create open, freely available software.  From an idealistic perspective, the open-source movement has some of the characteristics of a utopian society, where nothing is owned but instead shared between the community.  Everyone works for the common good, without the capitalist overtones, very much like the societal model presented in TV shows like Star Trek.

Pre-Cloud

In a world before the development of the public cloud, open source, as a development model, clearly offered substantial benefits.  The standard approach has been to share code freely while charging for support or extensions to the open-source base software that provides enterprise-class services.  This latter scenario is a more recent model, where only some of the code is offered through an open model, and the remainder is kept proprietary.

Cloud

The rapid evolution of the public cloud has changed the ground rules for the use of open-source software.  The big public cloud platforms have taken open-source solutions and repurposed them as commercial offerings within a service-based framework.  Most notably, we’ve seen this happen with MongoDB and ElasticSearch, both of which now have AWS forks of their original open-source code.

AWS hasn’t in any way acted illegally, but perhaps morally against the original intentions of the open-source movement.  However, there’s a case to be made that AWS and any other service operator has done nothing wrong at all, legally or morally.

Intentions

To answer my last point, we must ask – why do start-ups adopt the open-source model?  Some will claim an altruistic intention to share and offer their code to the broader community, but in reality, there are some deeper, more commercial drivers.

Writing software can sometimes be a thankless task.  There’s only so much code a single human can write in a day.  Multiply that out by more bodies, and the time taken to develop something meaningful can be reduced rapidly.  That milestone looks even more attractive if investors haven’t been required to pay for all the labour costs.  In addition, freely available code is more likely to be downloaded, tested, further shared, and even developed by the users – if it gains a popular following.  So, for businesses, open source offers cheap development costs and potentially widespread adoption.

For the programmer, there are benefits too.  In recognition of giving free time to a project, a developer could gain industry validation if the project turns out to be successful.  This, in turn, is a path to employment and is in some respects a self-defining CV.  This quirk of our industry has both positive and negative ramifications.  Firstly, the barriers to entry to a career in IT (and specifically software development) are vastly reduced.  However, the risk is that many entrants don’t have the skills to develop code efficiency.  This point is addressed by the process in which updates are developed and accepted into the mainline code, so theoretically, at least, poor programming should see peer rejection. 

Fork in the Road

At the outset of any project, developers choose whether to retain the proprietary model or to take the route towards open source.  The relative benefits and disadvantages are clear.  At the same time, the rise of the public cloud has resulted in public cloud providers like AWS being able to take advantage of essentially free software and use it as a basis for the development of service offerings in areas such as managed databases.

But we could look at the wider market and say that thousands of commercial companies have gained benefits from the unrestricted use of open-source software, most notably with free editions of Linux and the associated infrastructure tools it delivers.  Businesses might want to choose a supported model such as Red Hat, but equally, many were happy to use CentOS (or now Rocky Linux), especially in non-production environments.

The greatest challenge to the open-source model has become the adoption by public cloud vendors of long-running projects such as the ones described earlier.  The development of platforms like MongoDB (almost) pre-date the commercial start of the public cloud, and it could be argued that the developers never envisaged the way in which their products would be used to deliver cloud services.  However, I’d say that no one can predict or dictate the future.  It’s easy to say, with hindsight, that the original intentions of a licensing model no longer apply, but then the benefits were initially there too.

The Architect’s View™

The open-source development model has many community and inclusive benefits both for individuals and for commercial businesses.  Start-ups have a choice – develop proprietary code, for which protection in law exists, or “crowd-source” development using an open-source model and expose the code to the risks of greater unintended exploitation.  Licensing models are changing, with the result that there will be casualties along the way.  This evolution is arguably needed to bring the spirit of open-source development into the modern cloud era. 

One final point.  When projects use non-contracted programmers, there will always be a risk of conflict or even apathy that could see a project abandoned or struggle to get traction.  Businesses that have adopted this code have to think about the potential risks versus using a commercial solution where there almost certainly will be a contract in place.  This exposure is a real risk that isn’t always considered when choosing Open Source.


Copyright (c) 2007-2022 – Post #ff33 – Brookend Ltd, first published on https://www.architecting.it/blog, do not reproduce without permission.