Why don't they contribute to open source projects

Recently, on the Israel.pm list Gabor Szabo wrote:

In a recent poll conducted by Elizabeth Naramore people were asked why they don't contribute to open source projects?

He also linked, at the bottom, to Shlomi Fish's article about How to start contributing to or using Open Source Software.

Both articles are a mouthful, and try to be very thorough in the advices and ideas they present. Sadly, both miss the point completely by assuming that "contributing" means "committing code". And this is not only wrong, its part of the reason people hesitate to contribute

For starters, "Open Source" projects tend to be seen as a hard-core programmers-only club, where you have to know how to program (mainly in C/C++), or you have no reason to be there. Seeing that the high profile projects are such complex systems, I can understand how did this image.

I would even point to the whole concept of nomenclature (Free Software/Open Source) as another clue to this "hackers only" image. When new users ask about what is FOSS, they are given a confusing lecture about the freedom of reading the code, changing the code, etc. They read articles about Open source and realise they need to learn about build systems and about version control, and get scared away.

This is sad because, as I said before, contribution to FOSS project is never limited only to committing code. Ask many project leaders about what they need and the will tell you that other than code, documentation is the number 1 issue in almost any FLOSS project, starting from user-manuals to API and design documentation. Other fields that are traditionally lacking include community management, community support, creating a web-presence, graphical design, coordination, packaging, testing, and I'm probably missing another half a dozen.

In all actuality, centring your recruitment efforts around those areas will benefit your project in the more technical oriented areas, as projects that make good progress in those fields will be more visible, new-comers friendly and will end up attracting more programmers who will see it as a thriving project that they could jump into and not get entangled with undocumented, untested cruft, or need to face puzzled, annoyed users. Solid community management and shiny web presence give the feeling of a stable project, which is what most developers seek.

Not only that, but a lot of projects that focus on getting more developers, do end up neglecting the other parts of the package, and might end up losing the community of contributors they already have, since programmers don't want to do web design, mailing list moderation, or other non-programming things.

Not all projects are GNU/Linux, who were a technical, no eye-candy affair, and whose community developed as a meritocracy of programmers. Most projects do need to clean up the façade, replace the door mattress, wipe the windows and dust up the attic to get builders and architects interested.

3 Comments

I am sure some of the people reading this will be interested what was my original post so let me link to the archive.

 

In that draft I had the following order:
1) Pick a project
2) Learn how to communicate with the current participants (thought I wrote developers which was incorrect)

 

The 3rd point was Documentation and only after that I mentioned more "hard core" stuff.

 

Luckily as I started to prepare my talk the first thing I actually wrote about was about documentation: Helping the next CPAN user with very little work

 

I wonder if you think there is anything that a new contributer could/should do before 1 and 2 and how would you propose getting them involved in the task you are talking about?

 

I tried to list the items you mentioned:
(even though the I cannot manage to use bullet points here)

  • * documentation (user-manuals, API and design documentation)
  • * community management
  • * community support
  • * creating a web-presence
  • * graphical design
  • * coordination
  • * packaging
  • * testing

I'd be happy to read how do you propose to find people who would want to do any of the above and need instructions on how to do it. Then I'll need some help writing the instructions as I don't know how to do most of these myself.

 

Have you just volunteered to give such a talk during the February Tel Aviv Perl Mongers meeting?

One helpful thing is to look at your children and younger relatives.

These kids often have nothing to do, so much so that they play videogames non-stop.

Many of these kids have reasonable art skills, good color choices and some can even do some nice webpages.

I recommend that you act locally, with the people you know and get their unmotivated youth on board with a project. Suddenly their name is on something, suddenly they have a resume entry!

https://openhatch.org/ is a good start, but just about any opensource game needs art immediately. Art is at a premium in the opensource world.

Mine your kids for free work!

Leave a comment

About Erez Schatz

user-pic Stop software patents.