6 ms·

I think there are likely a variety of contractual options other than "24/7 phone support" which businesses would be happy to pay for, on an ongoing basis. For

by patio11 13y ago

I think there are likely a variety of contractual options other than "24/7 phone support" which businesses would be happy to pay for, on an ongoing basis. For example, you could charge $500 plus $100 per year for "maintenance", and not be any more specific than "the software will be maintained in an ongoing fashion", and now you won't be starting from $0 next January 1st. As someone who has started from $0 every January 1st for the last 7 -- don't do it! It sucks! Congrats, though -- Sidekiq is one of the few commercial OSS offerings that I know of doing well in the Ruby/Rails ecosystem. Most of the others just act as friendcatchers for consulting, too.

WestCoastJustin 13y ago
> charge $500 plus $100 per year for "maintenance", and not be any more specific than "the software will be maintained in an ongoing fashion" I work at a mega corp, and I cannot echo this enough, we have tons of "maintenance" agreements for hardware and software of all sorts, $100 is not even in the noise level for some of these agreements! Software needs to be maintained, get this done upfront, it is a total pain in the but to have something fail, and then try and push through a purchase for "maintenance" after the fact. This means that I have to get a quote, get my boss to sign off, get purchasing in the loop, etc, etc. Just have this as an annual agreement and it will get processed like everything else. 10 years later, someone will ask, who uses this, and no one will know, and it will get renewed, just because they don't want something to fail ;)
- eru 13y ago
  And since the bureaucratic overhead is so high, you better ask for enough money to make it worthwhile.
  - GFischer 13y ago
    Remember the often quoted advice from Joel Spolsky: http://www.joelonsoftware.com/articles/CamelsandRubberDuckies.html http://www.joelonsoftware.com/articles/CamelsandRubberDuckie... Enterprise sales cycle is EXPENSIVE, so, while the actual cost of your service may be much less, you have to pay for the ten airplane flights and meetings and hotel rooms before you close your sale (and add a few one afterwards for good measure). also http://cdixon.org/2010/02/06/selling-to-enterprises/ http://cdixon.org/2010/02/06/selling-to-enterprises/ "Enterprise-focused VC’s sometimes refer to products priced between (roughly) $5k and $100K as falling in the “valley of death.” Above $100K, you might be able to make a profit given the cost of sales. Below $5k you might be able to market your product, hence have a very low cost of sales" I'm not sure if all of that advice applies to a Ruby gem... big freaking enterprises don't use Ruby that much. That said, it's a great success story :)
    - Mikeb85 13y ago
      > big freaking enterprises don't use Ruby that much. Of course not. Ruby is slow, dynamic, and uses a ton of magic. Ruby is inherently more suited to smaller developers, who can use it to generate code, run scripts, embed it in things, and make use of the magic to be productive (things like generating C++, Fortran, or HTML).
      - justin_vanw 13y ago
        I think you have it backwards. Firstly, I am not a huge fan of Ruby, but ruby isn't magic itself, just Rails, which is a piece of crap. Secondly, 'big enterprises' tend to employ a lot of mediocre or poor developers, and as a result have gigantic code bases to do more poorly what might be done with 1/100th as much code. You say Ruby devs use 'magic' like code generation. Big Enterprises use copy and paste. Also, in case you woke up from a coma, it's not 1997 and everyone generates HTML. What do you think 'big enterprises' do? Type the same header into 50 million pages?
        Mikeb85 13y ago
        > Firstly, I am not a huge fan of Ruby, but ruby isn't magic itself, just Rails, which is a piece of crap. I'll agree that Rails is crap, but Ruby most definitely isn't. There's some interesting stuff going on in the Ruby world, mostly coming out of Japanese universities and research institutes. And Ruby certainly does have bits of magic, which is why it's so easy to write DSLs and code generators... Not saying other languages can't do it, but in Ruby everything is made pretty easy.
        foobarian 13y ago
        Ruby itself may not be magic but it encourages magic frameworks which end up extremely hard to maintain under turnover. I guess part of the problem is that when you have a couple of smart developers they try to outdo each other in the cleverness of their code, so it essentially ends up being write-only software.
    - marcosdumay 13y ago
