OSS is led by an “elitist circle,” and newcomers don’t get access
September 9, 2011 at 11:10 am 9 comments
There are efforts to engage undergraduates in open-source software development as a form of service learning, to be part of a developer community, or as a way to gain experience with significant code bases. I’ve mentioned before that the OSS community doesn’t have a great track record for diversity and welcoming newcomers. Here’s a new study describing how hard it is for newcomers to connect with the oldtimers in OSS. These results suggest that undergrads doing OSS for a course are still providing a service and are likely still gaining good experience working on a larger code base, but they’re unlikely to become part of the established developer community. It won’t really be an apprenticeship model — they’ll mostly just be talking to each other.
“Taken together, we found that accomplished developers tend to connect with other accomplished developers, essentially forming an elitist circle in the OSS (open source software) community. By contrast, it is more difficult for less successful developers to establish collaborative relations, and even if they do, they tend to connect with others who have a similar lower level of performance and experience,” Shen writes in the article.
via Research Shows Dynamics of Online Networking – UT Dallas News.
Entry filed under: Uncategorized. Tags: computing education, open source, undergraduate education, undergraduates.
Computing Ed Research - Guzdial's Take 
1.
John "Z-Bo" Zabroski | September 9, 2011 at 11:19 am
You can paint a portrait many ways…
To work with the best, you have to prove to gradually better and better programmers that you are deserving. In turn, these gradually better and better programmers will accept your patches, and eventually your changes will be noticed when integrated upstream. Also, participation in chats (IRC, mailing list, etc.), even if only lurking most of the time helps. Then there are conferences, which are important for joining a keyring (such as Debian’s).
What’s hard about that system, and what’s condemnable?
Did Michaelangelo work with Homeless Joe Boxcar?
2.
Jeff | September 9, 2011 at 2:02 pm
One of the things that’s helped NetBSD get over some of the reluctance to help out new developers is the Google Summer of Code – it’s helped individuals to see some of the benefits of giving newcomers a leg up. Of course, the downside of this is that it’s not uncommon for newcomers to take a lot of handholding and never contribute to the level they were assisted.
While I agree most projects need a reminder that new blood can be useful, students in particular often need a reminder that they need to demonstrate a willingness to listen to constructive criticism. (Even if it’s sometimes difficult to tell that it’s constructive)
3.
Neophyte Representative | September 9, 2011 at 5:37 pm
The Free/Libre Open Source Software (FLOSS) community is a meritocracy. As such you have to build your relationships with good work. Not unlike the usual experience of being the newest employee. At least if students participate in FLOSS, they can point to legitimate experience from which to offer suggestions on their first day on the job or they have learned how to more carefully present themselves to a yet unfamiliar co-worker.
4.
Mark Guzdial | September 10, 2011 at 9:23 am
But it’s not, really. As the cited study describes, development occurs along social connections. As work at the Anita Borg Institute has shown, those social networks are blocked to women and minorities. Thus, it’s not true that the best make progress — it’s not a meritocracy.
5.
Neophyte Representative | September 10, 2011 at 7:11 pm
The Shen-Monge study is a snapshot, not a long term study. It uses data available on the front-pages of a single family (BitTorrent) of related software projects.
I wonder what will happen over time. Will the project leaders appoint, as project leads, accomplished developers who consistently prove their worth? A person self-identifies as a developer, but usually must be allowed commit rights by an existing project member with commit rights. That is usually a reward given for merit. (There is no such thing as a pay raise for uncompensated work.)
In my experience being a Project Lead is also a self-identified role that is a lot of work for little ego boost. So, it is not seen as meritorious progress to become a lead even though good leaders are sincerely appreciated. Most of us come to work on the product components: code, installation scripts, documentation, publicity, testing, …. Until we experience a conflict with a change someone else wants to make, the project leader is more than glad to allow us to select our own tasks. Then we may both need the leader to help resolve the conflict. It’s also well known that the person listed as Project Leader is often not the person who ends up performing this conflict resolution task.
A better, but admittedly more difficult to statistically process, source of the actual interactions within most FLOSS projects are the communication streams: the mailing list, Internet Relay Chat (IRC) channel, and such. There the actual, active contacts can be documented, not just some ephemeral coincidental listing on one or two pages of the project description. There the relationship of the communicators can be established. Is Person A deferring to the judgement of Person B? Is Person C suggesting a change that is readily adopted by the community? Is Person D being shunned (a sure sign of lack of merit)? Is Person E invited to encode the design that Person F has provided (a definite expression of merit value)? Note, none of these interactions reflect an evaluation based on anything other than the work and interactions experienced. You do the work; You get to do more of it.
6.
Matthew McMullan | September 10, 2011 at 4:43 pm
This comes as a bit of a surprise to me. I have been developing open source software for several years now, and every project that I have touched along the way has been extremely welcoming. Granted, I have not worked on any massive projects such as a linux distribution, but the mid-sized projects that I have worked with were welcoming to me and willing to answer any questions that I had about the project and codebase. Perhaps my experience is unusual, but I am still surprised by the conclusions of this study.
7.
luisibanez | September 11, 2011 at 10:37 am
The title of your post may be overly provocative, but… the content is a valid criticism of the daily activity in Open Source (OS) projects. Despite the fact that it is not at all the intention of OS developers to keep newcomers away from a project, the practical reality is that we could do much better to bring new developers on-board.
Of course, given the thousands of OS projects, it is not possible nor fair to generalize on this statement. Some projects do a much better job than others on welcoming new developers, and we have a lot to learn from the project that do it right.
Along those line, we wrote this blog post:
“Opening Open Source”
http://www.kitware.com/blog/home/post/13
and also learned a lot from an exercise we did with the Teaching Open Source group at OSCON 2010, in which by working in pairs we look over our partner’s shoulder as they navigated the web site of our project trying to find the source code and the bug tracker (pretending to be a newcomer). The eye-opening experience was simply that: despite the fact that we “thought” that our project was open, welcoming, and easy to navigate; the path to join was not as clearly marked and warm as to attract and retain the occasional visitor and the interested newcomers.
Since we spent too much time inside the project, and know where everything is, we tend to overlook the fact that things are not marked as clearly for people coming from the outside.
At the bottom,
this is mostly a matter of Economics:
“Efficient Allocation of Resources”
The scarce resource in Open Source is the time and attention of skilled developers. Old time developers are confronted with the choice of using their time and attention to write and fix code, or to use it for training and mentoring new developers.
The mental calculation for an old developer is:
I can use 2 hours to help John Doe join the project,
or I can use those 2 hours to work on feature Z
or I can fix fix bug #666.
That calculation requires to estimate the chances that John Doe will stick around in the project, long enough to contribute features, bugs fixes, and hopefully take on responsibility and leadership roles in the project.
It also includes the chances that I will actually manage to implement feature Z, or fix bug #666…. 🙂
As in real economic problems, we have to act under conditions of incomplete information:
* I don’t know John Doe,
* I don’t know his programming skills,
* I don’t know if he is a team player,
* I don’t know if he is interested enough in the project.
* I don’t know if he still will be around next week.
(…although this last one may indeed be my fault
for not working hard enough on welcoming him..).
On the other hand, I certainly know that there are hundreds of bugs in the project and that we can use John’s help.
Moreover, if we focus on recruiting 20 to 50 new developers like John, then the project will be a lot better served than if we spend that same time only writing code ourselves. (Linus Law).
In ITK (http://www.itk.org) for example, we ran a recruiting program called “Adopt A Bug” in which we gave CVS (yeap it was the days before Git) write access to any random person who raise his/her hand and adopted one of the Bugs in our bug tracker:
http://www.itk.org/Wiki/ITK_Adopt_a_Bug_Program
Our calculation at the time was that the project needed a stable group of about 50 developers (with a typical power-log distribution of activity: 20% of the group doing 80% of the work) to maintain the project in a healthy state.
The effort brought very bright developers in, but not as many as we were hoping for.
Since then, what we have learned is that we were missing a couple of good practices and good tools. They are in particular:
1) We should have a categorization of “Easy Bugs”
that are clearly marked as suggested tasks for
new developers. Followed by “Not so Easy Bugs”
that could be taken upon as second challenges.
Essentially we were missing the “Gamification”
of the project:
* It should be fun
* It should start easy
* It should offer increasingly harder
challenges at a pace that matches
the player skills
* It should provide continuous feedback
on how the player is doing
* It should develop a sense of Mastery
in the player
More recently, Asheesh Laroia
http://www.oscon.com/oscon2010/public/schedule/speaker/77710
has made a great contribution to solving this
first problem with the “OpenHatch” project:
http://openhatch.org/
We have not, however, followed yet with stratifying
)
our bugs into categories that mark a clear path of
increasing difficulty for newcomers to earn their
stripes. (shame on us…we have been too focused
on putting our release 4.0 out of the door…
2) We also needed a better tool for mentoring and training
new developers. We have now find that tool on the form
of the Code Review system Gerrit:
http://code.google.com/p/gerrit/
http://review.source.kitware.com/
This is a tool that makes so much easier to accept
patches from new developers and effectively mentor
them through the process of improving their code.
We can now easily annotate their code, and give them
feedback, in an iterative rapid cycle. We can also fix
the code and post it back for them to see. Once we
converge, we can simply “git merge” their contributions
preserving their authorship and therefore raising their
ranks in the meritocratic structure of the project.
Before Gerrit, we had to attempt to do that by email,
and it was a very demanding and frustrating task to
“annotate” code in an email.
Being both an “old developer” in an Open Source project (http://www.itk.org), and an instructor in an Open Source class where we require the students to join Open Source projects:
http://www.opensourcesoftwarepractice.org/
I get to see both sides of this coin…
The summary is that:
OS project are trying,…
but they are not trying hard enough
(or not well enough).
Again, with the disclaimer that it is impossible to generalize
this statement to the hundreds of thousands of OS projects
out there. Some projects do this really well, and we should learn from them.
This is not a trivial problem to solve, but it is not an unsolvable problem either. This also illustrates that OS projects need participants that are not just “developers”. You really need some members with “people skills”, with the right attitude and mentality to engage and retain new participants.
This post is already long enough,
so let me just close with strongly
recommending the following books:
“The Art of Community”
“Building the New Age of Participation”
Jono Bacon
O’Reilly
“Cognitive Surplus”
“How technology makes consumers into collaborators”
Clay Shirky
Penguin Books
“The Cathedral and The Bazaar”
Eric Raymond
O’Reilly
(This is a classic that not enough OS people
have read, and that is still fully valid today.
A great portion of this problem is discussed
in the chapter “Homesteading the Noosphere”)
“Drive”
“The surprising truth about what motivates us”
Daniel Pink
Riverhead Books
8.
Becka Morgan | September 12, 2011 at 1:08 pm
Excellent summation of the problem that exists in the FOSS community. Thank you for pointing me to new sources of information for my dissertation 🙂
9.
Michael Kay | September 12, 2011 at 10:45 am
Elitist yes, exclusive no. I first started writing OSS after 25 years in industry and I was very quickly accepted into the circle. The point about open-source is that you can’t hide incompetence – and the open-source elite doesn’t tolerate incompetence.