In a recent article on Opensource.com, I introduced Data Geekery, the company behind jOOQ, and talked about the challenges we faced when transitioning our products from open source to a revenue-based business model last year. Our team learned a lot about running a business in general as well as making a big transition in our structure. Here, I'll share the top 5 lessons we learned that every open source business making this kind of change should know.
Make it a business from the beginning
Many great open source projects start out as a geeky weekend project. A proof-of-concept. A toy project. But, don't wait too long to make it a business if you get to the point of having a long-term vision for it. It's fine to measure you're success, hours, etc., but don't hestitate too long take that next step. If you're spending long hours on a project and seeing success, make it a business now.
For Data Geekery, we find great passion in our work and naturally know a lot about Java, JDBC, and SQL. From the very beginning, our customers valued our knowledge and consumed it freely, without contributing, anonymously (banks, insurance companies, etc.) under the ASL 2.0 license.
Use this early time to practice making your hobby a business. Be self-confident enough to sell tailor-made extensions, consulting, support, and maybe a lightweight "professional" or "enterprise" extension. Reach out to your customers. Someone will buy the extension. Maintaining an open source project doesn't mean that everything needs to be free. Don't under value yourself!
In fact, you might learn that by selling something, anything, you will get even more of a reward out of your work. Because by selling something, you strengthen your greater vision, instead of just focusing on the details of your every day work, like fixing bugs and addressing feature requests. It adds much more purpose and thus, pleasure to your project.
Make your users your customers from the beginning
When you start out with a project, see your users as your early adopters. See them as your biggest fans. They're the ones who are buying into your product in one way or another, even if your product is free. Treat them like customers, treat them like you want them to keep coming back for more.
No matter if you're planning to create a support-based business around free-as-in-freedom open source, or a dual license-based business around free-as-in-beer open source, your early adoptors will follow you if you transition and change.
Make your tool a product from the beginning
Whether you consider your work a toy project or a proof-of-concept for a greater vision, build it as though it already needs to be a commercial-quality product. You will have customers, sooner than you might want even! And, they will be demanding, even if your product is free. They deserve quality in all aspects because, like I said before, your early adopters are your customers.
Pay attention to legal details
Make a clear decision about licensing from the beginning. Do you want to maintain free software as free as in freedom or as in free as in beer? Both are viable ways to operate an open source business, and you can read more about the difference here. Your idealogical convictions will play a role, of course, but don't make the mistake of ignoring this important legal decision.
If you want to distribute free as in beer software, then be sure to get your copyright straight. Have your contributors sign a Contributor License Agreement, potentially transferring copyright expressly to you, helping you avoid due diligence cases later on.
If you want to distribute free as in freedom software, a Contributor License Agreement is also the right way to protect the business from any liabilities caused by potential copyright, patent, or trademark infringements from your contributors.
For us, Data Geekery, we had only a few contributors who contributed very specific code, so it was easy to retrofit copyright.
Share not only code, but also experience
Data Geekery didn't only share code, but also our experience. Trust me, this is key. Whatever weird SQL or weird Java issue we have discovered over the last four years of operating as a business, we have posted on our blog and contributed to Hacker News, Reddit, DZone, Stack Overflow, and many other information hubs.
Two reasons why we did this:
- As an open source company, we believe in sharing our knowledge. We license our blog posts under the Creative Commons BY-SA 3.0 license, and we know that we have readers who get a lot out of our blog and our knowledge, but who do not use our products. That's ok because...
- There is no better marketing than content marketing. If you can write/talk about it, then your business and product are more likely in the readers' eyes to product excellent results in real life. Even if readers don't use your product now, they may later, or they may pass your expertise on to their friends.
The most rewarding lesson we've learned is to just try things. Do you have a wacky new idea that challenges the status quo? Work on it. Test it. People will sign up and give you feedback. Be open to that.
2 Comments