bjelkeman-again 13y ago
We took a different approach with http://akvo.org http://akvo.org I noticed the really poor use of Internet systems in international development aid. More than $120 Bn is spent yearly on this, and nobody really has a clue where the money goes. There is no useful overview. So we started building tools to fix that and supply them as a paid for service. Everything we build is open source software. We have 45+ people working on this, with paying partners such as the World Bank, UNICEF, Liberian government, Mars Chocolate and many hundreds more. It is not your ordinary business model, but it works and we are growing. You can make open source software and earn a decent living.
- rushabh 13y ago
  Wow. This is pretty inspiring. We at https://erpnext.com https://erpnext.com have been looking to help govt agencies implement our Open Source ERP, but lack a forum where we can connect with such needs. Can you suggest us a way forward. I think our product can serve a great need for government organizations.
  - deleted 13y ago
    [deleted]
  - icebraining 13y ago
    You don't seem to do any custom development / extensions, which according to our experience¹ implementing OpenERP solutions, it's pretty much mandatory for any large company or governmental agency. ¹ http://www.thinkopensolutions.com/SoluçõesOpenERP/CasosdeSucesso.aspx http://www.thinkopensolutions.com/SoluçõesOpenERP/CasosdeSuc... (Portuguese)
    - rushabh 13y ago
      We initially burnt hands doing custom development so stay away these days. 90% of our revenue comes from cloud hosting, which is opposite of OpenERP (which gets 90% of revenue via Partners). If we do custom development, product will suffer, so we are staying out. But we are happy to consider it if it really makes sense. Will be happy to hear your views though (will send you a separate mail on this).
