One of the most visited and valuable public service websites in the UK over the past few months has been the Gov.uk Coronavirus dashboard.
Everyone from concerned family members to government personnel, public health officials, healthcare employees, journalists and the public relied on this open-source resource.
It’s not just the public sector which is convinced by the power of sharing and collaborating around IT functionality. We are seeing more and more organisations quietly dropping proprietary software in favour of open-source equivalents.
Using open-source technology – just paying for associated services support – is often a sensible option, especially when compared to hiring new staff. True open-source software is regularly improved by active community engagement. Bugs are often identified and fixed quicker than they are by a vendor who runs both an ‘open’ and enterprise version of their software.
True open source allows businesses to experiment with different software to find the best fit, without being locked-in. This gives you the chance to try new things and either adopt, or move on, depending whether it suits you.
Standards alignment
Even better, if your open-source vendor’s software has drop-in compatibility with a standard like SQL, there are many places you can move if you need to try something new. Aligning with such a standard means you don’t have to just accept price-hikes imposed during annual contract reviews because an important process is built on one piece of proprietary software and it has become too expensive for you to leave.
Open source also frees you from paying for legacy support contracts that are no longer fit for purpose. All this can be hugely beneficial for your business, as well as being cost-effective.
However, despite all these positives, in my experience the enterprise approach to open source at the big business software level is much more cautious than the narrative from the open-source community might suggest. In my view, some of the commercial strategies of the main open-source platform vendors aren’t making adoption that much easier either.
The challenge is how to monetise ‘free’ software. We’ve all become used to a freemium idea, where an entry-level version of the product is out there for free, but to access the good stuff – the enterprise, heavy-lifting services and features – you need to pay for the commercial edition.
Now that approach makes sense to some vendors’ CEOs, as they want to grow the company and keep resourcing the innovation, and I would say the majority of popular open-source applications have adopted this model.
As a CTO, this approach makes me wary. If the project stops being a proof-of-concept, then I may have to enter a commercial licensing agreement to access the full version of the software. This might be familiar territory, but I have a lot of scar tissue from dealing with vendors who love to take my money and then ramp up support costs every year.
To pay or not to pay
It’s even harder when I have worked with a vendor without issues for months – or even years – and something really good is in production; then they switch horses mid-stream, become a commercial company, and send me an invoice for what I thought was free excellence.
There’s also the danger that if I start a project on a freemium basis, build a great proof-of-concept pilot then baulk at the cost of the transition to ‘enterprise’ customer status, I may end up trying to fake it while I make it alone. This can mean crashing the whole idea because I don’t have the resources, and disappointing the line of business managers who loved what I’d initially given them.
I know this because while I (proudly) work for an open-source vendor now, I’ve been on the other side too many times.
I’ve worked – or tried to work – with a lot of open-source business software firms, and I’ve seen how badly this can go. I was on the wrong end of that commercialisation problem, in a previous role when a vendor we loved working with was bought by a third party. They changed their licensing model and the cost went from $2,000 a node to literally $10,000 overnight. This made it uneconomic, so we stopped paying them support and moved platforms.
Despite this, I’m a passionate believer in the open source ideal. I personally contribute to multiple open data and open source projects. So, do I have any magic solution to working with an open source company and making sure both sides get a fair deal?
Well, I’m not sure I have ALL the answers, but I do think this:
Accept there’s no such thing as a free lunch
You want innovation and support. They want to pay wages and grow their company. Don’t be naïve, or cynical: see this as a fair business relationship.
Offer to pay, and pay for the long term, not for their code, but their expertise. Having access to the main development team at the software firm to help you exploit the potential of what they are creating means your resources don’t get stretched.
You are still not paying Oracle-style fees, and the open source vendor gets to invest in their software and their team for mutual long-term success.
Have an honest conversation about long-term strategy
Yugabyte has committed to a true open source model. It may sound a bit gushy, but as a matter of company culture and purpose we won’t ever do the hiding-the-scale-bits-in-the-pricey-version thing.
We believe there’s sufficient demand for what we offer to allow us to be a profitable company by providing support services that some people want to pay for, and also allow others to just use the open source software if that’s all they need.
Not all open-source companies think like this, or see the roadmap this way, so have the conversation with your vendor. If where they want to be in three years doesn’t sound affordable to you, walk away and find an alternative – the best thing about open source is that there are always other options.
Incidentally, technology architecture choices are important. We use the PostgreSQL codebase for our API, which means if you change your mind, as it’s an open standard, the code you’ve built with us will work once you’ve asked us nicely to stop calling! No biggie, we wish you all the best.
Is it really open source?
True open source is about making it possible to run the solution at an enterprise level, at scale.
Understanding where your vendor sits on this spectrum is important, because you are likely to want a long-term relationship with your vendor to get the product your business needs. If you’re getting 10% of the features off a thinner shadow of the real programming, it’s not a genuine open source company; so be realistic about what you are getting into.
Partner, partner, partner
I’ve found that trust and honesty is what really makes a business relationship not just worthwhile, but valuable. Ensure you have an on-going dialogue with your new open source partners about where you want to go. That often translates into them being willing to build features for you that they hadn’t even been thinking about.
Summing up, I think that with some tweaking and a few more honest conversations on both sides, open source will continue to work well for the enterprise, allowing them to explore new software options, benefit from innovation, and reduce their technology costs.