Twitter github

Lowering Contribution Barriers in Open Source

Inside the Eclipse community, we’re looking at ways to make it easier for people to contribute. Part of that work involves working on improving the web presence of Eclipse when potential contributors come visit (the other major part is at the code level, but we will leave that for another post). To help me with some ideas on how to improve the contributor experience on the Eclipse.org site, I wanted to look at how other open source communities are handling it at the moment. My thought was that visiting other community sites would also help me play the role as contributor since I’m so entrenched with things at Eclipse and have a difficult time putting myself into the role of a contributor.

Mozilla

When visiting the Mozilla site, I was greeted with a gigantic Get Involved button.

mozilla

Mozilla realizes that there are many types of contributors out there and accommodates appropriately for that.

mozilla2

As a bonus, Mozilla even had contribution options based on how much time you have available!

mozilla3

Awesome!

Symbian

The Symbian site had no clear way for me to realize how I can contribute to the effort. The site was pretty but I’m not sure the excessive use of flash is going to win bonus points with developers (does Flash even run on Symbian-based phones?).

symbian

After some digging, I found the Symbian developer site.

symbian2

It was pretty easy to find links to code, bug tracking and forums. I didn’t see any obvious links for people who may want to contribute translations or their artistic skills to the project. Then again, the Symbian foundation is pretty new so maybe they aren’t at the point where they need translation contributions.

Fedora

Inside the Fedora site, I immediately was drawn to the Join Fedora link.

Join Fedora

After clicking that link, I was presented with a wonderful variety of ways I can contribute to the Fedora project.

fedora2

I’m a huge fan of any open source community that realizes that contributors come in all shapes and sizes; there aren’t only coders out there.

Ubuntu

The Ubuntu site had nothing obvious on how to get involved immediately (you have to scroll down quite a bit to see a link to get involved).

ubuntu

I dug around a bit and found a link to Get Involved with the Ubuntu community. I was delighted to be presented with the way I would like to get involved.

ubuntu

Ubuntu seemed to classify its contributors into developers, non-technical users, technical users and people willing to donate money.

Seems reasonable.

Conclusion

What did I learn at the end of this exercise? It’s important to realize that there are many different forms of contributor roles in open source. Here’s my simplified version of the major roles contributors may play:

  • Writers
    • These people can help with things like documentation and articles
  • Developers
    • These people can code; provide patches; potentially become committers
  • Translators / Internationalization

    • These people can help with internationalization efforts
  • Graphical Artists / Designers
    • These people can help with artwork; don’t let coders design things
  • Evangelists
    • These people can help organize events and spread the word; marketing is key

There are contributors that may fit many of these roles, but most will specialize in one type of role. The key thing to understand is that you need to cater to each of these roles including how much time people have (like Mozilla did). For example, developers will want to know how to access code and contribute patches to the project. Translators will need to know where to go to translate strings for the project or file bugs for long German words that wreak havoc on your user interface. And so on…

What do people think? What can open source communities do better at making it easier for people to contribute? As a next step, I’ll take a look at playing the role of contributor in one of these communities and write a “Hello, World” type application.

