Wednesday 13 October 2010

Pay per patch

I just read an interesting article about a pay per patch business model for free software.

This is something i've been thinking about lately and I came to a similar but slightly different solution - not that I necessarily want to go down that path myself.

The problem is a pay-per-path or pay-per-feature model is essentially a 'bounty' system - and bounty systems just aren't that successful for a number of reasons.

  • You still need some sort of maintainer to vet and accept the patches (are they unpaid by the patch money?)
  • Duplication. You can't work for nothing for potentially months on a project only to find someone else has done it, also see next point.
  • Undercutting - students, otherwise employed (e.g. me), people in developing countries don't mind working for relative peanuts or even nothing at all.
  • Legalities. It is really work for hire but usually not treated as such because it complicates matters particularly for international projects. Obviously this is something PFP would try to address but it isn't simple.

I think it needs tighter control for a given product and not be so much a free-for-all for all comers. Also a formal legal grounding is required and for adequate compensation.

  • Only a core set of project maintainers would be part of the process, depending on the project. This removes problems with duplication of work or the need for separate approval. As with other projects people could contribute in their own time for free as well and eventually become a core maintainer if there was enough work/they proved their skills.
  • Contracts are based on time and materials. The customer (be it a 'contracting company' organising multiple cients or the client itself) and worker (be it a group or an individual) agrees to a formal contract of what is to be done in what time-frame, and at what rate.

Essentially it boils down to running a project as a business rather than as a hobby. An example might be an individual or group of individuals starting a new project from scratch, getting it to a base level of usability and then asking customers to pay for new features. The main difference from the PFP model is you don't have a 3rd party involved as such, or a free-for-all for who might apply to do the work. As soon as you add 3rd parties you add extra costs ('leeches'), and lots of politics.

Although this will work for business and enterprise applications I'm not sure it would work for end-user applications. For starters end users are used to paying nothing for software (even if it was hidden in the cost of the computer). Secondly they don't realise just how expensive software is to make. At the very least of say $50/hour, it adds up very fast (casual cleaners get $22.50/hr here, so $50/hr is pretty cheap). Even very simple features will take at least a few hours to implement and some may take weeks or months for multiple developers.

And you still have a problem when the software works well enough for most users - eventually most software goes into maintenance mode where less effort is required. The upgrade mill that proprietary software companies use adds unnecessary expense for users even if it helps the developers maintain their lifestyle.

No comments: