http://opensource.com/business/15/4/best-practices-for-bootstrapping-an-open-source-business
Image by :
opensource.com
Go
to the networking and speaking events of any local startup community in
America and you'll quickly discover a dominant theme: investment. Read
any startup news site and you'll see the same hyper-focus on
fundraising. Websites like AngelList and CrunchBase
are wholly dedicated to facilitating capital acquisition and
documenting who's succeeded at it. With so much of the conversation in
these circles centered around how to attract early-stage investment
through an image of extreme profitability, open source businesses easily
fly below the radar.
I've felt this tension firsthand. My company, PencilBlue, an open source content management system, was instantly dismissed by a well-known venture capitalist because, as he put it, "No website creation tool makes money unless it completely gets rid of the need for developers." This is someone who made seed investments in multiple household-name tech startups, and he had no clue that more than 70% of all websites are created by developers and that the $21 billion web development industry is ruled by open source platforms.
That open source startups are hard to find in the investment-first ecosystem is not surprising, because they're usually started by people who actually build the product. Most of the time, seeking early stage investment for an open source product doesn't make financial sense. On the other hand, there's much to be gained from the business and marketing knowledge in local startup communities, so being sequestered from them can put open source developers at a disadvantage.
If you're bootstrapping your open source company, here are three tips to help you prepare for that ultimate transition from development project to fully fledged business.
That's why having at least one developer partner when building an open source product is so important. Having someone capable of questioning your decisions and giving new perspectives is invaluable, and it also makes you accountable to someone. Projects with multiple developers have a much higher completion rate because team members tend to keep each other from slacking off.
We made this mistake at PencilBlue, not releasing our software until it was a fully functioning, top to bottom CMS. While you could build a complete website with PencilBlue on day one, we quickly found out that it wasn't the type of website that a huge chunk of our potential users (namely, in the enterprise sector) wanted.
As a result, we've spent the better part of a year fulfilling feature requests from enterprise and other users. Granted, we would have spent the same amount of time adding features, regardless of when we released, but we would have spent less time changing or backing out functionality that we wrongly assumed users wanted.
The benefits of releasing a market-ready product didn't outweigh the efficiency we would have gained by quickly releasing an open source prototype.
Even if you want to make a business out of your open source software, your initial release doesn't have to be a minimum viable product, as it usually does with commercial software. You can release a functional prototype and allow the community to help you shape what ultimately goes to market.
I've felt this tension firsthand. My company, PencilBlue, an open source content management system, was instantly dismissed by a well-known venture capitalist because, as he put it, "No website creation tool makes money unless it completely gets rid of the need for developers." This is someone who made seed investments in multiple household-name tech startups, and he had no clue that more than 70% of all websites are created by developers and that the $21 billion web development industry is ruled by open source platforms.
That open source startups are hard to find in the investment-first ecosystem is not surprising, because they're usually started by people who actually build the product. Most of the time, seeking early stage investment for an open source product doesn't make financial sense. On the other hand, there's much to be gained from the business and marketing knowledge in local startup communities, so being sequestered from them can put open source developers at a disadvantage.
If you're bootstrapping your open source company, here are three tips to help you prepare for that ultimate transition from development project to fully fledged business.
1. Don't do this on your own
Take a look at most developers' personal projects and you'll find that they're usually very personal. We have a tendency to base our side work on the one thing we can't base our daily work on, and often this is why so many open source side projects quickly fade into obscurity. The developer focuses so much energy on writing "elegant" software that they forget to release usable software. We can be so bent on our own use-case that we forget to build something for a realistic user base.That's why having at least one developer partner when building an open source product is so important. Having someone capable of questioning your decisions and giving new perspectives is invaluable, and it also makes you accountable to someone. Projects with multiple developers have a much higher completion rate because team members tend to keep each other from slacking off.
2. Have a revenue model in mind from the beginning
Businesses that don't have any way to make money aren't really businesses at all. If you plan on turning a profit with your product, then you should have revenue strategies in place from the beginning, and build your open source company around them. Here are seven of the most common open source revenue models:- Razor/razor blade: One of the most popular revenue models is to give the initial product away for free, but charge for added features that many users need. This most often manifests in open source as a store to purchase extensions to a platform.
- Hosting fees: This model is common among blogging platforms, like WordPress and Ghost, where customers can purchase turnkey website hosting with the platform developer. Although hosting services can be very profitable for closed source products, there's a flaw in using it as a main source of revenue with open source platforms. Because everyone has free access to your source code, any third-party provider can offer their own hosting solution and potentially undercut you.
- Closed-source enterprise version: If your product has enterprise users, offering them a commercial version of your software with enhancements for their class of needs can be very lucrative. Magento is a prime example of this revenue model.
- Partner programs: Because open source software is often used as a tool for developers to do their own client work, many will pay to be placed on your website as trusted partners, ensuring a rise in inbound prospects.
- Training and certification: How do you ensure that your partners meet the requirements for recommendation on your site? Through for-profit training and certification programs. Higher tiers of partner programs often require an exponentially growing number of certified developers and salespeople on an organization's staff to qualify.
- Product management and support: If your product solves a complicated problem, chances are at least one full-time employee is needed to manage it. Enterprise customers are more likely to outsource that management to your company, or to pay for a full-time, dedicated support person.
- Resellers (requires the GPL): Some companies may want to integrate your product into their own offering, or even slightly modify it and flat out sell it as their own. If you release your product under the GNU General Public License, those companies will be legally obligated to either open source anything using your product, or license the software directly from you.
3. Release early, improve regularly
One can argue the finer points of lean startup methodology, but not the fact that open source software sees a higher rate of iterative releases than other products. Community debugging and code contributions are the hallmark of open source, and the longer you wait to benefit from them, the more your open source company suffers.We made this mistake at PencilBlue, not releasing our software until it was a fully functioning, top to bottom CMS. While you could build a complete website with PencilBlue on day one, we quickly found out that it wasn't the type of website that a huge chunk of our potential users (namely, in the enterprise sector) wanted.
As a result, we've spent the better part of a year fulfilling feature requests from enterprise and other users. Granted, we would have spent the same amount of time adding features, regardless of when we released, but we would have spent less time changing or backing out functionality that we wrongly assumed users wanted.
The benefits of releasing a market-ready product didn't outweigh the efficiency we would have gained by quickly releasing an open source prototype.
Even if you want to make a business out of your open source software, your initial release doesn't have to be a minimum viable product, as it usually does with commercial software. You can release a functional prototype and allow the community to help you shape what ultimately goes to market.
No comments:
Post a Comment