The Sad Story of XOOPS: Governance Fail

The XOOPS community was dealt a bad hand last week. The Dutch Court has rejected its suit against former project manager Herko Coomans and allowed Coomans to keep funds totally more than €15,000 held in a fund earmarked for the project.

This is hardly the first open source project to come into a bad way when early or original founders split due to disagreements. Gentoo had all manner of drama surrounding founder Daniel Robbins departure and attempted return. CentOS experienced issues with control of its funds and its domain last year. There's the split from Mambo to Joomla, X.org from XFree86... most of which have their roots in poor governance issues.

The XOOPS site has a full accounting from the perspective of the remaining XOOPS community, but the bottom line is that things went south because most of the control of the project's resources were held by one member of the project.

Simon Phipps hits the nail on the head, saying that open source communities need get their governance right up-front:

There’s an important lesson for all open source communities; get your governance right, with actual legal control distributed among the members. You may trust each other now, but that won’t help in a few years time when you no longer trust each other and something has gone wrong. The time to put a sound foundation in place is before you build the building, not after it’s built.

An environment of trust at the start of a community is exactly the right time to put a solid legal framework in place.

Even when the "good guys" prevail, these sorts of splits are enormously disruptive. Community members wind up focusing on the legal battles rather than development, which is never a good thing.

The biggest problem, aside from convincing communities that they need to get governance right very early, is the lack of resources to help with this. Some projects have gotten governance right, but there aren't a lot of templates to work from. The Open Source Way book has great suggestions from the community organization standpoint, but not much in the way of legal help.

We need more projects like the Software Freedom Conservancy (SFC) and Software in the Public Interest (SPI) to work with fledgling projects. SFC and SPI usually only work with established projects, which is understandable but problematic since projects may be well into danger territory before they are large enough to qualify for acceptance.

But one thing is clear: If all of your projects resources are controlled by one or a few people in the community, it's a potential problem that needs to be solved quickly.