Realizing the Promise of Open Source in the Nonprofit Sector

"Aside from cost, Open Source's promise to the nonprofit sector lies in its open code base. It allows developers globally to collaborate and produce or enhance new applications for the nonprofit sector. This assumes there are a reasonable number of developers willing to devote time and effort for little pay to work closely with nonprofit clients over significant periods of time measured in years to develop and maintain these applications. Nonprofits typically don't have the resources to implement basic technology right out of the box let alone supporting technicians to develop and maintain their applications. The fundamental question is how one underwrites and sustains mission critical Open Source applications designed for the nonprofit sector?"  (Next Five Minutes, September 2003)


Every so often, a technology or protocol emerges that is touted as a "magic bullet" either by the company or consortium promoting it or a core group of enthusiasts using it. Examples of this are WAP, OS/2, ISDN etc... The technology is initially promoted as having "earth-changing" significance that will revolutionize the way things are done. Eventually most of these either fall by the wayside or take their rightful place as effective [but less hyped] mainstream tools in a much larger toolbox of solutions. The problem with the magic bullet approach is that it over-promotes particular technologies. It often obfuscates the real benefits they could provide if evaluated and positioned in a more realistic context. For the for-profit community investing in failed magic bullets, the fallout is typically nothing more than an unfortunate R&D decision which can be expensed before moving on to the next IT investment.


When these same technologies create a significant buzz in the nonprofit community the results are often more serious and may lead to more unfortunate consequences. When nonprofits invest in magic bullet technologies that fall by the wayside or don't meet all the hype, they often don't have the financial resources to write them off and reinvest again. More often in this sector, a bad technology investment leads to a phobia for ever investing in technology again, even if the next underlying technology has merit. Therefore, it behooves people working in ICT for the nonprofit sector to manage expectations and not promote a particular technology as a magic bullet.


One of the latest technology protocols to benefit from the magic bullet buzz is Open Source. I am deeply concerned about this because the Open Source methodology does show a lot of promise in helping nonprofits take advantage of technology in new ways. In fact it is happening as I write this article. The idea that applications can be licensed to use or modify freely has a very powerful attraction. The Open Source methodology is certainly a viable choice for some of the technology I use, recommend and fund. However, I don't see it as a magic bullet that will revolutionize the software development and deployment process for nonprofits as some pundits do -- At least not unless it's dealt with in a far more strategic and realistic context by civil society actors.


Open Source speaks to the ideological biases of the nonprofit environment. This makes people prone to buy into it without deeper analysis of the peculiar dynamics of this sector's use of ICT. Chronic under investment in capacity skews successful implementation of any technology in this sector and requires a paradigm that differs from other sectors to make up for this deficit and insure success. Recent discussions of Open Source's benefits have focused not only on the "free as beer" aspect of the software being available at no cost but also on the "information should be free" aspect. Open Source development methodology promotes an ethic of collaboration and philosophy of openness more common to the nonprofit environment that proprietary development does not.


The reality is that Open Source has a cost of ownership attached to it that goes well beyond the initial pricing. Moreover the idea of nonprofits collaborating on software development or anything else without some financial support or funder enticement is somewhat optimistic. Nonprofits compete fiercely for limited financial resources that inhibit both cooperation and collaboration with other institutions. Many feel they own their information and constituents and that creates unique value for their institutions that they must protect. Nonprofits do foster trusted source relationships with other nonprofits just as for-profits foster co-opetition relationships with other for-profits – but the right incentives must be there for both to occur. My point is there is a danger of buying into the perceived benefits of Open Source and promoting its use on this premise alone. To derive real strategic benefit from Open Source on a macro level in the nonprofit context one must appreciate the dynamics that dominate this sector's use of ICT.


There is a compelling reason for the nonprofit sector to seriously consider Open Source as an alternative. Proprietary vendors have been making software piracy and even legal purchase much more difficult for erstwhile nonprofits, particularly in the developing world, because the end-users cannot afford to spend a lot of money on it. Between online registration and monitoring, regressive and costly software licensing fees and aggressive piracy policing proprietary vendors use, nonprofits are caught between a rock and a hard place. Authoritarian governments can use software piracy of proprietary applications as an excuse to close down nonprofits who don't agree with their policies. It's no wonder proprietary software vendors are seriously rethinking their donation and discount policies for this sector, and its high time they did.


