Many startups choosing open source are successful. Some of them were today at the Open Source Startup Summit organized by Bain Capital Ventures in San Francisco to talk about their business models, strategies, success and failures and how they build their communities.
I was expecting to see at least one or two open hardware startups in the mix but the event turned out to exclusively focused on software companies, including mobile and open data. Main concepts and practices of open hardware come from open source software so the event ended up being interesting and I thought I would share with you some of the main ideas coming from open source veterans.
These pieces of advice will apply to many open hardware projects.
Community is different from customers
Many speakers pointed it as an important reminder: your community is not necessarily the one who buys your product. It’s even rarely the case. Your open source community don’t buy but is still useful in the buying process thanks to word-of-mouth.
Don’t try to sell to your community, sell to companies. PHP co-creator Andi Gutmans talked about his beginnings at Technion Israel Institute of Technology where he spend his time creating PHP instead of studying. In the first 5 years, PHP reached a huge adoption (20M websites!) but didn’t have any monetization because it was not ready for enterprise. It’s only when he and his co-founder launched Zend and partnered with big companies such as IBM, Oracle or Microsoft to integrate PHP to their solutions that it really took off and became an actual business for them. Zend allowed them to go from a cool successful open source project to an enterprise-ready open source company. Car company FIAT for example, one of their clients, spend over 7 billion euros on their PHP framework.
Identify your customers, many chances are they are different from your community.
Commit to your open source community
Managing and nurturing your open source community takes a lot of time and requires a lot of commitment. Successful open source projects are a lot about process and governance. You need to over-communicate with your community and not impose one communication channel over the other. Use different tools available (IRC/freenode, mailing-lists, forums, also Bugzilla, Askbot, Stack Overflow) and repeat your messages many time.
Redhat Gluster Community Leader John Mark observed that many communities are now migrating from mailing-lists to web forums.
Facebook Open Source Lead James Pearce shared some management methods for launching open source projects inside your company. When an employee has an open source project he wants to release on the public Facebook’s GitHub repo, he has to follow a few steps (including branding, trademarking and testing) and commits to maintain his project. All projects have to always be maintained so the team uses a tool to keep track of who is in charge. When someone leaves the company or can’t take care of the project, he is replaced by someone else.
James noticed how branding plays a huge role in an open source project success:
“Making things look nice has a disproportionate effect.”
They even have a graphic designer specifically working on creating cool branding for their open source projects.
Don’t think of your open source project as a draft but as the actual product
The open source side of your product should be as good as your proprietary side, if there is one. Your clients should pay for support, not for better product quality. Puppet Labs CEO Luke Kanies explained his number 1 goal: build an open source product that is so good that it changes vendors’ expectations and make them buy the enterprise version for full support and deployment.
Your clients will pay for the pleasure of not having pain.
Access to source code is rarely the deciding factor for a sale. With open source, your customers don’t pay up front, they pay when they deploy and need support. You need to treat your open source project with the same discipline than any other product.
To finish this round-up of open source ideas, I’d like to share this quote that I found very interesting:
“Just because it’s open source doesn’t mean it’s open source.”
I like this idea. It basically says that it’s not because you put your code out there that you truly have an open source project. Open source means that you actually have a community of people interested and actively developing around your project.
As Sarah Novotny from NGINX said, “there are 2 types of open source projects: the ones that start with the code and the ones that start with the community”. Both can succeed but it’s easier if you start with a community. And it doesn’t have to be a huge one. Everyone agreed: there are usually only a handful of active members at the core of open source projects. Then, most members add value by using APIs, which create a big multiplication effect.
How do you think these ideas apply to your open hardware project?