What Non-Profits Can Learn from an Open Source Software Project

My experience working on the development of an open source software project has caused me to think about its success and how it might be applied and adapted in the not-for-profit institutional world.

I’ve been involved with community building for a long time. When I was twelve, my parents sent me to Habonim Camp, a project of the socialist Zionist movement emanating from Israel. I was enamored with the idea of cooperation. Simply put: people do better when they work together and share the fruits of their labor.

Until starting my own business a year ago, I had only worked in non-profit organizations. (I continue to work for JRF part time and most of my clients are non-profits.) One would think that agencies whose missions did not concern themselves with profit would be ripe for the kinds of sharing and collaboration that I first got an inkling of in Habonim. In my experience, however, various fears hold in check the kind of openness that is needed to truly collaborate and share.

So when I became involved in an open source software project two and half years ago, I was delighted to discover a rich culture of collaboration and sharing, albeit surprised that geeks seemed to succeed where I had seen rabbis and social worker types struggle.

What is Open Source

Open source, defined somewhat narrowly, is a method for creating software in which the source code is free and available to the public at every stage of its development. Typically developers (the people who write the code), user testers and documentation writers, sometimes numbering into the hundreds or even thousands, will be collaborating on the project at the same time.

Here is a great description of open source from the open source Wikipedia article:

The open source model of operation and decision making allows concurrent input of different agendas, approaches and priorities, and differs from the more closed, centralized models of development.

A strong proponent of open source methodology, Eric S. Raymond, promotes it as the most efficient method of software development (as described in the Wikipedia article on his book The Cathedral and the Bazaar):

Given enough eyeballs, all bugs are shallow: the more widely available the source code is for public testing, scrutiny, and experimentation, the more rapidly all forms of bugs will be discovered.

My Experience with Drupal

Dries Buytaert, Drupal Project Lead: Photo by Shai GluskinDrupal is open source software used to build and run interactive web sites. I got involved in early 2006 when I was trying to create a web tool to organize the vast array of information on the Jewish Reconstructionist Federation (JRF) web site. What I found with Drupal was an active, helpful community of developers and users who were collaborating in the ongoing development of software that I could use to further the work of the JRF in significant ways.

In the Drupal community I found:

• Transparency; the proceedings, discussions, and the products were in the public domain to be reviewed and scrutinized, always with an invitation to role up your sleeves and help out.
• Leadership that encourages leadership. Dries Buytaert, Drupal founder and “project lead” created an environment that empowers leadership among community members. He designed Drupal to be modular. The “core” code, over which Dries holds full authority, can’t do much on its own. Drupal’s power relies on the contributions of modules by community members, whose code Dries does not have authority over. Individuals or groups who have a vision for how the functionality might be extended (or who have a requirement from a client) take leadership for developing modules that are housed alongside Drupal’s core to create software that is powerful and flexible. Personal initiative, a key component in leadership, is probably valued more than any other quality in the Drupal community. Everyone can see what you’ve done — your Drupal “resume” is literally a part of your account page on Drupal.org. (See my account page. Click on the “tracker” link there to see my participation in the forums.)
• Commitment to innovation; it’s all about making what is, better. The basic story is that you get feedback from your users, look at the changing best practices, question core assumptions, and then work hard to rewrite the the code and its documentation.

What Non-profits Can Learn

Leaders of non-profits are overly concerned with “message management” which stifles the free flow information. Needing to justify their work to funders, non-profits are more interested in painting their work in a good light than in exposing the “bugs” in their operations.

This need for message management and positive spin distances non-profit staffs and boards from many of their own constituents (or potential constituents). People are more willing to get involved in something when they have a part in creating the message. Most non-profits are afraid of giving power to people they can’t control. Ultimately this fear saps energy and pushes people away.

Obama for America has shown that significant fund raising can be done at the grass roots. Let big donors follow the grass roots donations rather than the other way around. Non-profits often justify the need for control and the resulting lack of transparency because of practical concerns related to fund raising. Ultimately the source of funds comes from the enthusiasm among a group’s core constituents. Stakeholders will be better donors when the culture of the organization truly gives them a voice.

Finally, we live in an era of innovation. In order to thrive non-profits must embrace it. They must seek employees and board members who have shed preconceived notions about how work is done. Enthusiasm about learning new things, adapting old systems and creating new ones must be at the heart of a non-profit that wants to thrive in the 21st Century.