Participation in OSS projects is similar, in many ways, to an apprenticeship. It takes some effort, and some help, to work your way to the top. Let’s watch the path a typical newbie takes up Contributor Mountain.
Alice is a budding artist, and she likes to share her work with friends online. She’s a big fan of anime. One of her friends suggests that she might be interested in a program called Inkscape, a cool illustration program.
Then her friend points her to a couple of Inkscape anime tutorials online, and Alice’s opinion of Inkscape changes from “kinda cool” to “incredibly cool.” Within a few short months and a lot of practice, Alice becomes a devoted Inkscape user. As it happens, developers sometimes forget that users are the reason that software exists. Alice, in becoming a devoted and expert user of Inkscape has taken the first, critical steps to being a valuable contributor to the Inkscape project.
Note: Alice may not yet know, or care, that Inkscape is OSS software; in fact, she probably doesn’t even know what OSS is. It’s irrelevant to her. She loves the fact that Inkscape is freely available, which is one of the great features of OSS software — but beyond that, the concept of OSS just isn’t meaningful to her. Yet.
The Internet has changed the way we ask questions. Billions of people can now go to a web page, ask almost any imaginable question, and get some kind of response — maybe right, maybe dramatically wrong, but some kind of response. It is this experience that is, in no small part, why the word “google” is now a verb. Alice, without realizing it, will quickly move from a “User” of Inkscape to a “Seeker” of information.
Our friend Alice has a problem. She has an Inkscape file with lots of cool images that some of her friends have made, and she wants to use them as part of a new illustration she’s working on. But when she opens that file, and then tries to cut and paste into a new document, Inkscape crashes. Well, it crashes sometimes. And this unpredictability is becoming annoying — so Alice goes to her favorite online anime discussion forum to ask her friends if they’re seeing this problem.
One friend recommends that she go ask on the Inkscape developers mailing list. Another friend recommends that she file a bug. A third friend asks for more details: when does it happen? Does it happen randomly, or can she make it happen by doing a particular thing over and over? Then another person pops up and says that yes, he’s had that problem too, but he works around it by opening his documents in a certain order. After some back-and-forth with this new friend, trying to figure out exactly what he means, Alice figures out the workaround: no more crashes! Alice thanks everyone for their help and gets back to her project.
Alice has become a seeker. By looking for answers, Alice has discovered a broad community of people who are willing to help her figure out how to do things a better way.
When she forgets about the workaround, the bug still bites her. Lately, some of the other people who hang out on her anime forums have been complaining about this bug, too, and she always points them to the forum thread where she learned about the workaround. But still she wonders: when is it going to get fixed?
Why? Good question. Collaborators to OSS have many different reasons for collaborating, but a frequently heard rationale is the desire to “scratch an itch.” Alice loves Inkscape, but she hates this bug.
She thinks back to the forum discussion in which one of her friends advised her to “file a bug.” She’s not even quite sure what that means, exactly, but now that she’s decided she wants to help, she starts looking around. After a bit of googling and sorting through some stuff that doesn’t make any sense to her at all, she finds a page on the Inkscape wiki that tells her what to do.
One sentence stands out: “Check the bug tracker first; your bug may be already there.” So she goes to the Inkscape bug tracker and searches for “crash”, and finds a ton of bugs — seems like software crashes a lot! She tries a few more search terms (like “copy” and “paste”), and the number of bugs she has to look through starts to drop. Alice’s search through the bugs uncovers a great deal that she doesn’t quite understand… until she finds a bug that looks almost exactly like her bug! She sees some comments on the bug that say things like “I’ve confirmed this on my Ubuntu system” and so on — so she creates an account for the Inkscape bug tracker, and adds her comment, confirming that she, too, has experienced this bug on her Mac Powerbook. Two months later, she receives an email that the latest version will contain a fix.
The line between collaborator and contributor can be a blurry line, and there are many ways to define contribution, but here’s one good way of thinking about it: a contributor is a person that an OSS community actively relies upon for help.
Of course, some contributors focus on writing code — but for the most successful projects, this is a comparatively small percentage of contributors. Some contributors maintain a wiki and help keep it up to date. Some contributors test every new beta version the day it’s released. Some write documentation about the project. Some go through bug reports, to make sure that bugs are useful for developers. Some blog about the new features to help spread the word.
Users and contributors could still interact despite different responsibilities, such as users could give feedback to contributors about the software. In fact, this kind of interaction is common in OSS projects.
Users can become contributors and actively participate in OSS projects.
