Blame Mikko, he started it. Or Stephe, who tagged me in the process of delivering his answer – Mårten’s chimed in as well. Either way, we’ve got another one of these meme games to play. This time the theme is lessons for open source firms: three to avoid, three to embrace.
So first, my three Do’s:
- Do Encourage Distribution:
I’m something of a broken record on this subject as many of you are already aware, but one of the most significant advantages you’re likely to enjoy as an open source firm – particularly while competing with less freely available closed source competitors – is distribution. We advise all of our clients to do everything in their power – whether it’s licensing, community outreach, product design, whatever – to remove barriers to entry to their product, thereby enabling the widest possible distribution.My canonical example in this space was the example in which I compared Geronimo to JBoss and Postgres to MySQL. All four projects are open source, but JBoss and MySQL were in the repository of the Linux distributions I tend to use, while Geronimo and Postgres were not. A small distinction, but an important one.
As an open source business you’re likely to have issues with conversion rates, and you may not be able to match closed source profit margins. It’s imperative, then, that you try and make up for those limitations with volume.
- Do Give Back:
Conversations around ‘professional’ or ‘commercial’ open source often focus, for understandable reasons, on the benefits of open source that accrue to the business. But it’s vital, in my opinion, to not take those benefits for granted, and to understand that they do not come without cost.The relationship that open source projects and vendors have with their community often extends beyond – sometimes far beyond – the traditional buyer/seller interaction. Like any serious relationship, though, it requires more work than one that’s more shallow in nature.
We recommend asking yourself the following question on a regular basis: how can you better serve your community? What can you do to help? Not to the detriment of your own enterprise, of course, but there’s always more that can be done. Maybe you can provide office space for meetups. Maybe some pro bono legal counseling. Maybe you can use your contacts and network to try and resolve issues. Maybe you can employ developers to work on a project that’s aligned with your business interest. Maybe you can sponsor travel for a developer to attend a conference.
Look around, you’ll find something. Don’t think of it as altruism, if that makes you uncomfortable: think of it as pragmatism. It’s kind of a truism that you get out of relationships only what you put into them; in my experience, open source is no exception.
- Do Make Friends:
Open source, as anybody who’s reasonably familiar with it can tell you, is not the elixir vitae of the software business. It cannot transform product dross into product gold, nor can it rocket you from obscurity to ubiquity overnight. It can assist in the journey to those ends, but you’ll need both a good product and help along the way.Setting aside the good product, because what kind of advice is that, be sure that you’re reaching out to products that complement your own – and perhaps even those that compete with it. Particularly if you’re a newly launched project, enlisting allies will be critical to your success or failure.
And now for some of the Don’t’s:
- Do Not Let Others Set the Rules:
Way back when open source was more interesting novelty than a phenonmenon poised to reshape the technology industry, you might have heard open source vendors pitch their wares on the basis that “our products are nearly identical, only our is – cue dramatic music – Open. Source. And did we mention, cheaper?”There are several problems with that sales approach, as you might guess, but the most alarming in my view is this: you’re allowing your competitor to set the rules of the contest. Meaning that they can be easily rigged in his favor, and that you’re assured of playing catch up.
If you’re delivering a product to a volume audience, certainly there are concessions that need to be made to user expectations and so on. But do not let that stifle your ability to innovate. MySQL became one of, if not the most popular relational database on the planet without the benefit of basic features like stored procedures and triggers (which have admittedly since been added). What does that tell you? That MySQL was able to compete, and compete effectively without trying to go feature by feature and function by function with their competitors.
- Do Not Build an Open Source Business According to a Closed Source Model:
While you’ll hear people state occasionally that there are effectively no differences between open and closed source firms, I do not agree. The distribution advantages mentioned above can manifest themselves in practical terms as significant advantages in marketing, sales and so on. These can and should impact the way that you staff up; like MySQL, you may want to question the need for the traditional high cost enterprise salesman – as well as the methods used to sell.Likewise your margins and conversion rate may impose important restrictions on comp plans, hiring plans, and more. You cannot and should not expect to staff your venture in the same manner that higher margin businesses can, because the economics are distinct.
- Do Not Forget Questions of Project Governance:
In the world of open source, license choices often get an undue share of the credit or blame for project success or failure. Though I do not subscribe to the notion that the license is unimportant – I think indeed it matters very much – project governance and the implications of that governance are at least as important if not more so.The choices made with respect to governance (and the tools that support it) can impact whether or not you’ll be able to accept outside contributions (thus ammortizing the cost of development across external parties), the volume and quality of contributions you might expect back, the relative strength and goodwill of your community, the adoption rate you can expect to see and so on. Its reach is, in other words, quite profound, and yet it can often be an afterthought following licensing conversations and choices.
As for whom I tag, let’s see…maybe a couple of the #redmonk regulars. Dalibor, Jdub, luisv, mjw, and Mike. If they choose to play, I guarantee you’ll want to hear what they have to say on the subject. Apologies, gentlemen – and that they’re all gentlemen. Apparently female technologists value their productivity enough to stay away from #redmonk 😉
