4 ms·

Ask HN: Business models for single dev OSS

25 points by chuhnk 10y ago

Hey HN, I've been working on an OSS project called Micro (https://github.com/micro/micro) for over a year now which has seen production use by a number of companies. I was fortunate enough to get an enterprise company to sponsor the OSS development of the project which allows me to work on it full time but I'm now starting to think about long term sustainability and next steps. I've read about Mike Perham's experiences with Sidekiq and am interested to hear more from the HN community about appropriate business models for OSS as a single developer. I imagine there are countless developers here who would also probably like to hear about ways to build a sustainable business around OSS. I'm currently thinking about the dual-licensing model that aligns with what Cockroach Labs plan to do https://www.cockroachlabs.com/blog/how-were-building-a-business-to-last/ Please share your thoughts and experiences on the subject. Cheers Asim

jetti 10y ago
I have no experience in this so take my opinion with a grain of salt but what about charging for support contracts? While the project is open source and anybody could make changes/fixes it isn't always an option for a company to have somebody jump in the code to try and get a handle of the codebase to make certain changes. If they had a contract with you, somebody who is intimately familiar with the codebase, then bugs and changes could be implemented faster and better.
- tonyedgecombe 10y ago
  Doesn't that just make you a technical support person? I don't know about the OP but selling support sounds like hell to me.
  - jetti 10y ago
    It does. But a software company of 1 will always make you the technical support person, unless you just don't want to give support.
    - chuhnk 10y ago
      Echoing tonyedgecombe, I'm not interested in the support model. I've spent a number of years as a sysadmin and developer on call, it's not the most enjoyable part of the job. Appreciate the comment though.
      - jsegura 10y ago
        I know that pain very well, but for me it's difficult to think in a dual licensing model without providing support. How it will look like?
        tonyedgecombe 10y ago
        There is a difference between providing support for something you sell and making it the whole of your business. I've been running an isv for years and support rarely takes more than 30 minutes in a day.
- mperham 10y ago
  Charging for support incentivizes you to provide poor documentation and frustrates the customer.
