Chapter 2: Community and open source – Practical Open Source Software for Libraries


Community and open source

The best person to do a job is the one who most wants to do that job; and the best people to evaluate their performance are their friends and peers who, by the way, will enthusiastically pitch in to improve the final product, simply for the sheer pleasure of helping one another and creating something beautiful from which they will all benefit.1

Open source is about so much more than the code and the programmers; it’s also about the community and the power of the crowd to produce amazing products. Every successful (the key word being ‘successful’) open source project is backed by a community of developers and application users who keep it alive and kicking. While there are ways to make money from working on open source, you’ll find that many of these community members perform their duties to keep learning and share knowledge out of a love for the product and a sense of obligation to the community.2

Peter Wayner covers the variety of motives that open source developers have:

Some contribute source code because it helps them with their day job. Some stay up all night writing code because they’re obsessed. Some consider it an act of charity, a kind of noblesse oblige. Some want to fix bugs that bother them. Some want fame, glory, and the respect of all other computer programmers. There are thousands of reasons why new open source software gets written…3

In his chapter on Geek culture, Russell Pavlicek tries to help us understand the motives of open source community. He reminds us that if we are going to understand open source we have to understand the people and the culture behind it.4

Working for open source

As professionals, we are all familiar with hierarchy and corporate structure. It is this knowledge that makes it hard to understand how an open source community can develop successful projects without such hierarchy.

Open source communities are self governing and self organizing. This is because there are no executives in charge of deciding the direction of the software for the entire community.5 The open source community assumes that if enough people need or want a feature it will be written. Remember, open source is about scratching an itch and developers and users alike understand that when the itch arises a development will be submitted for inclusion in the product.

Audris Mockus et al point out that open source software follows a development process that is radically different from the traditional proprietary style of development:

The main differences most often mentioned are the following.

OSS systems are built by potentially large numbers (i.e., hundreds or even thousands) of volunteers. It is worth noting, however, that currently a number of OSS projects are supported by companies and some participants are not volunteers.

Work is not assigned; people undertake the work they choose to undertake.6

Working together

To an outsider first joining an existing open source community, these differences in workflow make it look as if there is no control and no rules governing members, but once you become an active member in the community you learn that is not the case. Open source community members follow a series of unwritten rules, no matter what project they are working on.

Rule 1: Communication is key

As most open source projects are worked on by a widespread community, it is key that everyone communicates. Without frequent communication, projects may end up having more than one developer working on implementing a feature instead of working together. It is for this reason that mailing lists associated with active open source projects never sleep. In fact, as Clay Shirky notes, open source communities often have more discussions than would be had among those working on a proprietary programming project.7

One key way that open source communities communicate is by sharing ongoing development projects (via bug databases, mailing lists, forums, wikis, and so on) so that everyone knows what is being worked on and time isn’t wasted with multiple people working on the same thing.

Rule 2: Honesty is essential (or speak your mind)

If community members cannot be open and honest with each other then things are going to get missed and projects can fail. Pavlicek gets it right:

In a world where people are constantly exchanging ideas, evaluating concepts, and suggesting enhancements, it is vitally important that everyone speak the truth as he sees it. If someone fails to speak the truth, the process of creating software will be greatly impaired.8

This goes hand in hand with communication; if a developer isn’t completely honest with the community it can cost the project hundreds of wasted hours in development and planning and, since many open source developers work on these projects in their spare time, this can be devastating.

Rule 3: Respect each other

In any community, there are bound to be disagreements, but it is important to keep in mind that respect is esssential to working together successfully. As is true with most communications, it is important to keep emotion out of messages sent to community members and realize that not everyone thinks the same way that you do. With freedom to develop comes freedom to disagree.

Rule 4: Everyone can be a teacher

In order for open source communities to grow, new members need to be taught the ropes. I speak from personal experience when I say that it can be very scary to jump into a project that has been around and thriving for years. If members of the community aren’t willing to teach new people to help out, then there would never be new ideas added to the project and things would become stagnant.

Esther Schindler writes about the importance of mentoring in open source communities (and includes several quotes from Chris and me):

Some software developers wrinkle their nose at the very idea of deliberate one-on-one help. The default behavior in many (most? it’s hard to know) free and open source software (FOSS) communities is to read the code and documentation, try it out, rinse and repeat. People improve their skills on their own; if they need help, they post a note in a forum or ask in IRC [Internet Relay Chat]. Why should it be otherwise?

