Mientras estaba mirando mis pagínas web preferidas he encontrado en linux.com un artículo muy interesante: Lessons learned from open source Xara’s failure, escrito por Nathan Willis.
Para nosotros, es interesante por dos razones: primero, Xara es un software open source / propietario de dibujo vectorial (y, por tanto, podría ser interesante para los diseñadores), y porque explica los errores que deben evitarse en la gestión de iniciativas basadas en una comunidad y en un código abierto.

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.

Consideraciones para sistemas de productos/servicios open source

• debemos ser cuidadosos al intentar mezclar código abierto y código propietario: ¿cómo se relacionan? ¿Son interdependientes, y cuánto?
• debemos escuchar a la comunidad: no es posible ordenar a una comunidad, pero podemos facilitar (to enable) su crecimiento y actividad
• debemos recordar que una co-creación, un servicio basado en una comunidad, no sólo debe ser abierto sino también paritario: los usuarios y la comunidad comparten las decisiones y el poder con la empresa. Por esta razón, insist en la adición de peer-to-peer a open: las dinámicas más prometedoras ocurrem cuando estos dos elementos están presentes