What makes a great Open Source project?

Recently the Document Foundation has published its annual report for the year 2015. You can download it as a pdf by following this link, and you can now even purchase a paper copy of the report. This publication gives me the opportunity to talk a bit about what I think makes a great FOSS project and what I understand may be a great community.

If it is possible to see this topic as something many people already went over and over again, think again: Free & Open Source Software is seen as having kept and even increased its momentum these past few years, with many innovative companies developing and distributing software licensed under a Free & Open Source license from the very beginning. This trend indicates two important points: FOSS is no longer something you can automagically use as a nice tag slapped on a commodity software; and FOSS projects cannot really be treated as afterthoughts or “nice-to-haves”. Gone are the days where many vendors could claim to be sympathetic and even supportive to FOSS but only insofar as their double-digits forecasted new software solution would not be affected by a cumbersome “community of developers”. Innovation relies on, starts with, runs thanks to FOSS technologies and practices. One question is to wonder what comes next. Another one is to wonder why Open Source is still seen as a complex maze of concepts and practices by so many in the IT industry. This post will try to address one major difficulty of FOSS: why do some projects fail while others succeed.

My analysis is that because FOSS is a combination of several utterly different things (licensing, collaborative practices, philosophy, ethics, business models…) it is quite hard to claim that FOSS has “won” anymore that it has “lost”. Business models may for a time and under the right circumstances bring convincing proof of their relevance. Licenses may or may not gain popularity among projects because of a variety of factors. Philosophy may evolve to encompass new technological challenges (Free Software and cloud computing), etc. But what does a successful, friendly and great Free Software project do? What does this mean? Below are a few points that I believe to be key parameters to have a striving and growing FOSS project:

A clear and clean intent: The original author(s) of the project should be clear about their intent and the reasons that make them start the project. If it sounds obvious or perhaps some sort of justification no one should have to make explicit, in my experience there are wrong reasons to start a project and often bold claims that are made in order to “cover up” the initial intent behind the project. I remember clearly that just a few years ago, an established vendor “dumped” -really there is no better word than this one- a code base for an application development framework on to Apache. Apache also accepted the code dump of the OpenOffice.org codebase to Oracle, but I will not quote this example as it could be taken as an easy trolling from yours truly. So let’s go back to the other, unnamed Apache project. The vendor at the time made bold claims that it wanted to push its development framework to the top and make one of the most used tools in that category. Because it would be Open Source, it would automagically attract new developers behind the project and new developers as consumers of that framework. Fast forward till today: the vendor still has some resources into the community, but the project, while relatively active, is nowhere where it could have been and the community quite endogenous (i.e: the affiliation of developers shows a clear lack of diversity). The problem with the initial intent was that the bold claims the vendor made at first were not reflecting the reality of what it actually wanted to do: lower its costs in a highly competitive field while finding a plausible exit strategy.

Clear rules, clean governance, simple goals: This seems like a no-brainer, and yet many projects fail at addressing these points to this day. By clear rules and clean governance, original developers should make it easy for contributors to, well, contribute. It may be more difficult than it seems. It is easy enough (sometimes) to publish the code repository; less easy to justify a distributed code revision tool (aka Git but there are others) over a centralized one like SVN; it is however much harder to attract non-developers to the project, because this usually entails having quality assurance practices everybody agrees on, a workflow for documentation, volunteers for users support, and perhaps some low-hanging fruits in the field of devops and infrastructure. The challenge, then, is to weld in all these bits and pieces together to have an effective process generating code, happiness, and revenue (not just for the original developers though). Clean governance is trickier. It does not only rely on clear rules although they do make up for a large part of the governance. It does not just imply transparency. Clean governance exists and works well when no contributor can have its hand forced by a party that essentially yields too many resources in the project. Clean governance, in a nutshell, exists when no one can seriously make the claim that the game is rigged. You will find many projects with “one”, most important (corporate) contributor, and many will claim the project works well. I’m sure it does, but my experience shows that the imbalance that may not affect the everyday’s life of the community can gradually transform into a dysfunctional project with an ineffective governance that is rigged and only able to serve one party’s interest. It should be added that Free Software by itself does not make claims against such situations as the largest contributor should pretty much have the largest influence – and that’s fine with me. It is fine in smaller scale project with one contributor; and yet again it still raises the question of what would happen if that person were to leave the project. On this point, there’s no easy answer; but ensuring there’s as little imbalance as possible is a good thing to do. I’ve set aside simple goals because far from being a mere slogan, there are actually an important factor among the rest. Whatever the goals and intent of the original developers may be, a large or small part of it may not be shared by every contributor to the project. And that’s all right of course: the project exists and finds its coherence on the “segment” of the goal(s) that is actually the common interest shared by all the contributors of the project. If your own, ultimate goal is to build and fly a transcontinental airliner, it may well be that I’m only interested in powerful jet engines; or that I may be interested in a military airfreighter. So while we may not work all the way up to the airliner, we will work together on at least one specific project: the jet engine. This is where our combined interests align. Simple goals then are understandable, articulate, and stand a much better chance to be shared by a lot of potential contributors.

Good licensing & open doors: What’s good licensing? Don’t expect I will impose my views on what’s the best Free and Open Source Software license. I do have an opinion on the subject but it does not matter. Good licensing is licensing that is both well accepted by the contributors, and implies no or a minimum amount of friction and potential games to be played. Also, copyright aggregation is a no-go for many developers, even for a good cause. If it is to ensure the codebase has an unified IP in order to protect the “intellectual property” of the code base or avoid legal issues, other tools exists, such as declarations of origin whereby the contrbutor states that its contributions are indeed its own. This now leads me to what I call open doors. An open doors policy is the opposite of what’s happening in the Hotel California song, where you can get in but never leave. “Open Doors” truly empowers the developers and other contributors who want to participate and bring meaningful and important contributions. Yet this principle should never bend the rules of the project so that ignores the barriers to entry. In other words: I’ve been a strong advocate of the meritocracy principle for years. I have witnessed an unmistakable trend: meritocracy works in FOSS projects. It does work very well indeed. What it does not do, however, is to ensure that the barriers to entry to a project are both documented and low enough as to enable the potential involvement of as many parties as possible. Because of this, you could easily describe projects with proper meritocratic governance and transparent processes, but with a “domination” of just a few parties, one software vendors dominating the rest. Whether that would be an unspoken yet desired outcome remains to be debated of course.

With these few ideas in mind, I hope I’ve given some sort of “analysis chart” of what makes a good Open Source project. If we live in an era where even Wired titles that Open Source has won, maybe it’s time to improve and perfect our art. We’re not done with Open Source, we have just started.