FooBarWidget 13y ago
Unfortunately, support models only work for a limited set of software. It happens to work for Red Hat. For a while, we tried making money off support contracts for Phusion Passenger. The amount of money we made with that put us far below minimum wage. It turns out that with Phusion Passenger, nobody needs good support. Some people may have trouble setting it up (mostly people who are not familiar with Unix, and don't have money for a support contract anyway) but for the vast majority of users, Phusion Passenger just works and never stops working. By making our software stable and user friendly, we were essentially shooting ourselves in the foot revenue-wise. We didn't want to cripple Phusion Passenger to make more money off support, so we ended up selling Phusion Passenger Enterprise which only differentiates on features, not stability. This latter model turns out to be far more successful and has skyrocketed open source development to new highs.
- danielweber 13y ago
  For almost 20 years I've had this problem with "give away open source, sell the support," because I thought if it works well people don't need support. I've learned a lot in those 20 years that made me realize that it's not that simple, but stories like yours make me keep coming back to it. On the other hand, how hard have you tried to market support contracts?
  - bjelkeman-again 13y ago
    We at Akvo couldn't do what we do if we just lived of support. We run the software as a service and charge money for it. We have some advantages that makes it possible to do this. But only support wouldn't work for us.
tjbiddle 13y ago
Hey Patrick! Just wanted to say I love following your blog - And this is definitely something that's been engrained in my mind after reading it, and I'm glad you've reiterated here. If anyone would like to follow him - here's a link to an arbitrary archived newsletter that he's published where you can sign up: https://training.kalzumeus.com/newsletters/archive/sources_of_revenue_growth https://training.kalzumeus.com/newsletters/archive/sources_o...
wslh 13y ago
My company has two good types of yearly contracts for "advanced support" oriented to large companies. In both we can charge a good price because they support complex technologies. One is our own product that is very costly to maintain (reverse engineering third party applications) and some customers agree that they need to have this additional service. Another one is for complex application virtualization. For example, we give the technology for virtualizing IE6 on Windows 7 and 8 but some Microsoft updates break the solution and the company needs to have an "insurance" against that. Simple support gives a lot of headache.
Tyrannosaurs 13y ago
I agree with the idea but not the don't be specific. The main thing I'd say about "maintenance agreements" is make it clear what they are and aren't getting. Does it cover upgrades to work with new versions of another OS/framework/database whatever? Does it cover new functionality? Does it cover bug fixes? If so is there an SLA? Is it limited in some way? X incidents? Y hours of your time? There are such a range of these things that if you're not careful you end up with disappointed customers when it could easily have been avoided. That's not to say it has to be comprehensive. Corporate organisations will pay a lot for a small amount of peace of mind, but make it clear.

by patio11 13y ago

WestCoastJustin 13y ago

> charge $500 plus $100 per year for "maintenance", and not be any more specific than "the software will be maintained in an ongoing fashion" I work at a mega corp, and I cannot echo this enough, we have tons of "maintenance" agreements for hardware and software of all sorts, $100 is not even in the noise level for some of these agreements! Software needs to be maintained, get this done upfront, it is a total pain in the but to have something fail, and then try and push through a purchase for "maintenance" after the fact. This means that I have to get a quote, get my boss to sign off, get purchasing in the loop, etc, etc. Just have this as an annual agreement and it will get processed like everything else. 10 years later, someone will ask, who uses this, and no one will know, and it will get renewed, just because they don't want something to fail ;)

eru 13y ago
And since the bureaucratic overhead is so high, you better ask for enough money to make it worthwhile.
- GFischer 13y ago
  Remember the often quoted advice from Joel Spolsky: http://www.joelonsoftware.com/articles/CamelsandRubberDuckies.html http://www.joelonsoftware.com/articles/CamelsandRubberDuckie... Enterprise sales cycle is EXPENSIVE, so, while the actual cost of your service may be much less, you have to pay for the ten airplane flights and meetings and hotel rooms before you close your sale (and add a few one afterwards for good measure). also http://cdixon.org/2010/02/06/selling-to-enterprises/ http://cdixon.org/2010/02/06/selling-to-enterprises/ "Enterprise-focused VC’s sometimes refer to products priced between (roughly) $5k and $100K as falling in the “valley of death.” Above $100K, you might be able to make a profit given the cost of sales. Below $5k you might be able to market your product, hence have a very low cost of sales" I'm not sure if all of that advice applies to a Ruby gem... big freaking enterprises don't use Ruby that much. That said, it's a great success story :)
  - Mikeb85 13y ago
    > big freaking enterprises don't use Ruby that much. Of course not. Ruby is slow, dynamic, and uses a ton of magic. Ruby is inherently more suited to smaller developers, who can use it to generate code, run scripts, embed it in things, and make use of the magic to be productive (things like generating C++, Fortran, or HTML).
    - justin_vanw 13y ago
      I think you have it backwards. Firstly, I am not a huge fan of Ruby, but ruby isn't magic itself, just Rails, which is a piece of crap. Secondly, 'big enterprises' tend to employ a lot of mediocre or poor developers, and as a result have gigantic code bases to do more poorly what might be done with 1/100th as much code. You say Ruby devs use 'magic' like code generation. Big Enterprises use copy and paste. Also, in case you woke up from a coma, it's not 1997 and everyone generates HTML. What do you think 'big enterprises' do? Type the same header into 50 million pages?
      - Mikeb85 13y ago
        > Firstly, I am not a huge fan of Ruby, but ruby isn't magic itself, just Rails, which is a piece of crap. I'll agree that Rails is crap, but Ruby most definitely isn't. There's some interesting stuff going on in the Ruby world, mostly coming out of Japanese universities and research institutes. And Ruby certainly does have bits of magic, which is why it's so easy to write DSLs and code generators... Not saying other languages can't do it, but in Ruby everything is made pretty easy.
      - foobarian 13y ago
        Ruby itself may not be magic but it encourages magic frameworks which end up extremely hard to maintain under turnover. I guess part of the problem is that when you have a couple of smart developers they try to outdo each other in the cleverness of their code, so it essentially ends up being write-only software.
  - marcosdumay 13y ago

bjelkeman-again 13y ago

We took a different approach with http://akvo.org http://akvo.org I noticed the really poor use of Internet systems in international development aid. More than $120 Bn is spent yearly on this, and nobody really has a clue where the money goes. There is no useful overview. So we started building tools to fix that and supply them as a paid for service. Everything we build is open source software. We have 45+ people working on this, with paying partners such as the World Bank, UNICEF, Liberian government, Mars Chocolate and many hundreds more. It is not your ordinary business model, but it works and we are growing. You can make open source software and earn a decent living.

rushabh 13y ago
Wow. This is pretty inspiring. We at https://erpnext.com https://erpnext.com have been looking to help govt agencies implement our Open Source ERP, but lack a forum where we can connect with such needs. Can you suggest us a way forward. I think our product can serve a great need for government organizations.
- deleted 13y ago
  [deleted]
- icebraining 13y ago
  You don't seem to do any custom development / extensions, which according to our experience¹ implementing OpenERP solutions, it's pretty much mandatory for any large company or governmental agency. ¹ http://www.thinkopensolutions.com/SoluçõesOpenERP/CasosdeSucesso.aspx http://www.thinkopensolutions.com/SoluçõesOpenERP/CasosdeSuc... (Portuguese)
  - rushabh 13y ago
    We initially burnt hands doing custom development so stay away these days. 90% of our revenue comes from cloud hosting, which is opposite of OpenERP (which gets 90% of revenue via Partners). If we do custom development, product will suffer, so we are staying out. But we are happy to consider it if it really makes sense. Will be happy to hear your views though (will send you a separate mail on this).

FooBarWidget 13y ago

Unfortunately, support models only work for a limited set of software. It happens to work for Red Hat. For a while, we tried making money off support contracts for Phusion Passenger. The amount of money we made with that put us far below minimum wage. It turns out that with Phusion Passenger, nobody needs good support. Some people may have trouble setting it up (mostly people who are not familiar with Unix, and don't have money for a support contract anyway) but for the vast majority of users, Phusion Passenger just works and never stops working. By making our software stable and user friendly, we were essentially shooting ourselves in the foot revenue-wise. We didn't want to cripple Phusion Passenger to make more money off support, so we ended up selling Phusion Passenger Enterprise which only differentiates on features, not stability. This latter model turns out to be far more successful and has skyrocketed open source development to new highs.

danielweber 13y ago
For almost 20 years I've had this problem with "give away open source, sell the support," because I thought if it works well people don't need support. I've learned a lot in those 20 years that made me realize that it's not that simple, but stories like yours make me keep coming back to it. On the other hand, how hard have you tried to market support contracts?
- bjelkeman-again 13y ago
  We at Akvo couldn't do what we do if we just lived of support. We run the software as a service and charge money for it. We have some advantages that makes it possible to do this. But only support wouldn't work for us.

tjbiddle 13y ago

Hey Patrick! Just wanted to say I love following your blog - And this is definitely something that's been engrained in my mind after reading it, and I'm glad you've reiterated here. If anyone would like to follow him - here's a link to an arbitrary archived newsletter that he's published where you can sign up: https://training.kalzumeus.com/newsletters/archive/sources_of_revenue_growth https://training.kalzumeus.com/newsletters/archive/sources_o...

wslh 13y ago

My company has two good types of yearly contracts for "advanced support" oriented to large companies. In both we can charge a good price because they support complex technologies. One is our own product that is very costly to maintain (reverse engineering third party applications) and some customers agree that they need to have this additional service. Another one is for complex application virtualization. For example, we give the technology for virtualizing IE6 on Windows 7 and 8 but some Microsoft updates break the solution and the company needs to have an "insurance" against that. Simple support gives a lot of headache.

Tyrannosaurs 13y ago

I agree with the idea but not the don't be specific. The main thing I'd say about "maintenance agreements" is make it clear what they are and aren't getting. Does it cover upgrades to work with new versions of another OS/framework/database whatever? Does it cover new functionality? Does it cover bug fixes? If so is there an SLA? Is it limited in some way? X incidents? Y hours of your time? There are such a range of these things that if you're not careful you end up with disappointed customers when it could easily have been avoided. That's not to say it has to be comprehensive. Corporate organisations will pay a lot for a small amount of peace of mind, but make it clear.