In today’s evolving developer landscape, we’re finding that more and more open source software is commercially backed. A recent GitHub report found that the largest open source projects by contributor count in 2022 are almost all commercially backed, meaning more money and more talent is being devoted to them.
This is a win for the open source community, but it also raises questions for businesses that develop open source software about how to invest in, grow, and commercialise their open source projects. The worlds of community and commercial open source are very different, and it can be a struggle for organisations to keep a foot in both camps, all the while providing each type of software with the support it needs to flourish and grow its appeal to developers.
Some companies end up favouring one type of project over another, often with the commercial side winning out. But maintaining a balance between your commercial and community open source projects is far better for the long-term sustainability of both. To achieve this equilibrium, you need to identify and nourish the contrasting factors that ‘feed and water’ each type of project.
A virtuous cycle of learning
Some companies have their roots in an open source project, on top of which they have built services and additional functionality to provide a companion paid offering. Other vendors acquire open source products to complement or augment their paid products, with the intention of adding a commercial open source version. Although the needs of community and commercial open source differ, valuable information can be gleaned from one group of customers that can then be helpfully applied to the other group. Think of it as establishing a virtuous cycle, where the interests and innovations of the larger open source community prove valuable feedback for the paid version of the software, while the input of a smaller group of paying customers helps to inform the roadmap for the community version.
One way of looking at the challenge of maintaining separate but related goals for community and commercial open source software is to imagine each version as a race car. A business must ensure that both vehicles are fully maintained and have the necessary fuel and features to keep moving forward at speed. The commercial “vehicle” will always need to be running somewhat ahead of the open source vehicle and contain additional features that organisations will be willing to pay for. The race track and the surrounding environment continue to evolve, however, so both vehicles need to be in a state of constant evolution and improvement to meet the surrounding needs.
How many integrations?
One concern for all open source projects, regardless of if they’re commercial or community products, is keeping pace with the constantly-evolving landscape of adjacent technologies and deciding how or whether to connect with them. For instance, in the world of machine learning right now, there is a crazy Darwinian landscape of programming models that are constantly competing and supplanting each other, whether it’s TensorFlow, PyTorch or JAX. Ideally, an organisation wants its software to interoperate with all these models — past, present and future. However, that’s rarely feasible. The organisation must decide which models to develop itself and which to partner on or outsource in order to remain relevant in the ever-shifting ecosystem. A further question is whether to take the same approach to integration for the community and commercial versions of the software or whether they should differ.
In the open source world, supporting a broad range of third-party technologies and standards can demonstrate the health of a project, attracting developers with the breadth of features regardless of how those features translate into real-world usage. On the other hand, commercial buyers want to quickly realise ROI and achieve an optimised level of usage. So debates about which functionality and integrations to provide might favour the customer or customers with the loudest voices and deepest pockets. This is a balance every organisation must strike based on their resources and the anticipated needs of their customers and community.
Ease of use vs bells and whistles
Usability is another prime differentiating factor. Open source users tend to be technically-minded developers who require less hand-holding than corporate users, who generally want software to work out of the box and be intuitive to use. Customisation is more strictly controlled in the corporate world and much more ad-hoc in open source communities where hundreds of contributors are welcomed, and developers are more willing to fine-tune software to their liking. The commercial software world also has much higher requirements when it comes to security, governance, and regulatory issues, and this is an area where product functionality will often diverge.
Support and security are always key
Maintenance and support are critical for commercial open source software, along with regular updates and patches. By contrast, finding the latest version of a community open source project, or a fix to a vulnerability, often takes more time and effort on behalf of developers or may even involve a lag in time before the community steps up to remediate it.
In general, businesses providing commercial open source software should strive to provide the best possible maintenance and support since this is often a key distinguishing factor compared to the community-supported version. But in every case, organisations must make vital security patches available to all users in the quickest and easiest manner possible. This is a basic responsibility of all software providers and will go a long way to securing the trust and confidence of all users of an open source product, whether commercial or community-based.
The halo effect of a great open-source project
As we’ve seen, there are multiple considerations for any open source project, and companies pursuing a mix of commercial and community open source must find the right balance to satisfy all their constituents. One certainty is that a well-managed open source project can have a “halo effect” for vendors — developers who appreciate how the open source software is supported and maintained grow to trust the vendor and may therefore be attracted to other products and platforms they provide. In this sense, it always pays to do right by your users, commercial and non-commercial alike, and to provide the best possible experience for both worlds.