Unfortunately, for the typical nonprofit wishing to set up and support a full scale Open Source environment from server to workstation and everything in between is currently a costly exercise – in training, maintenance and ongoing development and support. Not all the necessary applications exist or are production ready for the typical NGO wishing to use Open Source technology to install and not have to worry about it in the same way it deploys proprietary technology. This is particularly true for the desktop basics which are not ready for prime time for the majority of non-technical NGO users despite the protestations of savvier open source jockeys. Nor do the support mechanisms critical in supporting the ICT needs of the nonprofit sector exist in many places. Some of you reading this article will no doubt be able to point to individual discreet cases of Open Source deployment in the nonprofit context that were or were not successful. What I want to focus on in this article is not individual stand-alone cases of Open Source deployments, but the leveraging factors necessary to make it as ubiquitous and useful to the nonprofit sector as E-mail is now.


What colors my perception of the Open Source alternative as it is currently promoted is my experience with software development. At one point in my career I was also the developer and chief technology support for an application distributed in twenty-six countries through a network of independent but affiliated student exchange organizations. This experience taught me a lot about the software development and maintenance cycle and how NGO's actually use technology. The most important lesson I learned was that software is never completed and requires a long term relationship between its users its developers and its maintainers.


The very act of using software leads to a need to modify it. Inevitably users become familiar with it and develop more sophisticated requirements. These requirements beg enhancements and modifications to meet new needs, in addition to fixing outstanding bugs which inevitably arise. Then there are the advances in hardware and software underlying the applications we use. New computer chips, new versions of programming languages, new operating systems, etc. make upgrades to software that use these resources almost mandatory every two to four years. Otherwise one falls behind on versions and discovers certain functionality missing or not working in a previously functional application. Between user needs and the speed of technology advances, software typically needs to be modified every one to three years in order to stay relevant. This requires the commitment of dedicated technical staff over an extended period to maintain these applications.


Aside from the "free beer" aspect of Open Source, its promise to the nonprofit sector lies in the open code base which allows developers around the world to collaborate on projects to produce or enhance new applications. This is expected to provide opportunities to develop a whole slew of new mission critical applications to meet nonprofit needs at a reduced cost. There is just one problem. This assumes that there are a reasonable number of developers willing to devote time and effort for little pay to work closely with not-for-profit clients over significant periods of time measured in years to both develop and continue to upgrade these applications. Why have nonprofits had a hard time developing applications to meet their needs in the proprietary marketplace? Is the problem really that a slew of programmers buzzing around the nonprofit environment could not access the code to develop or enhance new systems? I think not.


Experience tells me that nonprofits typically don't have the resources to implement basic technology right out of the box let alone to support technical people to both develop and maintain their applications. There is a reason that technology support organizations like NPower and the Circuit Rider movement work in the nonprofit context. It's because technology in this environment is not about simply technology. It's about technology bundled with capacity and service. Capacity and service are what for-profits invest in internally so they can absorb and take advantage of the technology they implement. In the nonprofit environment only the largest nonprofits, (typically those with the capacity to generate income) invest in internal technology departments. The rest require low cost nonprofit technology service providers or consultants.


So how does the capacity and service model change in the Open Source context for most nonprofits? Does the very act of making code accessible magically create a cadre of new and interested programmers willing to develop and maintain applications for the nonprofit environment over years with few resources to compensate them? Do projects like the open sourcing of Ebase, the contact management system undertaken by Groundspring, or the development of the Martus Human Rights application undertaken by Benetech require continuous foundation subsidies of hundreds of thousands of dollars to be developed and stay relevant? That is certainly not a sustainable model, nor will it assist most nonprofits in implementing these technologies. How does one insure that an Open Source application defined to meet the non-commercial needs of a group of NGO's in a particular sector will be supported long term and updated as it needs to be?


It is clear why Open Source application efforts such as Apache and Mysql work. These applications are about developers creating products for other developers in order to enhance their own efficiency and productivity. In the end these products help anybody implementing a web server or database including nonprofits. The constituency for these applications is huge -- Much larger for example than for an application focused on case management for battered women. It is also clear why end user Open Source applications like Open Office developed for a mass audience (including for-profits and nonprofits) work as well. They have the benefit of well paid technical staff employed by companies who may wish to work with the code to enhance internal needs or to experiment on their off time. Some governments, which are beginning to mandate Open Source usage, may contribute technical support to these endeavors as well.