However, we all learn differently. You might want to settle in with a programming book, while I prefer to take an in-person class. If your project wants to attract new contributors, it behooves you to think past the ‘dive into the deep end’ culture.9

The article goes on to discuss mentoring in several different open source projects with first hand accounts from mentees and mentors.

Rule 5: Keep it transparent

Tying all of the rules together is the simple rule of transparency. Make sure that everything you do and say is out in the open so that everyone can benefit from your opinion, experiences and skills. If you are communicating about the project, log the discussion for those who are not online. If you are writing code, make sure it is submitted to the public repository or logged in a shared database of current projects so that work is not being doubled, and if you teach someone something new, document it and share it with others so they too can learn down the road.

Governing in open source

Even with such utopian rules governing community participation, Steven Weber reminds us that open source is not all about happy, shiny people:

The open source software process is not a chaotic free-for-all in which everyone has equal power an influence. And it is certainly not an idyllic community of like- minded friends in which consensus reigns and agreement is easy. In fact, conflict is not unusual in this community; it’s endemic and inherent to the open source process.10

This is why many of these projects have at least one (usually many more) person who is in charge of approving code for inclusion in the project. This person reviews all patches (the common phrase that refers to code updates) as they are submitted and makes sure that they improve the product for the majority of users.

In one of the open source communities that I am active in (the Koha integrated library system;, we have several people on the release team. The person who reviews all patches is known as the release manager (sometimes known as the release coordinator in other communities). Below him is at least one quality assurance person who makes sure that all patches meet the programming guidelines of the community and do not introduce new bugs or security leaks. The release team also has a documentation manager, who is in charge of maintaining and writing documentation for the project; a translation manager, who coordinates with translators all over the world to make sure that the application can be used worldwide; and an interface design manager, who works with the developers to make their interfaces more appealing for those who will be using the software.

Other open source projects are run by foundations or directors of some sort; like everything in open source, there is freedom to choose the type of governance that works best for your product and community. As Weber states, ‘There is no off-the-shelf template for coordination and nonauthoritative governance of complexity in the open source setting.’11

Whatever roles the community chooses to govern its actions, they never prevent others from chipping in. The whole idea behind open source and the community is that we all help each other in any way possible. So even though my role in the Koha community is as documentation manager, I have been known to test new code and have even written a few patches to fix bugs or add new features, just as others have been known to write documentation.

Health of the community

One of the points I always stress when teaching open source is to make sure that the product you are reviewing has an active and healthy community behind it. As stated earlier, open source is about so much more than working code:

In considering a FLOSS project, make it a point to understand the community as you familiarize yourself with the code. Subscribe to and skim mailing lists, find the list archives, and examine the project’s Web site. If the project has an Internet relay chat [IRC] channel, spend some time there – IRC’s informality can reveal whether participants actually like one another.12

1.Howe, Jeff. Crowdsourcing: why the power of the crowd is driving the future of business. New York: Crown Business, 2008.

2.Lakhani, Karim R. and Bob Wolf. ‘Why Hackers Do What They Do: understanding motivation and effort in free/open source software projects.’ In J. Feller, B. Fitzgerald, S. Hissam, and K. R. Lakhani (eds), Perspectives on Free and Open Source Software. MIT Press, 2005.

3.Wayner, Peter. Free for All: how Linux and the free software movement undercut the high-tech titans. New York: Harper Business, 2000.

4.Pavlicek, Russell. Embracing Insanity: open source software development. Indianapolis, IN: SAMS, 2000.


6.Mockus, Audris, Roy Fielding, and James Herbsleb. ‘Two Case Studies of Open Source Software Development: Apache and Mozilla.’ ACM Transactions on Software Engineering and Methodology 11, no. 3 (July 2002): 309–346.

7.Shirky, Clay. Here Comes Everybody: the power of organizing without organizations. New York: Penguin Press, 2008.

8.Pavlicek, Russell. Embracing Insanity: open source software development. Indianapolis, IN: SAMS, 2000.

9.Schindler, Esther. ‘Mentoring in Open Source Communities: what works? what doesn’t?’ ITworld, September 20, 2009.

10.Weber, Steve. The Success of Open Source. Cambridge, MA: Harvard University Press, 2004.


12.Crowston, Kevin, and James Howison. ‘Assessing the Health of Open Source Communities.’ IEEE Computer 39, no. 5 (2006): 89–91. .