lukaseder 10y ago
Dual licensing is a great option. I.e. don't wait for someone to be "generous" and "pitiful". Demand money. Make it a business. Screw OSS, because after all, you're not doing it for the philosophy or Richard Stallman's beard, you're doing it to support your family. And you worked hard for it. The only reason why you should pick OSS is because it gets you more market traction more quickly (but also, you're commoditising your own product by making it free, so how to increase its value again?) We've been quite successful with it for jOOQ (http://www.jooq.org http://www.jooq.org). Here's some reading on how we fared (and why we should've done it earlier): - https://opensource.com/business/14/1/how-to-transition-open-source-to-revenue https://opensource.com/business/14/1/how-to-transition-open-... - https://opensource.com/business/14/1/5-lessons-open-source-revenue-based-model https://opensource.com/business/14/1/5-lessons-open-source-r...
- chuhnk 10y ago
  Thanks for sharing your experience. Curious to know, how did you determine pricing for jOOQ?
  - lukaseder 10y ago
    There are different things we did (emphasis on "we". YMMV): - Check prices of other products in the same market (by market, I don't mean ORM in our case but all libraries, including UI libraries like Sencha's products, or ZK) - Never compare with prices of products from other markets (e.g. tools in our case. The value proposition of a library cannot be compared to that of a tool like IntelliJ, or a database like Oracle). - Ask existing users (that's gold!) - A bit of this: http://dilbert.com/strip/2010-10-20 http://dilbert.com/strip/2010-10-20 - Testing different price plans (express, professional, enterprise) - Testing different subscription terms (monthly, yearly, perpetual) - Testing different discounts (hint: don't offer discounts in a B2B product) The biggest win (for us) was to introduce tiered pricing (check the bottom of https://www.jooq.org/download/price-plans https://www.jooq.org/download/price-plans), as this got rid of discount discussions which are humiliating for both parties without adding real value, and helps high volume customers keep admin work low. They don't want to count the exact number of licenses needed. What we don't do: - Offer special reseller discounts (I don't see why we should, resellers would work with us nonetheless - they can add their margins on top of our price) - Have country-specific pricing (that's just too complicated to track and validate, at least for us) - Raise prices for existing customers (not yet, and no plans yet), even when they purchase more licenses. - Probably tons of other things we hadn't thought of (yet)
mperham 10y ago
Kudos for even thinking about the long term and sustainability. So many people just create a project with nothing more than the first/next release in mind. Good luck, whatever you do.
- chuhnk 10y ago
  Thanks much appreciated. It was always a thought from day 1 knowing the way OSS goes. Hopefully dual licensing proves to be a good option.
jsegura 10y ago
I've been following your project since a year ago and I only have to congratulate you for moving forward. I think that Dual licensing is a good way to go but, just to know, have you ever thought in providing some components on a privative way?
- lukaseder 10y ago
  What's the difference between dual licensing and "providing some components in a private (= restriced licensed) way" ?

25 points by chuhnk 10y ago

jetti 10y ago

I have no experience in this so take my opinion with a grain of salt but what about charging for support contracts? While the project is open source and anybody could make changes/fixes it isn't always an option for a company to have somebody jump in the code to try and get a handle of the codebase to make certain changes. If they had a contract with you, somebody who is intimately familiar with the codebase, then bugs and changes could be implemented faster and better.

tonyedgecombe 10y ago
Doesn't that just make you a technical support person? I don't know about the OP but selling support sounds like hell to me.
- jetti 10y ago
  It does. But a software company of 1 will always make you the technical support person, unless you just don't want to give support.
  - chuhnk 10y ago
    Echoing tonyedgecombe, I'm not interested in the support model. I've spent a number of years as a sysadmin and developer on call, it's not the most enjoyable part of the job. Appreciate the comment though.
    - jsegura 10y ago
      I know that pain very well, but for me it's difficult to think in a dual licensing model without providing support. How it will look like?
      - tonyedgecombe 10y ago
        There is a difference between providing support for something you sell and making it the whole of your business. I've been running an isv for years and support rarely takes more than 30 minutes in a day.
mperham 10y ago
Charging for support incentivizes you to provide poor documentation and frustrates the customer.

lukaseder 10y ago

Dual licensing is a great option. I.e. don't wait for someone to be "generous" and "pitiful". Demand money. Make it a business. Screw OSS, because after all, you're not doing it for the philosophy or Richard Stallman's beard, you're doing it to support your family. And you worked hard for it. The only reason why you should pick OSS is because it gets you more market traction more quickly (but also, you're commoditising your own product by making it free, so how to increase its value again?) We've been quite successful with it for jOOQ (http://www.jooq.org http://www.jooq.org). Here's some reading on how we fared (and why we should've done it earlier): - https://opensource.com/business/14/1/how-to-transition-open-source-to-revenue https://opensource.com/business/14/1/how-to-transition-open-... - https://opensource.com/business/14/1/5-lessons-open-source-revenue-based-model https://opensource.com/business/14/1/5-lessons-open-source-r...

chuhnk 10y ago
Thanks for sharing your experience. Curious to know, how did you determine pricing for jOOQ?
- lukaseder 10y ago
  There are different things we did (emphasis on "we". YMMV): - Check prices of other products in the same market (by market, I don't mean ORM in our case but all libraries, including UI libraries like Sencha's products, or ZK) - Never compare with prices of products from other markets (e.g. tools in our case. The value proposition of a library cannot be compared to that of a tool like IntelliJ, or a database like Oracle). - Ask existing users (that's gold!) - A bit of this: http://dilbert.com/strip/2010-10-20 http://dilbert.com/strip/2010-10-20 - Testing different price plans (express, professional, enterprise) - Testing different subscription terms (monthly, yearly, perpetual) - Testing different discounts (hint: don't offer discounts in a B2B product) The biggest win (for us) was to introduce tiered pricing (check the bottom of https://www.jooq.org/download/price-plans https://www.jooq.org/download/price-plans), as this got rid of discount discussions which are humiliating for both parties without adding real value, and helps high volume customers keep admin work low. They don't want to count the exact number of licenses needed. What we don't do: - Offer special reseller discounts (I don't see why we should, resellers would work with us nonetheless - they can add their margins on top of our price) - Have country-specific pricing (that's just too complicated to track and validate, at least for us) - Raise prices for existing customers (not yet, and no plans yet), even when they purchase more licenses. - Probably tons of other things we hadn't thought of (yet)

mperham 10y ago

Kudos for even thinking about the long term and sustainability. So many people just create a project with nothing more than the first/next release in mind. Good luck, whatever you do.

chuhnk 10y ago
Thanks much appreciated. It was always a thought from day 1 knowing the way OSS goes. Hopefully dual licensing proves to be a good option.

jsegura 10y ago

I've been following your project since a year ago and I only have to congratulate you for moving forward. I think that Dual licensing is a good way to go but, just to know, have you ever thought in providing some components on a privative way?

lukaseder 10y ago
What's the difference between dual licensing and "providing some components in a private (= restriced licensed) way" ?