Navigando tra i mie siti preferiti ho trovato su linux.com un articolo molto interessante: Lessons learned from open source Xara’s failure, scritto da Nathan Willis.
Nel nostro caso, è interessante per due motivi: innanzitutto perchè parla di un software proprietario/open source, Xara, per la grafica vettoriale (e quindi interessante per un designer), in secondo luogo perchè ci spiega quali siano gli errori da evitare nel gestire un business basato su un codice aperto ed una comunità.

On October 11, 2005, proprietary software maker Xara announced its plans to open the source code to its flagship vector graphics package Xara Xtreme, and with the help of community developers port it to Linux. Today, two years later, the project is stagnant and on the verge of irrelevance, primarily because the company couldn’t figure out how to work with the open source community.

Xara and the volunteer developer community disagreed from almost the very beginning about a crucial issue: the company’s decision to keep the application’s core rendering library CDraw closed source. The developers said time and time again that a half-open, half-closed application was a dealbreaker.

Xara refused to listen, insisting that the code it had made available should be good enough, and that by not contributing its time, the developer community was not upholding its end of the bargain.

During the fall of 2006, Xara pulled its own developers off the open source project and shifted its energies toward the next major release of its Windows product — the company’s primary money-maker.

Looking back on it, Xara went into this experiment with a set of preconceived notions and expectations about open source — notions and expectations that were wrong.

As Xara saw it, the company’s contribution was the source code, and the open source community’s contribution was developer time. It had made the code available to the community, and therefore the community was obligated to work on it. Unfortunately, as the company learned, the developer community doesn’t operate that way.

That misperception isn’t a fatal flaw; many proprietary software vendors misplace assumptions when delving into open source for the first time, just as they might when tackling any new business model.

What doomed Xara’s experiment was that it continued to hold on to those bad assumptions, even in the face of repeated and candid feedback from the developer community.

Xara was wrong about the surface issue — the importance of keeping CDraw closed. So what if it didn’t release all of the code, it asked in effect. It released 90% of the code; at worst it ought to get 90% of the payoff that it would have from releasing the entire kit and caboodle.

But source code isn’t hay, to be bought and sold by volume. Ninety percent is no better than nothing if the 10% withheld is what keeps the rest of it together — which is exactly how the developer community saw CDraw. It was not some add-on feature, it was central to the app. And it was not the licensed property of some third party that Xara could not release; the company chose to keep it closed in order to own it and control it.

The more fundamental problem, though, was below the surface. Xara felt it had the right to dictate the terms under which the developer community would operate, and that does not work. The individual developers in the community participate by choice; issuing unilateral commands about what they can and can’t do destroys the relationship. Xara chose terms that the community found unacceptable, but more importantly it refused to listen to the community and adapt. Since the developer community was all volunteer, its members had no incentive to stay and work.

Other companies contemplating working with the open source community can learn at least two lessons from Xara’s experience. The first is that you can’t boss around volunteers — at best you will drive them away, and at worst you will drive them toward the competition.

The second is that collaborating with a community means willingness to adapt and change. The community may move in directions that you did not anticipate before you began; if you refuse to listen to it or refuse to make adjustments, you are likely going to kill it.

Considerazioni per prodotti/servizi open source

• bisogna porre attenzione nel mischiare codice proprietario e codice aperto: come si relazionano tra loro queste parti? Quanto sono interdipendenti?
• bisogna porre attenzione a ciò che dice la comunità: non è possibile comandare una comunità ma facilitarne (to enable) il funzionamento e la crescita
• bisogna porre attenzione al fatto che una co-creazione, un servizio basato su una comunità, deve essere non solo aperto ma anche paritario: gli utenti/comunità condividono decisioni e potere con la impresa. Per questo motivo insisto nell’aggiungere sempre peer-to-peer a open: le dinamiche più promettenti si ottengono con queste due caratteristiche