Quote:
the fact that all nice add-ons we have have been single-developer efforts (I think that only Hijack got some patches by somebody other than 'lead developer'). We simply don't have very good 'bazaar' development track record


I think there are a number of reasons for this, and they would all need to be addressed for the record to be changed:
  • the source release from Empeg (as it was then) and the sources to hijack and jemplode aren't in a public CVS repository
  • we don't have a wiki or similar collaborative way to document stuff and collect documentation together
  • we don't have a big enough community - bazaars follow the 10% rule*
  • it is way more difficult to build a development community around a product that is partly closed-source (and thus could be halted at any time) than a product that is open-source.**
  • the community doesn't have access to the issue tracking tool used by the developers
  • the feedback loop hasn't been closed - the developers don't use public mailing lists, bug track tools, cvs and wiki to the exclusion of internal alternatives. Simply put, they don't wash their laundry in public.


The lack of the above makes it hard for community members to make tiny contributions (which is how new committers get hooked on open source) and makes it virtually impossible for the community to help the developers in any meaningful way.

Back when Empeg started, a closed source product made sense. Empeg was first to market and so keeping the barriers to entry high was a sound strategic move. But the market has moved on now. There are masses of car, home and portable digital audio products on the market from loads of manufacturers. Making a Rio Karma or an Apple iPod isn't considered particularly hard any more.

The thing is, most of the organizations in this market already have products and in typical corporate mentality, most of them think their product is best. Hugo has already indicated that there is no one person in DNNA that knows how the software works anymore and that RobS would need help in understanding it - this is a key reason why companies do release their code as open-source: they realise that their biggest competitors would either simply ignore the code, or waste lots of man-hours trying to understand the code and always be playing catch-up.

By using an appropriate license, DNNA could force competitors to carry an indeliable "powered by RIO Engine" or similar mark on the outside of the product (and even feature the mark in their adverts). The really big boys might choose to take a risk in stealthily using the code (but see the previous paragraph), and the tiny companies may do the same, but most will play ball: your smaller competitors now have a similar feature set to your own products, but carry your brand.

Of course, we know most of the benefits of open source: better quality product with better testing, improved user acceptance and market applicability. So, it really comes down to a simple choice over priorities: revenue from direct sales or improved visibility, ubiquity and the opportunities those might bring.

DNNA seem to be loosing the ubiquity game at the moment. It may be that creating a licensing programme and opening the source to the player would be a far more effective way to win market share from Apple than spending money on TV adverts.

--
Michael

* 4000 users generates 400 active BBS or mailing list lurkers, 40 regular contributors, 4 hackers and 0.4 lead developers or community leaders on average. This community probably does rather better than the average but still has a very long way to go to get to a healthy development community.

** In places where a community has succeeded, it is invariably because they have organised around one or more independent open-source components of the larger project.