'Hocus Pocus 2' Review Wi-Fi 6 Router With Built-In VPN Sleep Trackers Capital One Claim Deadline Watch Tesla AI Day Student Loan Forgiveness Best Meal Delivery Services Vitamins for Flu Season
Want CNET to notify you of price drops and the latest stories?
No, thank you

Learning from a failed experiment in open source

A review of an exceptional article on how to build a healthy open-source community.

It's great to tout open source's successes, and they are many. Linux.com, however, has an insightful article on Xara, a proprietary software company that open sourced its vector graphics engine. Well, most of it, anyway. That "most of it" turns out to be the reason why "all of it" failed.

The market is littered with examples of failed open-source projects, many launched by proprietary companies hoping for 15 more minutes of relevance. But open source doesn't work this way, and communities don't join up to prolong the existence of failed companies or products.

As Linux.com points out, this was Xara's central failing: an inept understanding of how to engage the development community on the community's terms, rather than Xara's:

Xara was wrong about the surface issue -- the importance of keeping CDraw [the core of its project] 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.

No one wants to be a lackey to a commercial open-source project, contributing her time to further some corporation's interests. People contribute if they feel that the core project fulfills their interests. In Xara's case, it didn't. By withholding the core components needed to derive value from Xara, Xara effectively told its potential community, "You can contribute to this project, and we'd love you to do that. But we're going to ensure you hobble away from it with a leg iron."

Does this mean that commercial companies need to open source all of their code to get contributions? No, though I wish they would, as doing so provides other benefits (including allowing prospective customers to evaluate the entire project, and not just 90% of it, which brings down sales and marketing costs further). Rather, companies must release enough of their code to enable the resulting open-source project to stand or fall on its own, without the need for the proprietary code.

The proprietary code can be a useful extension to the code, but it shouldn't be its central raison d'etre.

As Linux.com points out, the crippled code is just one of Xara's problems. The other, and perhaps more fundamental, problem was its refusal to heed its community. Xara wanted to be in control of its community, but one of the central tenets of open source is the right to fork which, at its most benign, means that one's community may want to take a project in a different direction from the project lead's preferred path. Good open-source projects embrace this. Bad open-source projects resist it.

And then they die. Like Xara.