Nonprofits certainly benefit from both the hard core Open Source technical products like servers and databases and the mass market open-source end-user products. However, they are not necessarily underwriting their development or enhancing the code themselves with phantom technical resources they cannot afford. In this sense, the nonprofit sector's use of Open Source is not much different then their use of commercial applications. True, they are not paying retrogressive licensing schemes. However, they are not necessarily taking full advantage of the promise of Open Source either. They are still paying someone for long term technical support for applications they don't necessarily have a hand in customizing.


The fundamental question to be answered is how one underwrites and sustains the development and continued maintenance of mission critical Open Source applications designed specifically for the nonprofit sector? Applications for monitoring, case management, customer relationship management, advocacy, knowledge management, web publishing, analytics, etc. that support the unique missions of NGO's. There are literally millions of nonprofits all over the world with software application needs. How will Open Source assist in the development, implementation and maintenance of low cost, easily maintainable core applications that meet these needs? And how will these be underwritten long term?


Realizing the Promise

The promise of the Open Source methodology satisfying these needs will not be met by a few narrowly subsidized initiatives. It will require some dedicated strategically defined public support over a number of years to develop a social source community and do the following:


1) Define the core mission critical applications that most NGO's need.


2) Subsidize the base development of the core applications or at least open standards around these applications including the necessary documentation and training needed to implement them successfully.


3) Develop a programmer community around these applications along with some software development institutions that employ at least a few project leaders and senior developers to coordinate activities.


4) Tie them closely to the nascent nonprofit technology support community that has arisen over the last few years so that the applications, once developed, can be both delivered and supported over the long term.


5) Develop a cost structure that is not prohibitively expensive for NGO's but that supports continued maintenance and development of the core applications.


This will not happen without a proactive, well thought out strategy by a collaborative of progressive funders, developers and technology service providers. The dynamics that underwrite the long term maintenance and costs of mass market Open Source applications simply don't exist for the nonprofit sector because they are not underwritten in the same way they are for the commercial environment.


To develop a Social Source development and implementation community involves dealing directly with the problem of limited technology capacity investment in the nonprofit sector. The lack of internal infrastructure hampers the supplemental benefit of having subsidized developers and technology service providers also working to create a Social Source community. The funding community has started to deal strategically with a couple of technology service issues in the nonprofit sector by supporting intermediary technology service organizations and data aggregators such as NTEN, NPower, Oneworld, APC, Itrainonline, Geekcorps, circuit riders, etc.. These organizations serve as an external technology capacity substitute for nonprofits that cannot afford the internal capacity. The inception of many of these intermediary organizations was subsidized heavily by the public sector. However, a sustainability model that collected reasonable fees for service was built into the business plan in order to maintain long term viability and continued service. The model that supports technical support and training activity is instructive and needs to be duplicated for the software development activity. Moreover, these organizations must be supported to service new Open Source technologies just as they currently support proprietary technologies.


One issue that people not working in the technology space often fail to appreciate is that the technical discipline consists of a number of vertical specialties just as other disciplines do. Technical support and training is a very different animal then software development requiring different skill and mind sets. Supporting the technology service solution therefore does not solve the social software development solution. Most technology service organizations don't wish to be developers and most developers don't wish to be technology support organizations. It's instructive to note that a typical corporate IT structure also separates these specialty disciplines. In the nonprofit environment the technology service organizations are stretched so thin simply focusing on their area of expertise that they cannot effectively do long term software development even if they wanted to. Nonprofit technology service providers typically rely on pre-packaged applications that can be implemented and supported for their clients. They can go to the vendor if they need support and the vendor provides the updates.


Developing a viable Social Source sector requires not only viable technology service providers but also a Social Source development organization. Such an organization for NGO specific applications does not exist. I envision a Social Sourceforge with an added service and support arm that assists with prioritization, documentation, standards setting and closer cooperation with the technology support organizations that implement and maintain applications in the nonprofit environment. One could do without a Social Sourceforge if it was less important to develop new mission focused applications for the nonprofit sector than to simply deploy mass market Open Source solutions that already existed. However, if development of new applications is necessary for the nonprofit sector (and I think there is an argument to be made for it). Then there is a need for a Social Sourceforge.


