TriggerMesh, Case Study in Open Sourcing Enterprise Software – InApps Technology 2022

The future of infrastructure and systems management software development is open source-driven not just by vendors but by technology users.

Kubernetes is a prime example. It has become the de-facto cloud native platform supported by every major cloud vendor. There are many reasons to think that the next decade will see continued growth in free and open source software.

Looking at companies that have decided to go all-in with enterprise open source solutions, there have been impressive results. We have witnessed Confluent, Kong, Cockroach Labs and HashiCorp deliver systems management and infrastructure software as open source, and all of them have earned their unicorn horns as private companies.

Elastic and MongoDB have both become multibillion dollar public companies, and IBM’s $34 billion acquisition of open source vendor Red Hat was the largest in history. That’s why I continue to see this as the most compelling way to deliver enterprise infrastructure software.

TriggerMesh’s Transition to an Open Source iPaaS

At TriggerMesh, we knew early on that we wanted to open source our cloud native integration platform. We even built a team that has extensive open source experience as leaders, contributors and maintainers, though many people have questioned why we didn’t start out making our platform open source. For lack of a better reason, adoption. Not that we didn’t know how to do open source, but we knew that we didn’t have the resources to do it well. And open sourcing software just for the sake of it and then see it gather dust on the shelf was far from our vision.

In 2018, Sebastien Goasguen and I co-founded TriggerMesh on our dime, then took a very modest amount of funding in December 2019 to build the core product. In June 2021, we raised additional capital to bring our products to market, and that meant we now had the funding for our open source initiatives.

That’s why we launched our TriggerMesh Cloud Native Integration Platform as an open source project at Kubecon North America 2021. It was a difficult decision, as we and our investors have to consider what’s best for our company. After many discussions, we decided to go all-in on open source and a business model that complements our open source strategy.

Choosing an Open Source License

We were very aware that we needed to choose a license that the Open Source Initiative approved for software to be considered open source. However, we wanted to learn from others who had come up with licenses that, for the most part, included the values of open source but had some restrictions.

For example, we evaluated the Server Side Public License used initially by MongoDB and later Elastic NV. We saw that Confluent chose to license its product built around Apache Kafka similarly, but with a provision that prevents vendors from providing its free code as a service.

We also considered the Business Source Licenses, an alternative that delays immediate open sourcing, used by several prominent vendors. Championed originally by MariaDB and later Cockroach Labs, it also includes a provision that precludes a vendor for offering a commercial database as a service.

I understand the reasoning, as an open source license may allow other vendors, particularly SaaS providers, to offer the same technology as the original developer, who has done the lion’s share of development. The consideration is seeing how companies have spent considerable resources only to have cloud vendors provide the software as a service and cut into initial developers’ business opportunities.

However, we ultimately settled on the Apache License, Version 2.0, because we wanted to make sure there was no question that we were delivering open source software and not some modern shareware variant.

Open Source Is a Development Methodology, Not a Business Model

We believe that open source is the best way to bring infrastructure software to market. We are operating under the assumption that in 2021 every large enterprise will have an open source strategy of some sort. That is why we use open source development to generate our technology. Though selling software isn’t our business model, solving enterprise technology problems is.

We also believe that companies need to be very careful about making their business model depend on open source licenses or similar licenses like those mentioned earlier. That is why we chose the Apache License, Version 2.0.

This license is broadly accepted and mitigates risk for potential customers who may be reluctant to take a chance on a budding company with a short track record. We also made sure to register and defend our trademarks so that while our code is free, our trademark can only be used under the guidelines we specify.

Building a Community

We didn’t subscribe to the “Field of Dreams” open source strategy, briefly stated as, “If you open source it, they will come.” Instead, we wanted to put the infrastructure together to deliver our project and grow it. It also meant making some changes to our processes and procedures. For example, we needed to think about the experience for new users and potential future developers.

The first thing we did to prepare was reorganize our repositories on GitHub into a single repository. Consolidating our codebase enables users to find what they are looking for quickly.

We also created a single Kubernetes controller for users to install the product easily. We hired an experienced open source contributor with a long track record in open source and cloud integration to manage developer relations.

We also updated our website to focus on open source and community engagement. Also, we spent a considerable amount of effort updating and adding to our documentation to help new users and developers be more successful.

The big question is: How do you define success? It’s not unlike the way you would manage a business, but we are looking at metrics like users, contributions and pull requests rather than revenue. Perhaps the most superficial metric is the number of stars, which is an excellent first step, and we hope that’s the beginning of a funnel of community members.

Our Business Plan, Not an Open Source Plan

Our business plans have remained essentially unchanged despite the licensing change. The TriggerMesh entry-level product involves support and services for the TriggerMesh open source integration platform. We offer this for on-premises use and provide a hosted version in the cloud that we manage for the user. We offer products and services that complement the open source project. We will likely open source more software and increase contributions to upstream projects like Knative, which just reached its 1.0 milestone.

Featured image via Pixabay.