Lessons learned from open source Xara’s failure

On October 11, 2005, proprietary software maker Xaraannounced 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.

Source code to Xara Xtreme was released in March 2006 at the inaugural Libre Graphics Meeting in Lyon, France. That release was tagged 0.3; subsequent releases followed in the coming months, the most recent of which was 0.7 in August of 2006.

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.

The project’s mailing list was soon dominated by debate over the viability of the open source project, rather than constructive talk about the code itself. In an email message to the list dated August 29, 2007, Xara’s Charles Moir confirmed that the company’s coders are no longer working on the open source project, and laid the blame at the feet of the open source community.

Expectations and assumptions

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. Numerous developers told Xara point-blank that they would not devote their time and energy to working on Xara Xtreme while its CDraw core remained closed source. Xara persisted with its original stance, in essence telling the developer community that the community was wrong: the code it had released was enough, and they should start working on it and stop complaining.

Two issues

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.

By not coming together with the developer community and collaborating as equals, the company eventually drove all of the volunteers away. By February 2007, when it finally agreed to open a Subversion branch of Xara Xtreme ported to the open source Cairo renderer, there simply weren’t enough interested developers to maintain momentum.

What does “dead” mean for open source anyway?

When someone inquired on the mailing list recently whether the project was dead, one Xara employee insisted that it wasn’t on the grounds that the source releases were still available on Xara’s Web site. “Sorry, I must be missing something. Has Xtreme suddenly stopped working on your machine? Has anything else changed?”

While it is true that ambitious coders could still take the GPLed parts of Xara Xtreme and continue to develop them, there is little incentive to do so. The copyright holders are not participating, and they are the ones who wrote and understand the code. The active communities around other open source vector graphics projects are a far more inviting target.

Furthermore, while the 0.7 release of Xara Xtreme from 2006 might still work on most Linux distros today, it will eventually begin to suffer from bit-rot as core system libraries evolve. It will stop working at some point, and become just like the thousands of other abandoned applications still available through SourceForge.net and other project hosting services.

Of course Xara could still bring the entire project back to life by either shifting developers back to it or by releasing the last bits of the Xara Xtreme source code. It just doesn’t look like the company intends to do so.

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.