If you have any ideas on how to improve the contributor experience at Eclipse, please comment on this bug.

  • From a newcomer’s point of view, especially if they are not software developers by profession, the roles you identified would make a lot of sense, when presented in a way similar to Mozilla’s website. I really like the classification based on the time available, this makes it much easier to pick a suitable task and actually complete it, as opposed to starting something and realizing later that it’s just to big of a task.

  • Great review, thank!

    I can add one more important role which is “Testers”. Eclipse doesn’t recognize them as contributors but in my opinion, they contribute their time by opening bugs to our task repository and they provide valuable input for the development teams.

    Another aspect to examine will be to analyze the process that one should pass in order to contribute in the various roles and projects.

  • @Roy Ganor

    Thanks for the comments. I agree that there should be some mention of testers. My view was that any user of your software is a tester. There should be a mechanism in place to allow people to give feedback while testing. In Mozilla Firefox, when it crashes there’s a nice feedback dialog you can use. I’m sure there are other examples out there of similar mechanisms.

  • Donald Smith

    I wonder if some of the differences can be explained by some being applications, some being operating systems, and some being tools. I.e., I can understand differences where firefox is coming from being a pure application for any end users, whereas Symbian is bit-level operating system code for specialized hardware. I.e., very different expectations from their communities, open source or not.

    I’d also be keen to see feedback on how easy it is for someone to show up and get new feature code into the core platform of these various communities, versus the surroundings.

  • @Donald Smith, in the end people are pimping their platform and trying to attract people to it. In the Symbian case, they are trying to attract people to work on the core bits of the platform AND build applications for it. These are two different types of people in my opinion. This is analogous to Eclipse where we are trying to attract more committers and projects to build up the Eclipse “platform” and also get people to extend the platform with their own applications.

    I’d also be very keen to see how easy it is to get new features in say Symbian or Firefox. What type of process they have… how much meritocracy there is… how open people really are 😉

  • Doug Schaefer

    The first thing that hit me was how the accessibility matched the greyness of open. If projects really rely on external contributions they make it easier for them to find their way in. And visa versa.

  • Donald Smith

    @Chris — but they’re different kinds of platforms looking for different kinds of contributions is the point I’m trying to make. For example, asking for volunteers to help clean up a community park would look very different than asking for volunteers to help clean up an aircraft engine.

  • Philippe Marschall

    How about kicking the IP process, the biggest hurdle to contribution? I have a patch hanging there for months. What’s the point in contributing if you can’t get anything in because it will be stuck forever in the process?

  • @Philippe Marschall, what’s the bug that you’re contributing something? Do you have a CQ? I can take a personal look at it to see what the hold up is. Sometimes it could be the committers aren’t following the process so things take longer than they should.

    The IP process is an asset to Eclipse in my opinion. Eclipse has become the largest and most successful multiple vendor sponsored open source community due to this reason in my humble opinion. We are effective at tracking contributions and validating code is safe for people to consume. There’s a balance of the IP process and making contributions very welcome. In the beginning, there’s a high cost, but once you become a committer your contributions are trusted.

    If you have ideas on how to improve the IP process let me know. As an Eclipse Committer representative, I’ve fought hard in trying to make things go faster and make it simpler.

  • Scott Lewis

    @Chris Aniszczyk

    >The IP process is an asset to eclipse in my opinion.

    At this point, I suspect there are a lot of people (contributors, committers and community members) that disagree with you on this opinion.

    It’s reasonably clear that it’s considered an asset by some (some commercial members), but I think it’s also becoming clear that it’s not perceived as an asset, but rather a liability by others…like Phillipe…and I don’t think it’s even clear these days how many of even the commercial members agree with this benefit vs. cost trade-off.

    Since you are a representative of the committers and community on the Board, I believe it would be worth investing some effort in finding out how widespread Phillipe’s view is among committers and contributors…since their views should matter in terms of representation at the Board level.

  • Philippe Marschall

    @Chris Aniszczyk
    If the problem is systemic, fix the system, not the instance, it doesn’t scale.

    Of all the Open Source projects I contributed to I had the worst experience with Eclipse due to the IP process. How to do it better? Look at any other Open Source project, it doesn’t matter, Eclipse really isn’t special. For those where it is not OK to check a checkbox you print a PDF, sign it, get it signed by your employer and fax it.

    I was writing a simple patch, that makes two anonymous inner classes top level so they can be enabled based on the selection configured in plugin.xml. If you do a wc -l on the file it is over 250 LoC. Sure because all the code is removed in one file, added in two others, there are the Eclipse License headers, whitespace and plugin.xml is not particularly concise either. Now some case of suit is looking at all the closed source code bases in the world and all the software patents so see if that violates somebody’s IP? Really? To me the message that comes across it “Fuck off, we don’t want your patches!”.

    Sure if you’re comitter the IP process isn’t so bad but that’s like saying cancer isn’t so bad once you’re cured from it. That doesn’t really help you if you just want to contribute two or three patches for small things.

  • @Philippe Marschall, I think there are aspects of the problem that are systematic but they are necessary to ensure that we minimize any risks to the Eclipse Foundation, the project and our adopter community due to inappropriate intellectual property contributions.

    I argue that Eclipse is special in regards to other open source projects for now, but slowly changing as other projects who want to see success commercially need to have these types of agreements in place. The only other project that handles contributions in a somewhat similar fashion is the Apache project. The Apache project has standard contribution agreements that its projects must adhere too, with an option to make things a bit stricter for projects like Apache Harmony.

    What would be your ideal approach to handling contributions? Would it help if there was something like Git repositories available to make it easier to contribute from your end and keep up with HEAD?

    On a side note, in your case, I think the committer should have used his judgement as your contribution was less than 250 LoC if you didn’t count all the license and refactoring stuff. In the end, the IP process dictates that it’s up to the Eclipse committer to make these decisions. My offer still stands if you want help with the contribution as I don’t mind looking at it.

  • Hi Chris,

    I am currently working on a research paper on OSS patch contribution process. Your post is really relevant to my research. I am currently reviewing OSS websites specifically on information for new contributor for submitting patches.

    I did looked into Linux kernel, X.org, Apache, KDE, OpenOffice.org, and Eclipse. Despite a lot of documents, I fine it hard to find out how one can submit patch to Eclipse by browsing the website. The information about patch contribution on Eclipse is scatter in many pages. I later found many useful information by looking at the committer related documentation but non describe the process for patch contribution. I research goal to describe a generic patch contribution process that can be tailored to various OSS projects. I am thinking about describing it using the Eclipse Process Framework and SPEM.

    What would be the best way to get in touch with you?

    Best Regards,
    Deen

  • Hi Deen, great to see your doing some research into the variety of open source contribution processes out there. The problem with Eclipse is that it's made up for many independently controlled projects (about 80 from last count). Each of these projects have a variety of contribution strategies depending on how the project is structured and what the project leadership feels is appropriate.

    The best way to get in touch with me is via email or Twitter. I'd love to help out with your research and preview any work you come up with.

  • Hi Deen, great to see your doing some research into the variety of open source contribution processes out there. The problem with Eclipse is that it's made up for many independently controlled projects (about 80 from last count). Each of these projects have a variety of contribution strategies depending on how the project is structured and what the project leadership feels is appropriate.

    The best way to get in touch with me is via email or Twitter. I'd love to help out with your research and preview any work you come up with.

  • Its my great pleasure to visit your blog and to enjoy your great posts here. I like it a lot. I can feel that you paid much attention for those articles, as all of them make sense and are very useful