How Many Open Source Developers Sabotage Themselves

Despite that I have sold hundreds of titles over the years of very closed source products, I respect and support open source projects. I use open source projects every day. There are numerous open source products I pay for, too. That might seem a bit strange to those who see open source being synonymous with free. An open source project can be free, but its in its usage where it has value – its got to work when you need it to work – and that is the value point that many open source developers fail to grasp.

One of my favorite open source projects is Joomla. Its an incredible content management system, and it has a great third party add-on community – most of which release their add-ons under the GPL (there are reasons for this, not applicable here).  Ive bought a number of these. But since they are GPL, I should be able to get access to the source code and effectively get them for free, right? What and why pay?

Many vendors come up with service based plans – which sad to say, mostly fail to deliver value. They disappoint the customer, and I suspect they ultimately disappoint the vendor. Here are some things they do wrong, and also how they can fix the problem.

  • Provide meaningful fixes. If you charge a subscription fee for access and support, you should be continuously updating the product. Short cycles with 1-2 main new features and lots of user requested fixes. That means lots of continuous updates. This style also makes subscription payers believe they are getting value for the cost.
  • Fix the stupid stuff. There are issues which have workarounds, but that doesn’t resolve the inconvenience you are foisting on your customers. Not fixing the stupid stuff demonstrates you don’t understand how convenience translates into what your customer values.
  • Understand what support is.  Support is getting answers when expected and needed. That requires timely feedback. Support is not the same as a community forum or public Q&A system. Those things are in addition to support and may reduce the workload of support.
  • Understand what documentation is. Documentation isn’t a Q&A system or forum. Documentation is ordered instructions. Documentation explains complex topics and processes in an ordered way. You don’t have to search through 27 pages of forum posts to find an answer in documentation.
  • Understand how evaluation works. Some customers are going to be more conservative than others. They want to see documentation and they want to see dedication. But usually those who are justifiably conservative don’t mind paying subscription rates.
  • Don’t hide your identity. Of course, you don’t want people calling you to ask for free support. Hiding contact information, who you are, where you are located – these make you look small time an unbusinesslike.  Work up a methodology for dealing with support calls .

If you aren’t providing any service, then its hard to expect a good revenue stream from open source projects. If you are providing service – charge what you need to charge – but then deliver what your customers need. You don’t have to give away your lifeblood on open source.


Leave a Reply