No Easy Way Forward For Commercial Open Source Software Vendors

In an earlier article, I examined some of the recent dynamics in open source software, specifically around the for-own-profit commercialization of some projects by large cloud providers, and how that is driving smaller companies to seek out restrictive license models, in the process causing themselves considerable friction in their communities.

As befits a piece that deals with themes of free software and a polarized cloud industry, the article seemed to have struck a chord with several people, some of whom have contacted me to agree or disagree with my points. Rather than keep those to myself, I thought a follow up with three of these luminaries, with regards to their inside views on the topic, would be much more engaging.

In this article, I’ll summarize the main points from my conversations with Spencer Kimball, co-founder and CEO of Cockroach Labs; Joseph Jacks, founder and general partner of OSS Capital; and Abby Kearns, Executive Director of the Cloud Foundry Foundation. All have extensive track records in open source, but each has a slightly different take.



The independent vendor perspective: Spencer Kimball

While still a student in 1995, Kimball developed the first version of GNU Image Manipulation Program (GIMP) as a class project, along with Peter Mattis. Later on as a Google engineer, he worked on a new version of the Google File System, and the Google Servlet Engine. In 2012, Kimball, Mattis, and Brian McGinnis launched the company Viewfinder, later selling it to Square.

Drawing on his experiences at Google, Kimball wanted a technology like BigTable to be made available as open source outside of the company, and co-founded (again, with Mattis, and ex-Googler Ben Darnell) the company Cockroach Labs to provide commercial backing for CockroachDB, an open source project.

According to Kimball, whichever cloud provider is the best at brokering the multi-cloud migration will ‘win’ cloud. He adds that CockroachDB was built for that multi-cloud/region and relational future—where scale, complexity but also privacy frameworks such as GDPR become critical business drivers. But as optimistic as he is about the business, Kimball is also concerned about the sustainability of today’s and tomorrow’s venture-backed commercial OSS businesses.

Red Hat, Kimball reflects, clearly ‘figured out’ the model for commercial OSS before the days of cloud, becoming the dominant force in the commercial OSS business. The Red Hat ‘equilibrium’ (Kimball’s term) was based on selling contracts for support and professional services on top of widely-available OSS. With the emergence of cloud, Red Hat capitalized on the complexity of ‘big-software’ systems such as OpenStack and Kubernetes. (Bassam Tabbara of Upbound has commented on how this model might change with the IBM acquisition.)

Kimball states, “with cloud becoming the mainstream way to consume and manage IT, the complexity of some OSS provides a natural advantage to cloud platforms such as AWS or Azure, as they can use economies of scale to build a managed service out of any open source core.” He adds, “they can also offer enterprise support on top, effectively taking the bottom 50% of an emerging vendor’s total addressable market, and also capping its growth in the enterprise high-end.” So what is an emerging vendor to do? “The best protection is community,” says Kimball. Engaged, committed groups of maintainers, contributors and users are impossible to copy or to replicate in a managed service, and can keep even the most aggressive IT giant at bay.

Another protection could be to address a multi-cloud niche, as Cockroach Labs has done, which serves customers at the gap between the lock-in-focused cloud providers.  At the end of the list, Kimball mentions restrictive (“almost ‘byzantine’,” he says) licenses and other defensive models such as ‘free for use, source available’, whole-compilation protection and more—all suboptimal and not in line with the principles of free software.

In light of these comments from Kimball, it is very interesting—if not entirely surprising—to note CockroachDB’s licensing change, announced last week on the company’s blog: they are adopting a version of the Business Source License (BSL), that is not limited by nodes (unlike MariaDB’s version), but prohibits the offer of a commercial version of CockroachDB as a service without buying a license, by other players (read: AWS). This announcement has already resulted in friction on social media and the blogosphere (which I would rather not amplify by referencing).

The venture investor perspective: Joseph Jacks

OSS Capital is the world’s first VC firm exclusively-focused on investing in and partnering with commercial open-source software startups. An early contributor to Kubernetes, Jacks previously founded Kismatic, which he sold to Apprenda, as well as founding container mega-tradeshow KubeCon and donating it to the CNCF as part of its inception.

