SteveStreeting.com

Bruce Byfield wrote an interesting article (discovered via Matt ‘Alfresco’ Asay’s blog, which should be required reading for anyone in this field) about the sometimes unsteady alliance between open source and business that, on the whole, I agreed with – within a given context. I do think, however, that his context was weighted towards the larger players in market that are fusing open source with business opportunities though, and wanted to share some of my experiences and conclusions from the perspective of a more individual player in the business.

Apologies for the length of this article, I had a lot to say

Public Companies And Priorities

I happen to believe that publicly-traded companies are the worst example to take when comparing and contrasting the balance of ideals versus commerce, because they are essentially at the far right end of that scale; at the end of the day, those quarterly results and their effect on the share price trump all other concerns, when push comes to shove anyway. In this environment, it’s not surprising that Bruce considers it inevitable that business considerations will inevitably trump open source principles.

I think that in private companies there’s scope for more balance, if the company owner(s) are on board. That’s not to say private company owners don’t want a return on their investment of course – it’s just that it’s at least possible that they’re close enough to the original ideals of the company to decide to sacrifice a little profit in favour of other priorities, should they want to (and assuming it doesn’t put them out of business).

Balancing Business and Community

However large you are though, there’s absolutely no doubt that developing a sustainable business from open source is hard. I do think that business and open source can co-exist without hurling philosophical rhetoric at each other every 5 minutes, but there are challenges. Let’s assume for a second that a business is investing in developing open source, and see what the parties get out of it:

The business gets:

• Free, mostly positive publicity if they respect the community
• Contributions & help with support from volunteers in the community
• The opportunity to sell products & services to supplement the open source core

The community gets:

• Some (hopefully) good free software – free from cost is good, freedom to modify & distribute is better
• Underwriting of costs for things like hardware & hosting for the community site, publicity at shows etc
• Access to extra support services – many corporate users find this a reassurance even if they don’t end up needing it because the community meets their needs, it’s a ‘safety net’ of sorts

It’s actually a pretty fair trade. In fact the lines between open source and business are often very blurred – both myself and others I know sit in both the business and volunteer camps, contributing time and code freely one day, selling products and services another – and again this is mostly because we’re small business owners with a blend of personal and commercial interest. Both sides are necessary, and both sides benefit.

But how exactly should a business which invests in developing open source make money? This is something I’ve given a lot of thought to over the last couple of years, and have been experimenting with. The glib answer from most Free Software types is that all software should be free, and we should all make our livings from support services. It’s a nice idea, but it suffers from one tiny flaw: it doesn’t work.

Why Services Can’t Support Core Development

A pure services model cannot support core development of an open source product because there is no business incentive to invest significantly in the core open source product.

If all your revenue comes from support (help-desks, training, deployment etc) or contract development (the result of which is almost always proprietary to the person hiring you), next to none of your revenue is related to forward development of the open source project itself. Sure there’s a halo effect of upgrades, but if the core project is stable enough (and if there is services demand, it always is anyway) it’s actually not that big.  It’s actually more profitable to be an outsider to the open source project selling those services, because you have no costs associated with maintaining the core, and just derive revenue from the value-added services – skimming off the cream, basically. Someone has to maintain that core though, otherwise no-one gets to do any skimming – but who? Volunteers in the community certainly contribute hugely, but it takes a certain level of commitment, continuity and stability from a core to really tie it all together into a cohesive whole. But there is no service I know of that involves customers paying towards this effort except donations, which while very welcome, are by no means enough to feed / clothe even one developer. You can divert money to core open source development from commercial services, but it’s hard to stay competitive that way.

The Misleading Example

Some people might point at Red Hat as proof that you can have a lot of core developers on staff while making a living from services, but they’d be wrong – Red Hat in fact makes the vast majority of its money selling a product (Red Hat Enterprise Linux), which has at times been thinly disguised as a support service.

And you know what? There’s absolutely nothing wrong with that. Red Hat have found a way to make a living while contributing massively to the open source community as developers, and I applaud that. But it’s important to recognise how they do it – not through services (although those no doubt supplement their income), but primarily via product sales. Again Matt Asay discussed this a few years back and I really wish I’d read his article earlier!

My Conclusions

I’ve been trying to make a services model work to help subsidise spending the level of time I want to on the OGRE core during daylight hours. It hasn’t worked that well – the work time I’ve managed to spend on OGRE (to free up my spare time a little more than in previous years) has been possible purely because I own my company and am willing to forgo a little paying work now and then, and there are no external investors to bark at me about it Most of the time though, I’m still working on OGRE in my spare time just like everyone else, I just feel a little more responsibility for it than most.

