Are Nuxeo's open source projects truly community-driven? You bet they are!

Dion Almaer wrote yesterday a blog entry with a list of criteria that, in his opinion, make an open source project truly community-driven (which is, of course, a Good Thing(tm)).

I had some apprehension, while reading the blog entry’s title, because, of course, we want to be community-driven (that’s one of the criteria BTW), but what if we had forgotten something important?

Fortunately, the short answer is “of course we are community-driven”. With Dion’s criteria, I can confidently self-grade us at A+ (or 20/20, for french-educated people). Here are the criteria and my comments:

If you don’t have any commiters from outside of your company. You probably aren’t community driven.

Half of the commiters in the Nuxeo project are not Nuxeo employees, and we are actively trying to recruit more contributors.

If you didn’t spend time cleaning up documentation for the community when you opened it up. You probably aren’t community driven.

We’ve produced already several hundreds of pages of users and developers documentation, and we’ve gone through great efforts in producing this documentation in time for the first public releases of the software.

If your users haven’t helped with the documentation if it is lacking. You probably aren’t community driven.

We got great feedback from our users regarding the documentation, and we’ve already had user-contributed sections in some of our manuals.

If you do not have some kind of forums/lists where people help each other out. You probably aren’t community driven.

We have several mailing lists for all of our projects, with a total of about 1500 subscribers.

If you aren’t willing to put in a lot of effort to build your community to get true benefits. You probably aren’t community driven.

Yes, we’re putting a lot of efforts, and we get the rewards of course.

But there is something more important, that is not explicitly stated in Dion’s criteria: we have designed the Nuxeo software with the explicit goal of creating an Architecture of Participation (a term coined by Tim O’Reilly, Dion’s boss, BTW). Our creation of Nuxeo Runtime, the OSGi-based plugin system (inspired by Eclipse’s), our use of a component framework like JBoss Seam for our webapp, are consequences of this vision, which comes from years of experience working with system integrators and ISV.

Extensibility at all levels is one of the majors criteria of a successful historical open source project (think Eclipse’s or Mozilla’s plugins, Emacs scripts, LaTeX packages, etc.). Monolithic apps usually don’t make great open source communities. That’s a lesson we will never forget!