Individual successful social software development efforts do exist. There are initiatives like The Nonprofit Open Source Initiative and the development efforts of Civilrights.org to meet the demand of its organizational constituency. Organizations like Benetech and Greenmedia Toolshed are developing discreet Open Source tools for the nonprofit sector. The Land Alliance Trust, Greenpeace, MIT and project OpenHand have all developed stable sets of Open Source code.


However, to deal with the larger strategic issues of unlocking the power of Open Source across NGO program areas and application categories I believe there needs to be a separate Social Sourceforge entity created. Its purpose is to aggregate volunteer developers to work on a variety of applications that are prioritized and defined in collaboration with technology service organizations, funders and the various NGO sectors they support. Social Sourceforge acts as a:


1) A home base for development activities designed to meet a broad base of prioritized, mission focused application needs.


2) A place to actively foster a mission focused development community.


3) A documentation and training material depository for all applications on Social SourceForge.


4) The arbiter of open standards for the NGO sector across application platforms.


5) A catalyst spawning individual development efforts conforming to standards.


6) A place where individual developers come if they wish to interact with a vibrant mission focused developer community for support.


I am not suggesting that Social Sourceforge maintain a monopoly on Open Source development for the NGO community. However, at least one should be underwritten so that it can set a standard of excellence that others emulate. NPower and TechSoup do not occupy their niches alone, but they do set the bar for other endeavors that wish to provide the same quality of services.


Social Sourceforge cannot be all-volunteer because unlike the generic Sourceforge, its members are not subsidized by corporate underwriting for its developer's activities. It needs to employ a full time software project manager and a couple of senior programmer analysts that work with a board to define Open Source standards across application platforms. This staff will also prioritize and coordinate the various Open Source initiatives, plugging the volunteer programmers into the projects that need their assistance. Here I think entities like Idealist and VolunteerMatch will be extremely helpful working in collaboration with Social Sourceforge to match developers to projects. Coordination and consistency provided by a small paid technical staff is key however.


Initially, the public sector will need to underwrite the Social Sourceforge staff as well as the initial ‘category-killer' application platforms for mission focused applications like monitoring, case management, advocacy, etc.. Along with the application's design, a sustainability paradigm must be developed to maintain them over the long term. Social Sourceforge will see to the care and feeding of the developer community around mission focused applications fostering both standards and rigorous documentation requirements.


Finally, it must be recognized that corporate IT has a methodology for prioritizing, financing, developing, and supporting its software technology projects. The various departments come together and manage this process under a project leader. In the nonprofit context, these entities do not exist under one roof. Technology service and support organizations and the Social Sourceforge of developers are designed to emulate NGO internal capacity. However, they exist external to the organizations they support as discreet entities with vertical market specialties. To further complicate the situation, funding for these endeavors comes from another source; the various public funders that underwrite these activities.


The structure requires a coordinating neutral entity that brings together funders, technology service organizations, and the developer community to agree on issues of priority, development, marketing and distribution of the applications so they reach the broadest possible environment. This horizontal agency is what bridges the vertical specialty areas of funding, development, distribution and support. A couple of years ago, OSI together with a number of other funders recognized that one of the key issues of software development for the nonprofit environment was not that applications did not exist but that there was a gap between underwriting an application, developing it and distributing it to scale.

Aspiration was created as a 501C3 to fill this gap and help bring key software technologies to the largest possible audience. Aspiration has done this successfully with a number of applications. However, it is still underutilized. Like the technology service providers and various Open Source development efforts in the nonprofit sector, it is dealing with initiatives on a case by case basis. What it needs to do in concert with the other entities is to deal with the same issues on a sector wide basis – One that creates a strategic framework that defines the social software space, mirrors the SourceForge community and works with a variety of core application needs and funding priorities across the NGO sector. Such a coordinating entity may merge with one of the other pieces of this puzzle once a vibrant community is created and all the pieces have a history of coordinating and functioning in unison. Or, it may continue to exist drawing fees from this coordination activity. At the outset however, this entity must also be underwritten for the broader vision to work.

- Jonathan Peizer -