This article is based on a contributed piece by Patrick McFadin, VP Developer Relations at DataStax, originally published on IDG Connect in late 2019. It reflects the state of the open source ecosystem as of early 2020.
Open Source at a Crossroads
Open source has shaped software development for decades. Foundations like the Apache Software Foundation have shepherded projects that now underpin applications used by billions of people worldwide. But as cloud computing matured and enterprise adoption deepened, the open source movement entered a period of structural tension heading into 2020. Questions around licensing, sustainability, tooling complexity, and community governance all demanded attention.
Here are four predictions — written at the close of 2019 — that capture the key forces shaping open source at that moment, along with context that remains relevant for DevOps practitioners today.
Prediction 1: The Tension Between Cloud Providers and Open Source Projects Won’t Go Away
In 2019, several high-profile open source companies — including Confluent, Elastic, and MongoDB — revised their software licenses specifically to prevent cloud providers from commercialising their projects without contributing back to the community. The moves sparked significant debate: Were these changes philosophically consistent with open source principles? Would they discourage community involvement? Would they ultimately harm or protect the projects themselves?
The practical impact of those licensing shifts was still unclear at the time of writing. Some cloud providers responded by forking older, permissively licensed versions of the software — effectively sidestepping the new restrictions while leaving the upstream project without a revenue share. Others chose to partner with open source vendors as a competitive differentiator.
The likely outcome going into 2020 was uneven: some projects would grow despite restrictive licenses because their value proposition was strong enough. Others would find that tighter licensing dampened adoption, particularly in cloud-native contexts where developers expect low-friction access to tooling. The core conflict — between the open source ethos of free use and the commercial reality of cloud monetisation — was not going to resolve itself quickly.
Why This Still Matters
The Business Source License (BSL), Server Side Public License (SSPL), and similar instruments remain contentious in the DevOps community. Engineering teams evaluating open source components should always review license terms carefully, especially when deploying on managed cloud services, to understand whether usage restrictions apply.
Prediction 2: Kubernetes Growth Would Drive Demand for Better Open Source Tooling
By the end of 2019, Kubernetes had become the de facto standard for container orchestration. Its adoption was growing rapidly, yet it consistently outpaced the broader industry’s ability to operationalise it effectively. Kubernetes is architecturally complex — managing networking, storage, scheduling, and workload lifecycle across potentially multi-cloud clusters — and integration with existing IT operations tooling was a known friction point.
The prediction was that Kubernetes Operators — software extensions that encode operational knowledge for managing stateful or complex applications — would become increasingly important. Operators allow teams to automate tasks like database provisioning, backup, failover, and scaling using Kubernetes-native patterns. Without a growing ecosystem of well-maintained Operators, running complex workloads (particularly stateful ones) on Kubernetes would remain difficult to scale reliably.
From an open source perspective, the development and sharing of Operators within communities was identified as critical infrastructure — as important as application drivers or client libraries for enabling real-world adoption.
Practical Implication for DevOps Teams
When evaluating whether a data store or messaging system is suitable for a Kubernetes-based architecture, check whether a production-grade Operator exists and is actively maintained by the upstream project or a reputable contributor. Poorly maintained Operators can introduce operational risk that negates the benefits of containerised deployment.
Prediction 3: The Commercial Role in Open Source Communities Would Become More Transparent
There is a persistent myth that open source contributions are broadly distributed across independent volunteers. In reality, the majority of meaningful contributions to most major open source projects come from developers employed by, or directly sponsored by, companies with a strategic interest in those projects. This dynamic was expected to become more visible — and more openly discussed — in 2020.
Companies like Confluent (Kafka), DataStax (Apache Cassandra), Red Hat (Linux, Kubernetes), and Canonical (Ubuntu/Linux) invest heavily in engineering, documentation, and community management for projects they depend on commercially. That investment funds the health of those projects — but it also creates questions about governance and direction.
The healthier model, as described in the original article, involves formal governance structures that separate commercial interests from community decision-making. Apache Cassandra’s introduction of the Cassandra Enhancement Process (CEP) was cited as a constructive example: it formalises how major features are proposed, discussed, and approved, ensuring that contributors from organisations like Netflix, Apple, Instagram, and Uber — not just DataStax — have a structured voice in the project’s direction.
Beyond governance, documentation was highlighted as an underinvested area where companies can meaningfully contribute. Good documentation lowers the barrier to adoption and reduces the support burden on core maintainers.
What to Look for When Evaluating an Open Source Project
- Is there a defined governance model (foundation, steering committee, or formal RFC/CEP process)?
- Are contributions coming from multiple organisations, or is the project de facto controlled by a single vendor?
- Is documentation actively maintained and versioned alongside code releases?
- Are release decisions made transparently, with public discussion and documented rationale?
Prediction 4: Microservices Architecture Would Accelerate Open Source Adoption — Including for Databases
The microservices pattern — breaking applications into small, independently deployable services — continued to grow in 2019 and was expected to accelerate further. As services became more granular and specialised, teams needed equally specialised open source components to back them: lightweight message queues, purpose-built data stores, and well-defined APIs that could be consumed without tight coupling.
An important nuance in the original prediction: while event streaming (consuming data as it flows through a system) is valuable, it is not sufficient for all use cases. Some application functions require direct, low-latency access to stored data — a role better suited to database technology than to stream processing alone. As microservices proliferated, this was expected to drive broader adoption of open source databases designed for horizontal scalability and high availability.
The underlying logic holds: when a service needs to scale independently, its data layer must scale with it. Monolithic relational databases become bottlenecks in this model, which is why distributed open source databases have grown in relevance alongside the microservices pattern.
The Bigger Picture: Open Source and Cloud Are Inseparable — But Not Without Friction
The through-line across all four predictions is that cloud computing and open source are deeply intertwined, but that relationship is not frictionless. Cloud providers benefit enormously from open source software. Open source projects benefit from cloud-scale deployment. But the commercial and governance structures required to sustain that relationship were — and continue to be — works in progress.
For DevOps engineers, the practical takeaways are straightforward: understand the licenses of the tools you depend on, evaluate whether the Kubernetes tooling ecosystem around those tools is mature, prefer projects with transparent governance, and choose components whose data models and scaling characteristics align with a microservices architecture.
Original analysis by Patrick McFadin, VP Developer Relations, DataStax. First published on IDG Connect, December 2019.