OSS Capital’s investment strategy is focused exclusively on supporting early-stage commercial OSS startup companies. OSS Capital’s equity partner/advisory network of commercial OSS founders have collectively captured over $140bn in value across 40 of the largest COSS companies of the previous decade; transferring this knowledge and expertise to the next-generation of commercial OSS founders is a core part of the OSS Capital’s value proposition. Additionally, OSS Capital organizes the commercial OSS community conference,

When asked about the strategic outlook for OSS given recent skirmishes, Jacks points out that the pie is getting much, much bigger: since companies outside of what is considered the software industry (from cars to home appliances) are effectively becoming producers of software, that grows the addressable market considerably, and will result in an acceleration of open source well beyond what we’ve seen so far.

Even from within the tech industry, Jacks says, “many OSS projects disrupt and/or bring transformational innovation to major global industries like data processing and storage (Spark, Ceph, Hadoop, Kafka,  MongoDB , CockroachDB, Neo4j, Cassandra), operating systems (Linux, FreeRTOS), semiconductors (RISC-V), networking/CDNs (Envoy, Varnish), software engineering (Docker, Go), computing (Kubernetes), search (ElasticSearch), AI (TensorFlow, PyTorth).” Those two major developments, says Jacks, will reframe the playing field for open source.

Given his expansive view, it is perhaps not surprising that Jacks is a critic of the recent proliferation of restrictive licenses as a defensive measure for emerging OSS companies. “This can dramatically reduce the value-creation potential of OSS projects, which are fundamentally driven by developer adoption,” he says, and adds, “instead, open-core OSS companies should use more permissive licenses like MIT, A2.0, or BSD in order to maximize value creation for all constituents (and that includes cloud providers), while capturing value on the proprietary layers around the open core.” (Jacks calls this layer ”the crust”.)

So what are effective strategies for a new OSS company to build, scale and survive in an  AWS-dominated world? Jacks says, “one, focus on maximizing value creation and capture for all, building highly standardized disruptive technology; two, build inclusive and constructive communities; three, ship quality software fast; four, embrace transparency and open governance across all constituents.”

The foundation perspective: Abby Kearns

I spoke with Abby Kearns as a follow up to my interview piece with her from late last year, and the conversation focused on the licensing implications of competitive moves in the commercial OSS market. At an impressive CF Summit, Cloud Foundry Foundation announced that its open source project Eirini, which enables pluggable use of either Diego/Garden or Kubernetes as orchestrators, passed its validation tests for CF Application Runtime releases. Kearns, who has served as Executive Director of the Foundation since 2016, is no stranger to both the opportunities and the tensions that exist at the intersection of free software and commercial interests.

As expected, Kearns is adamant, saying, “open source as a method of building and delivering free software can only thrive if we continue to put code in the open, and ask for help in improving it. ” She recommends to developers and commercial OSS companies to assume that someone will copy the software and perhaps even use it in a competitive context—and if one is worried about that, then why put code out there in the first place?

In Kearns’s view, actions such as using restrictive licenses can be revealing when it comes to the maintainer’s intent. Similarly, companies that open-source a wholly-formed thing might be missing the point, which is to build together, says Kearns—paraphrasing Richard M. Stallman’s famous manifesto: “free like free speech, not like free beer, not like a free puppy or free (used) mattress”.

Kearns believes that focus on these key tenets will see commercial OSS vendors through: engagement with contributors, transparency towards stakeholders, and outreach towards community. She also points out that growth in users isn’t the only meaningful metric for open source—just as important is growth in meaningful usage or in engagement with a dynamic community that likes to contribute.

Why open source in the first place?

To continue this positive note, Gabe Monroy of Microsoft recently retweeted a thread that showed how engineers from across rivaling vendors can collaborate successfully around open source software, to the benefit of both users and the projects themselves. Per Monroy, this is an “example of why multi-vendor OSS is the future of infrastructure software”. This, and so much more, could not have been achieved if it were not for open, collaborative communities and a bias towards permissive licensing.

