Cloud Native has become synonymous with open source, partly because organisations such as the Cloud Native Computing Foundation and the Continuous Delivery Foundation offer a vendor-neutral home for many Cloud Native projects with open source licenses. With this ubiquity, however, arises a conundrum. Cloud Native tooling has undoubtedly reaped benefits in terms of adoption because of these licensing terms, and cloud providers have been able to customize and provide managed service offerings for commercial gain. However open source is still very much an understaffed and largely voluntary venture. Even with all the knowledge and context around the open source movement, many organizations are happy being mere consumers of the software without giving anything at all back to the wider community.
With restrictive policies around voluntary contributions still in place in many commercial organisations, and a few major players backing the funding and upstream for such projects, we have the risk of a massive imbalance in the Cloud Native open source ecosystem. That is, of course, assuming nothing changes.
Freedom of software
But let’s take a step back. Why does open-source need funding if it is free? As this Stack Overflow blog correctly puts it, “Open source is not about free software, it is about freedom of software.” Most open source contributions are voluntary i.e. they are worked on by contributors in their spare time without any expectation of monetary compensation for their time and effort. Having an entire ecosystem dependent on such a stream of contributions isn’t sustainable in the long run however, primarily because neither the steadiness nor the availability of such a stream can be guaranteed. The situation can be even worse for more senior maintainers on an open source project as there are fewer of them. From a contributor perspective, it can eventually lead to burnout as clearly articulated by Dawn Parzych in this article. There’s also a wonderful talk delivered by Julia Simon at the recently concluded KubeCon + CloudNativeCon North America, 2021 on the same theme, and it’s one we’ll be exploring more in a subsequent issue of WTF.
The alternative is to have these contributions incorporated into their day jobs so that the contributors can be financially compensated for their work. This isn’t unheard of by any means, but it is still a relatively unusual situation. After all, why should organisations care about open source projects?
A case for open source upstream contributions
While there are a myriad range of benefits from contributing to open source, it is also equally difficult for companies to lean towards sponsoring these projects or even having upstream contributors. As with contributors, voluntary work for the sole purpose of furthering the open source movement is not a good enough justification since it does not guarantee anything in return from a financial perspective—Unless of course, the company is actually implementing the project for its own benefit or has a business around the project. As Aaron Stannard mentioned in his article, “...when you build a business around your OSS project your incentives for working on it change radically towards something that looks sustainable.”
But what about organizations that aren’t IT or software service providers, but rather are IT departments servicing a business? With the emergence of Cloud Native tooling and practices such as DevOps and Agile, there has been a cultural and technical shift in the way we develop and offer software. Not only has this garnered more interest around adopting open source alternatives but it has also resulted in major service providers incorporating these projects into their managed service offerings. This popularity of Cloud Native development could potentially steer open source towards better sustainability via increased support for upstream contributions.
A good example is how Pfizer contributed to Drupal’s 8 content workflow system,molding one of the most powerful content management systems. However this still is a cause that must be rallied for given the current state of affairs where the majority are mere consumers with minimal feedback into the entire process of open source development.
Nothing illustrates why upstream contributions matter (and are beneficial for all) better than this snippet from the Red Hat blog:
When software is developed using open source methods, an upstream repository of the code is accessible to all members of the project. Members contribute to the code, test it, write documentation and can create a solution from that code to use or distribute under license. If an organization follows the main stream or branch of the upstream code their solution will receive all the changes and updates created in the upstream repository. Those changes simply "flow down" to the member’s solution. However, if a member organization forks the code -- if they create a solution that strays from the mainstream -- their solution no longer receives updates, fixes and changes from the upstream repository. This organization is now solely responsible for maintaining their solution without the benefit of the upstream community, much like the baby salmon that took a tributary and then have to fend for themselves rather than remain in the main stream and receive the benefit and guidance of the other salmon making their way to the ocean.
Where do we go from here?
While support for upstream contributions is a major theme when it comes to open source sustainability, there are various other aspects that need to be considered as well. Governance models, codes of conduct, and licensing are all major factors in the open source ecosystem that determine who gets to do what and how they get to do it, and, as Jennifer Riggins notes elsewhere in this WTF collection, open source communities are often not the most welcoming to underrepresented groups in tech. Tying governance in with the existing discussion, and strengthening and even standardizing these within the Cloud Native open source ecosystem, will only help chart better roadmaps for the projects and their contributors. This helps build clarity and transparency within the ecosystem and makes it more appealing for consumers and partnering organizations alike.
Unfortunately there is no one size fits all answer here given the vast landscape that Cloud Native covers. As Matt Asay puts it“...open source sustainability will never have one, meta answer for all of open source. It's always a project-by-project analysis and, really, a founder-by-founder (or community-by-community) decision.”
Ultimately if your company is using open source for competitive advantage, it may well be in your interest to foster an environment that encourages active contributions. A recent McKinsey & Company report, How software excellence fuels business performance, found, the "biggest differentiator" for top-quartile companies in an industry vertical was "open-source adoption," where they shifted from users to contributors.
Previous article