My services business pulls me away from core development more often than not, because I need to do a certain amount of it to keep me going. Funding working days spent on OGRE is like trying to constantly fill up a leaky bucket – tiring and never-ending. I need to do it to keep the level of commitment I want to the project without destroying my personal life, but it’s not sustainable. I’m glad I read articles like Matt’s because they give me confidence that it’s not just my failure to see a workable model – it’s that there probably isn’t one that is based on services alone.

So What to Do?

Clearly, services are a valuable part of any open source business, but if you’re developing the core, they can’t be your only source of revenue.  To grow a sustainable business that allows a level of stability and modest expansion both within and around the development of the open source core, you have to get involved in selling products, which ironically probably means non-open source.

There are 2 main options here – dual-licensing and closed extensions / tools.

Dual-licensing

Many free software advocates detest dual-licensing because it goes against their philosophy that all software should be free. That’s all very well, but I’m afraid the world is yet to be convinced on that front, and to be honest the impracticality of supporting development wholly through a services-only model undermines their case quite significantly and suggests it’s mostly rhethoric. Poster-children like Eric Raymond might be able to support their development activities by writing books and doing the speaking circuit, but few of us have that option.

Generally, I think having the option of choosing between a free license and an alternative license is good; people who want free software can access the software on those terms, those who wish to dodge those conditions can do so in return for financially supporting development. There are a couple of sticking points of course, the first being the way it’s presented – I’m still not keen on the way some companies say that if you’re a ‘commercial’ user you can’t use the open-source version. That’s actually inaccurate most of the time since the GPL doesn’t stop you making commercial apps, provided you adhere to the GPL conditions. The second is whether the community is happy to continue contributing when a company potentially makes revenue from releasing an alternative license. Generally I think the principle of fairness governs this, comparing investment by the company versus that of individuals in the community.

Selling Closed-source Add-ons And Extensions

This is simpler than dual-licensing since it has none of the sticky issues, but conversely since the revenue is related to development of add-on tools rather than the core, it to some extent suffers from the same issue as services, in that it doesn’t driectly fund core development. However, there’s a difference, in that unlike service provision there is growth potential available which is not necessarily directly linked to resource usage, leaving more potential for subsidising the open source project.

When you’re supplying contract development services for example, you only have a finite amount of contractor time to sell, and time spent contracting is time that cannot be spent developing the core – they’re constantly at odds and no matter how long you do it, that never changes. Conversely, once you’ve invested the time developing an add-on product, you can sell it to many people over time and generate revenue in parallel with diverting time to develop the open source core further, perhaps even in a self-sustaining cycle between core and add-on offerings. This kind of ebb-and-flow setup is generally impossible with service provision, unless you’re lucky enough to sell a lot of yearly support contracts that nobody calls in on (very unlikely).

My Way Forward

We already offer a dual-licensing set-up, but we deliberately don’t promote it heavily since most of the time, the LGPL is fine for most commercial uses, and I certainly don’t intend to start telling people they need a different license when they don’t. It’s possible this area might become more popular, but ironically as an open-source advocate you don’t want it to become too popular, because you’d really like for people to embrace open source wherever they can and not default to avoiding it. Therefore this is a useful occasional supplement (which so far has just covered legal costs and some hardware / hosting) but not a main line of business in our case.

Far more likely to succeed for me is the add-ons approach, and OgreSpeedTree is an example of this. I still distribute source code for this to licensees, because I believe as a developer that you should have access to rebuild libraries you base your work on – but even so it’s not open source, because you have to part with some money to get access to it.

So, whilst my contract and support services will continue, I will be exploring commercial add-on opportunities like OgreSpeedTree more over the next year I’m sure. OGRE will remain as my hub – although I certainly don’t rule out branching out to other things too (I always have ideas rolling about in my head, often in very different fields), OGRE is an 8-year project of mine so far and doesn’t show any signs of stopping yet, and I have a rather strong attachment to it. I’m certainly hoping to find a sustainable way to increase investment in the core open source offering, in collaboration with the community, while still putting food on the table and having a personal life.

Final Thought

Again I apologise for the length. I’ve learned from experience some of the boundaries and practicalities that go with blending open source and business from a core development perspective, and I’m sure I have plenty more to learn. With any luck you got something positive or at least thought provoking from this post.

And if you’re a Free Software die-hard wanting to lambaste me for being a sell-out; save your breath and instead educate me on your methods of making a living developing open source, because I’d love to know (unless you’re employed by Red Hat, in which case I already know!).  And no theorists/philosophers please – unless you’ve actually done it, I’m afraid your voice will carry little weight.