(Originally posted on

Containers Put The ‘Dev’ Back In DevSecOps

On the back of a record-breaking Kubecon+CloudNativeCon (with a reported 7,700 attendees last week), it is very clear that Kubernetes’ position as a cloud center of gravity remains unassailable in the foreseeable future. For one, even outside of this sprawling tradeshow, it has taken over sessions at many other conferences, from the Open Infrastructure Summit (previously OpenStack Summit) to the Cloud Foundry Summit. I personally believe that in the next few years, these two conferences (and others) will either accelerate in their contraction or even merge into a mega CloudNativeCon.

Does that mean digital transformation has reached a steady state? Hardly. As the Cloud Foundry Foundation’s April report showed, 74% of companies polled define digital transformation as a perpetual, not one-time, shift. The survey also shows that organizations are already using a good mix of technologies and clouds in production, which explains the Foundation’s endorsement of Kubernetes and the launch last year of the related project Eirini.



New models, new personas, new tension

In the end, what matters to IT teams is a thoughtful approach to building and deploying cloud-native applications. There are many reasons why containers have become so popular since DotCloud’s pivot into Docker all those years ago, and I have gone through some of them in previous posts. IBM’s Jim Comfort has called it the most dramatic shift in IT in memory, more so than cloud computing. Since that pivot, it has become a convention that whatever is in the container is the developers’ responsibility, while operators own what is outside of it.

Kubernetes and related projects challenge that paradigm even further and represent the cloud-native vision in that they provide developers with access to native APIs, which means they have much more control over how their application is delivered and deployed. So, while software is eating the world, developers have started to eat the software delivery chain.

However, Kubernetes’ evolution into the golden standard of an “un-opinionated PaaS” still means that in most large enterprises it is still owned and maintained by operations-minded engineers. Therefore, one of the main efforts driving enterprise adoption has been to build operating models that balance developer empowerment and operator governance—for some, that means DevOps. However, the rise of DevOps is not the only shift in user personas that we have seen.

Open source and the “shift-left” risk

Security used to be the place where people not only buy, but also use solutions to prevent and adapt to security risks, but this was at an age of waterfall development and of mostly closed-source code. The rise of open source software has been disruptive to that as it has been pervasive—whether the application itself is open-sourced or not, significant amounts of open source packages are being leveraged in its creation. The cloud-native movement has accelerated this trend even further, with its strong bias towards open source.

The reason this matters is that security teams are not staffed nor equipped to control these open source inputs. Whether the security team was planning for it or not, a lot of their risk has “shifted left”, and now with open APIs, both the breadth and speed of risk have risen. Snyk’s latest report, “Shifting Container Security Left” shows that the top 10 official container images on DockerHub each contain at least 30 vulnerabilities and that even of the top 10 most popular free Docker-certified images, 50% have known vulnerabilities.

Even worse, the report surfaces an acute ownership problem, as 68% believe developers should be responsible for owning container security, while 80% of developers say they don’t test their images during development, and 50% don’t scan their images for vulnerabilities at all.

Time for joint accountability

As a consequence, when it comes to software-lifecycle tools, security vendors are experiencing a demand shift—a separation of personas at large enterprises. Security teams are still the economic buyers and hold the budget authority; however, with the realization that developers must have the tools to own more of the security of their own apps, comes a transfer of budget decisions over to development teams, who will actually use these tools. You build it, you run it—but you also secure it.

As I mentioned in an earlier piece, this is not an easy process for a security industry that is geared toward servicing security teams. The challenge many providers are facing is to provide tools designed for both sides of the aisle, that can promote joint accountability: empowering the people “on the left” while giving those “on the right” enough levels of control and observability.

In a sense, to shift-left is to let go. With more code—in a repository or in pre-built containers—coming from lesser-known origins and deployed more rapidly on more distributed systems, the only option is to continue to evolve and provide developers with the right tools and knowledge to own security.

(Originally posted on