A roadside cafe sign advertising Donas Cafe along the busy A12 trunk road on the 20th October 2009 … [+]
In Pictures via Getty Images
Developers love open source. In truth, many people outside of the professional software engineering cognoscenti are very fond of open source too, often optionally using a degree of open applications on devices from their smartphones, their tablets and onward their desktops.
But times are changing for open source and some parts of some projects are changing their licence structure and going commercial. Microsoft has already (famously) changed its mind on an aspect of open source monetization this year; this is a thorny subject, make no mistake.
Navigating stony ground
For open source project owners that want to move their work forwards into the commercially licenced sphere, the path to do so is (perhaps unsurprisingly) also fairly stony ground. Not only does an open source project need people with commercial acumen and experience of finance and business, but it also needs a fundamentally enriched level of technical monitoring and operational awareness.
One man that speaks from experience in this space is Caleb Hailey.
Hailey is senior director of product management at Sumo Logic and co-founder of Sensu, a software project that codifies monitoring workflows into declarative configuration files that can be shared amongst team members and subsequently treated as code and so edited, reviewed and versioned.
Sensu Enterprise, an open source monitoring software, experienced this journey in early 2013, transforming into a variety of forms before it was finally released in 2017, and then later acquired by Sumo Logic in 2021.
The shift from an open source software project to a product takes many steps, from considering revenue sources to launching a beta version of the product. From his own perspective and that of his team’s collective experience, Hailey proposes three key phases that could help define this process and guide others through the journey that some enterprise software will inevitably take today.
Phase #1: Listen
Perhaps unsurprisingly, phase #1 is all about listening. This process centralizes around a questioning analysis designed to decide how far a commercially licenced product with open source origins should be unopinionated or opinionated. In this sense of the term, unopinionated software has a stronger level of platform agnosticism and rawness that keeps it closer to its open roots – conversely, opinionated software has specified integration points with other software tools, platforms and functions.
Sumo Logic’s Hailey suggests that building a project through an unopinionated mindset can both hinder and help the development process.
“Sensu Enterprise originally set out with a goal to build an unopinionated product, with a framework that allows users to compose monitoring solutions using the best available tools around. However, developers ran into a wall when users wanted easier integration with the available tools they owned. Developers knew they could not ignore their users’ requests and so decided on a plan to provide a supported dashboard, third-party integration and commercial support to help meet the demands of users,” explained Hailey.
Phase #2: An open core model
In this instance, the adoption and utilization of an open core model proved its worth. An open core model – although essentially a technical play, is often thought of as a business strategy – means that a software project offers a free and open source version of its product alongside as a commercial paid-for version (that typically ships with extra add-ons and services) at the same time. Both spheres of the open source and closed source software project can be said to sit within the open core model itself.
An open core model benefits an open source software by cost savings, speedier development and greater productivity of IT management and administration.
When Sensu Enterprise switched to an open core model, Hailey notes that the project introduced a library that made it possible to leverage alternate messaging solutions, in turn improving Sensu’s support for extensions, allowing for native Secure Sockets Layer (SSL) support, pluggable authentication framework and support for Accces Control Lists (ACLs).
Phase #3: Launch a private beta
The decision to launch a private beta stage product is sensible. As the fourth stage in the software release lifecycle i.e. after pre-alpha and alpha, we get private beta before beta… and then release candidate and release to manufacturing after. Private betas are agreed to provide software developers with insight into the wider scope of needs for their product.
“With private betas, teams gain insight into their customers’ needs, outlining the areas that product managers need to support and adjust. Before it’s official launch, Sensu Enterprise launched a 10-week private beta, reaching over 50 organizations and supplying adequate user feedback that allowed the successful implementation a final set of improvements that helped successfully launch Sensu Enterprise 1.0 as it stood at launch,” said Hailey.
After a full year of Sensu Enterprise 1.0’s public launch, the success of the project-to-product process became apparent. Sensu Enterprise saw an 80x year-on-year increase in monthly recurring revenue (April 2015/2016) and an 11.5x growth in annual recurring revenue (ARR) from its opening quarter (Q2 2015) to Q4 2015, putting ARR well into the 7-figure territory after only 9 months of sales.
An intense focus on early customer feedback, the use of an open core model and true customer feedback lead the product to a successful year following its launch.
Wider (open) opinions
This is a sensitive but (arguably) burgeoning subject that is currently ‘enjoying’ (possibly & hopefully the right word) a great deal of discussion inside the professional software application development space among engineers, developers, information management scientists and C-suite tech circles too.
Having lived the life of almost all of those roles is Peter Zaitsev, CEO of Percona, a specialist open source database services provider with a dedicated focus on the MySQL, MariaDB, MongoDB and PostgreSQL platforms.
For Zaitsev, the journey between open source and enterprise software and the bridges and conduits formed between the two spheres comes fown to first making sure a software teams understand its goal (or goals) for the project in hand. He says that this defines if and how much of a commercial product might ultimately be built around an open core – it also helps specifiy the ‘degree of open source’ that that the project will be able to afford to be.
“An other element to consider is the ‘adoption-monetization slide scale’ where the ‘more open source’ a project is (i.e. permissive license), you will see better organic adoption. Whereas the more ‘commercial’ it is, the less organic adoption you will get. As an example, [open source analytics platform] Grafana went from Apache to AGPL, but only after it had reached critical mass,” said Zaitsev.
Agreeing to an extent with Sumo Logic’s Hailey, Zaitsev thinks that the phased approach described above is workable enough, but he reminds us that it is very specific to a particular use case such as a kind of software. What this means in practice is a different monetization depending on the type of software being created i.e. an open source library would need to approach things very differently from an open source desktop developer tool.
“In particular in the database space, we used to see an open core model – but that approach is now becoming a legacy technology as approach used instead is a Database-as-a-Service (DBaaS) solution with additional power features and usability with open source as the core product. I think it is better to talk about a more generic approach to differentiation i.e. you need to have a clear value difference with what a community (who just use open source software) gets vs what [commercial] customers get. It can be a delicate balance between what features and functionality the community can get that is exciting and valuable, but those who can afford it are motivated to pay,” explained Zaitsev.
Open doesn’t own community spirit
There are tangents, tributaries and t-junctions aplenty throughout this discussion and we can already see that there is more than one single open source universe. It’s an important takeaway point here, as is the fact that open source (where peaceful community spirit driven democracy and meriticracy are supposed to reign) can also come with politics and infighting.
“I think the most active community exists in cases like Kubernetes, Linux and PostgreSQL, when there are multiple commercial offerings which correspond to a single open source community. Also note that the strong community element is not a monopoly held solely within open source these days – think about AWS which is quite a proprietary platform, but with a pretty strong community around it. It is just the role and influence of the open source community varies depending on the ownership model,” concluded Percona’s Zaitsev.
Today, tomorrow and the day after that, open source software at the various levels described here will run much of our global technology backbone, our desktop and handheld devices… and the neural network of synaptic interconnections that weave the whole fabric of the modern IT stack together.
Open source runs us, so understanding how we run it is important.
