Documenting barriers to entry into free software projects

[Posted July 23, 2009 by corbet]

Dave Neary has announced a draft version of a document on community barriers to entry [PDF]; the idea is to help projects identify and fix problems which keep their communities from growing. "In many corporate projects, the most damaging dynamic is when a decision gets made by someone not on the developer mailing list, and is thus completely unaccountable to the community for the decision. It is damaging for your community, who feels ignored. In the case where these decisions are unpopular, it is damaging for the morale of your developers, who must defend strategic changes in the product they may not agree with."

to post comments

Documenting barriers to entry into free software projects

Posted Jul 23, 2009 14:03 UTC (Thu) by Baylink (guest, #755) [Link] (4 responses)

The largest barrier to entry that *I* regularly run across is projects that are *enormous*. Firefox, Nagios, and RT come instantly to mind. Most such projects tend to be carried around in the heads of the 2-15 lead developers, and such projects rarely have any structure for getting potential new contributors -- or even just bug reporters -- far enough up to speed that they can do that thing passably, much less well.

Ambassadors are hard to come by, too.

This is not impossible to do well; Ardour does a pretty decent job of it.

Documenting barriers to entry into free software projects

Posted Jul 23, 2009 18:08 UTC (Thu) by jwb (guest, #15467) [Link] (3 responses)

One of the key factors of success for software projects is unity of vision. It's no surprise that the core of a project might be a few people or even one person. If someone else comes along who is wholly aligned with the project vision, that's wonderful, but if not you invite conflict and dysfunction. In short, the number of developers should not be used as a measure of project success.

Documenting barriers to entry into free software projects

Posted Jul 23, 2009 18:11 UTC (Thu) by Baylink (guest, #755) [Link] (2 responses)

I believe you misunderstood my emphasis.

My point was to illustrate that there are projects out there so large that if you have a small patch (or worse, a small bug report), even if you *want* to create a patch yourself, creating one that will mesh with the philosophy of the project requires marrying it, a time investment most people cannot make.

Documenting barriers to entry into free software projects

Posted Jul 23, 2009 18:48 UTC (Thu) by jordanb (guest, #45668) [Link] (1 responses)

It's not that they're large, it's that they're monolithic beasts with no modularity, torturous build processes, and poor or nonexistent developer documentation.

Xorg is a large project that was totally opaque in the Xfree86 days, but in recent years has been pursuing modularization of the code base and build system, as well as improving code quality and documentation. While it's still a bit daunting to approach, and documentation is still often stale, it is indescribably more approachable to a contributor than it was a few years ago.

One thing that I think free software projects should try to keep in mind is that codebase accessibility is as important is code availability. Code that is technically available but is so monolithic and poorly written and documented that it is unapproachable by an outside developer isn't truly open.

Documenting barriers to entry into free software projects

Posted Jul 23, 2009 18:50 UTC (Thu) by Baylink (guest, #755) [Link]

I think that's a pretty acceptable rewrite of what I was trying to complain about, yes. Thanks. :-)

Documenting barriers to entry into free software projects

Posted Jul 23, 2009 14:43 UTC (Thu) by emk (subscriber, #1128) [Link] (13 responses)

From the paper:

Are you using svn for source control, or have you decided to use a less common tool such as bzr, git, hg or some other SCM?

This is a really interesting question, because my experience as a developer is almost exactly the opposite. If a project uses any kind of distributed version control (such as bzr, git, or hg), I can easily fork the project, make my own patches, and push those patches to a personal repository for upstream developers to examine. If the project uses a distributed VCS that I'm unfamiliar with, it's a bit more of a hassle, but still doable.

But when I'm confronted with a project using Subversion, I have no ability to commit my own patches to version control. Therefore, I need to keep my patches in a dirty working tree, and manually manage them with diff and patch. And 4 times out of 5, this is more hassle than it's worth.

Obviously, this is just a personal reaction (and anecdotes are not data), but I was still surprised by this recommendation.

Documenting barriers to entry into free software projects

Posted Jul 23, 2009 15:05 UTC (Thu) by nix (subscriber, #2304) [Link] (9 responses)

Also, git? Less common than svn? Not in the free software world, not anymore. With X, GNOME, the kernel and soon KDE all using git, and git trees of major svn-using projects like GCC in fairly wide use, svn is starting to look like the odd one out.

Git did get popular

Posted Jul 23, 2009 15:08 UTC (Thu) by mmcgrath (guest, #44906) [Link] (4 responses)

Git is also the majority of our http://fedorahosted.org/ projects 68% git vs only 19% svn.

Easy to see why...

Posted Jul 23, 2009 19:57 UTC (Thu) by khim (subscriber, #9252) [Link] (3 responses)

Git is also the majority of our http://fedorahosted.org/ projects 68% git vs only 19% svn.

Fedora hosted projects have a choice while majority of projects are hosted either on sourcefore or on code.google.com. In both cases you can only use svn. Big "almost professional" projects can afford to use git, ht or bzr - because they are using their own hosting, small projects (and that's most of the projects out there) use SVN because it's the only viable alternative.

And most projects which are big enough to deserve usage of Git are big enough to have this "need to marry - or you can't create any patch at all" problem... much worse then need to cope with SVN...

Thus in reality most projects where hobbyst can participate will be using svn for a long time to come...

Easy to see why...

Posted Jul 23, 2009 21:46 UTC (Thu) by johill (subscriber, #25196) [Link]

github.com, repo.or.cz, or, my personal favourite, gitorious.org.

Easy to see why...

Posted Jul 23, 2009 22:17 UTC (Thu) by anselm (subscriber, #2796) [Link]

Google Code now supports Mercurial (hg), too.

Easy to see why...

Posted Jul 23, 2009 22:28 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

You need to update yourself. Google Code and sf.net supports more than just Subversion for sometime already.

Documenting barriers to entry into free software projects

Posted Jul 23, 2009 15:56 UTC (Thu) by tzafrir (subscriber, #11501) [Link] (2 responses)

GCC on Subversion? CVS.

GCC on Subversion

Posted Jul 23, 2009 16:35 UTC (Thu) by GreyWizard (guest, #1026) [Link] (1 responses)

Actually, no. http://gcc.gnu.org/svn.html

GCC on Subversion

Posted Jul 24, 2009 7:36 UTC (Fri) by nix (subscriber, #2304) [Link]

And a good few people use <git://gcc.gnu.org/git/gcc.git>.

One of the many nice things about git is how nice its bidirectional gating
tools are.

For projects using git or another DVCS...

Posted Jul 23, 2009 17:50 UTC (Thu) by dmarti (subscriber, #11625) [Link]

...is your workflow understandable to new participants, either from documentation or list traffic? Since you can set things up however you want with git, how do changes make it into the released version? Are you using a shared repo as if it were svn, or do core developers run their own and post "please pull" to the list?

Documenting barriers to entry into free software projects

Posted Jul 23, 2009 15:38 UTC (Thu) by bfields (subscriber, #19510) [Link]

There's always git-svn clone <repo>. It works pretty well once you get past the initial import (which can be very slow on a large old project, as fetching the entire history is a more painful operation with svn).

Documenting barriers to entry into free software projects

Posted Aug 1, 2009 21:53 UTC (Sat) by dmag (guest, #17775) [Link]

I agree. For open source use, a distributed version control systems are a pure WIN.

First, if you don't have a commit bit, then you can't really USE subversion as a version control system. At best, you can run diff. You can't track multiple patches (unless you create your own SVN repo, but then that's so much work that nobody does it).

Second, Git (and others) actually help with merging and branching. Branching is so cheap in Git that you actually use it in a different way than SVN.

SVN will probably stick around the "enterprise" for a while (for the same reason they resisted Linux at first.) But I predict that ALL open source projects will move to a distributed version control system. DVCS make it much easier to develop in a decentralized way.

Hard to interact with SUBVERSION from a DVCS?

Posted Aug 3, 2009 3:05 UTC (Mon) by vonbrand (subscriber, #4458) [Link]

It is reasonably easy to use git svn to interact with upstream SVN from your local git repository.

Documenting barriers to entry into free software projects

Posted Jul 23, 2009 18:22 UTC (Thu) by jwb (guest, #15467) [Link]

The "Governance & Transparency" section of this document rings true to me from my early experience with Mozilla. It was infuriating that some anonymous product manager from AOL could come along on Bugzilla and effectively kill my contribution by simply flagging it as not important for the release with the fatal "nsbeta-" flag. Those people were accountable to nobody and to be given the royal thumbs-down by such faceless autocrats was very discouraging. Luckily Mozilla eventually escaped that fate, but future projects which are driven primarily by software companies would be smart to learn from that history.