We don’t make software for free, we make it for freedom

The debate about whether vendors can thrive and scale if their primary outputs are freely licensed continues to brew nearly two years since I wrote about the topic.

Basing a business on an open source strategy is undoubtedly challenging, because no matter how many times you quote Richard Stallman that “software freedom means ‘free speech’, not ‘free beer’”, there is a persistent expectation that open source means free: free software, free updates, free knowledge, free support.

In part, the confusion comes because a lot of GPL software is ‘free as in beer’. Many open source projects come from individuals or small groups coalescing around a problem they want to solve. They publish their output for free because they want others to join their effort.

But it’s a myth that volunteer software programmers are architecting application software suitable for enterprise deployments. It’s rare for volunteer- and community-based projects to scale without sponsors, such as large multinationals, foundations, or government grants funding paid-for project management, design and development inputs.

My own involvement in open source came from leading a government-funded consortium project involving 20 universities and other education institutions contributing to Moodle, then establishing the Mahara project and a wider community site called Eduforge.

I soon learned that the vagary of external funding is not a long-term sustainability model.

A challenging environment

Many commercially derived open source projects also end up being freely available. It’s hard not to when it’s so easy for someone else to undercut your offer with the very same code you wrote. If not entirely ‘free as in beer’, significant downward pressures on price remain. So, trying to be a successful open source vendor is not for the faint hearted.

For example, it’s really hard to scale an open source product supported solely through related consulting or professional services revenue.

With tight margins and feast-or-famine demand, it’s difficult to maintain the investment you need to drive a product forward without the benefit of licensing revenue. Although I know of some brave and impressive companies doing it, most erstwhile open source vendors end up being proprietary wolves in open source sheep’s clothing through various bait-and-switch tactics.

Take ‘open core’, which means offering proprietary modules that extend or enhance the core open source software.

The downside is that delivering mixed-model feature sets in a single software product can readily violate the GPL. And customers soon see it for what it is, another form of lock-in, not to mention lock-out from being part of the innovation value chain in any meaningful way.

Many single-vendor commercial open source firms adopt the dual-licensing approach, with a free community version and a paid-for enterprise proprietary license.

The risk here is that the company prioritises the proprietary version, because that’s where their money comes from, and the community version is soon perceived as ‘crippleware’ or even worse, ‘abandonware’.

For example, SugarCRM suspended or slowed development on its Community Edition and now makes it clear that it is not suitable in a production environment.

I’m not criticising them – you have to earn enough to keep the lights on, right? – But are they still an open source vendor?

Then there’s the rich irony of open source companies and cloud computing.

In this distribution model, the open source software is not released to customers. The Free Software Foundation considered incorporating the special provision of AGPLv1 into GPLv3 but ultimately decided to keep the licences separate.

So, while not open in the sense of having access to source code, the cloud approach is entirely legal.

How to succeed without bait-and-switch

Is there anything left? Yes, commercialisation to ensure sustainability of enterprise-ready open source software is possible without resorting to proprietary bait-and-switch tactics. It entails offering low-cost subscriptions for a packaged bundle of services including research and development, code maintenance, documentation and training.

It’s a given that you need good architects, analysts, designers, UX specialists and programmers to work closely together to develop, maintain and improve software products. You need revenue to pay for that.

But, given the freedoms of the GPL, you also need to offer low enough price points for such clear and tangible value that it dissuades the obvious free-rider workarounds.

Logically, if price points are low, that means scaling quickly, so you need to productise or package your services model, recognising that selling a GPL product is hard, if not impossible, to defend.

To scale quickly, you also need an engaged community of stakeholders (customers and partners) to help with the necessary feedback so your R&D is really focused.

You also need a high-quality, loyal partner network who can generate a vibrant marketplace of solution providers that offer real customer choice.

With full access to 100% GPL code, and without having to shoulder the burden of investing in the open source product set on their own, partners can accelerate the growth of their businesses by offering customers a huge range of value-added expertise: cloud services, hosting, consulting, implementation, training, configuration, integration, migration services, customisations and plugin extensions.

Intrinsically, by working with open source technology, a global community of service firms, system integrators and implementation experts can offer deeper value than is possible with a proprietary model.

Open source empowers innovation throughout a far more flexible ‘value chain’. This means customers are free to fully embrace ideas from anywhere in a way that is relevant, valuable, and sustainable, while not being constrained by a vendor’s closed intellectual property.

It’s a big challenge to make the model work. What makes it even harder is when luminaries in the open source community join the clamour for you to offer the equivalent of a free beer tab to the world.

Neither the open source definition nor the GPL obligates anyone to publish everything into the public domain in real time (or even later). This isn’t an interpretation of the GPL—there’s no requirement to publicly publish every innovation or software maintenance update on GitHub nor anywhere else.

Although hard to measure, it wouldn’t be surprising if the majority of open source code isn’t published, certainly not in real time.

Open source vendors aren’t obligated to work in the public domain for the public. It’s enough to work with our partners for our collective customers and deliver to them all the wonderful benefits of enterprise open source solutions.

We don’t make software for free; we make it for freedom.

This post originally appeared on opensource.com.