Open Source and Non-profit Organisations

E. M. Recio

01 June 2001

Drexel University
Philadelphia, Pennsylvania

Introduction

Open source software is the cheapest and most efficient way for a company or organisation just starting out to manage the informatics sector of their businesses. Yet, this well kept secret need not be reserved to for-profit organisations. Those organisations needing cheap (free), highly customisable, and stable software to run on older donated, or recannibalised hardware must look towards open source as a legitimate route with regards to their information management.

Several years ago I wrote an essayⁱ calling for the co-operation between the open source movement and the labor unions. A. Shostak (1999) devised the model of futuristics, inovation, services, and tradition to aid in the establishment of a digitised union, what he terms as cyberunions. My thesis in the essay was to put together the aspects of this F.I.S.T. model within a technological open source framework. I argued that the union must continually try new free software that keeps them a step ahead of the opponent. Cyberunions must be first in line in new technologies, receptive to external ideas, and those of talented staffers to explore free and stable software products. The leading edge unions must promote and maintain ties to those technically inclined individuals. This is easy because many of these open source `techies' are already used to, and enjoy working with this kind of software. They also like to code, for the pure satisfaction of seeing their creation utilised and providing a service to people through the code. Lastly, that open source must be made a part of the tradition of the union. While at the time, this was very relevant to my direct studies of industrial sociology, now I find that there might be some advantages to the application of open source in the general non-profit world (of which unions are certainly a part.)

This paper will attempt to demonstrate the various advantages and methods of the applications of open source onto non-profit and community related organisations. The purpose of this paper will be to demonstrate the ability for an organised national association of hackers and open source guru's to be able to maintain a myriad design and support services for non-profit organisations (NPOs).

Open Source

The basic idea behind open source is very simple; when programmers can read, redistribute, and modify the source code for a piece of software, the software evolves People improve it, people adapt it, people fix bugs. And this can happen at a speed that, if one is used to the slow pace of conventional software development, seems astonishing. The open source community has learned that this rapid evolutionary process produces better software than the traditional closed model, in which only a very few programmers can see the source and everybody else must blindly use an opaque block of bits.

Open source initiatives were what allowed the internet to get as popular as it is now. The code behind internet web sites, called hypertext mark-up language, is an example of open source. No one person, or company, controls the production, distribution or `licensing' of software (web-sites) developed using the code. Also consider the syntax used for email programs, web browsers, FTP, newsgroups, etc; the way these different programs talk to each other was mediated outside of the special interests of the companies which developed the programs. Much of the mediation was done by the Internet Engineering Task Force (IETF), an NPO formed specifically for designing and implementing these various protocols.

Non-profit Organisations

There are some problems with NPOs that make implementation of open source software solutions difficult, if not impossible. I was talking to a fellow volunteer of at least four years, called Joanne. She told me that many of the computer mediated solutions are usually dropped or left to drift without updates for several reasons. First off, there's no central management of these computer mediated programs. Secondly, there is a general lack of support system after the initial upstart of the program.

The lack of central management, Joanne explained, was similar to the left hand not knowing what the right hand was doing, with regards to technical aspects. Some project a might be started, and either finished or left unfinished. Regardless of the state of this project, it would leave no trace of its existence on record. Others coming after this project's beginning are forced to start from scratch because they either do not know the project's status or of its existence.

It is imperative in today's word for each NPO to have an IT department or even just an IT contact person. This person, or department, would be the co-ordinators of the various technical projects underway (includes the hardware, and infrastructure projects). It can assist with the transference of project owners to other qualified persons when the original project owner becomes uninterested in it. In this way, projects do not stagnate, nor do they get lost. It would also keep track of the timing, scheduling, and progress of projects that are started. This IT contact person would be familiar with the `business' rules of the institution and would be involved intimately with the organisation's main purpose. Rather than being the person `directing' the IT department for the organisation, he or she would be a liaison between the technically inclined and the staff or board members. The technical volunteer staff would recommend new software and hardware products, while the contact person would `decode' the technical recommendation into plain English for the rest of the board.

Methodology

What I propose then, is a national or international organisation of coders and hardware technicians who can volunteer their time to support the NPO of their choice. In order to get this organisation started, it will have to have the support of already existent hacker organisations. Examples of such supporting organisations are 2600, L0pht, CDC, MOR, Ghetto, Crackedbell, etc. They will provide the initial money and technical clout necessary to lure independent coders into the meta-organisation. The assets of these existing organisations are not necessarily any material, or financial assets, but most importantly the social capital.

There are long histories related to each of these organisations going back from five to fifteen years. Most of them are directly mentioned, if not footnoted, in most computer hacking literature. Someone intensely in the field, either by vocation or hobby, would have at least heard of them, if not been in direct contact with any of these groups. Because of their reputations and histories, they tend to have long term members whom have branched out into various aspects of the computing industry, from computer security to end-user programming. These long term members build up a network of social capital and ``redeemable favors.'' In the hacker community, everyone knows or knows of everyone else; it is a very close knit community of specific interests. Further, if a respected member of these hacker organisations give their full support towards this project, other community members may feel a certain attachment to the project. ``If so-and-so did it, it must not be that bad. Let me check it out.''

Those individuals not intensely interested in computing (for example, if someone got into the industry simply for a career or job) would not be as closely tied to the community as someone who works on an open source project. This, however, would not be our target volunteer; for the most part, these individuals do not know much beyond what is necessary for their jobs, and not interested in spending anytime in front of a computer when they go home at night. Another important point to consider, especially regarding the casual or day job coder, is the mandatory use of open source software. Many of these day job coders, or casual computer users are familiar with the use and implementation of closed source and licensed products. For the organisation to avoid any legal tangles, it must remain clean of all proprietary and closed solutions. If the casual coder, or closed source proponent were to be volunteering his time, he must remember that everything would be free. There should not be any recommendations made that allow for the establishment of closed source software. Apart from increasing the cost to the NPO for the software, which as was originally promised would be free, use of closed source software requires that any solution developed for the NPO be locked into, and dependant upon the closed system, making it very difficult for them to move towards open source in the future.

Along with the social capital afforded by the support of existing hacker organisations, there needs to be a small amount of financial capital to support the most integral part of this organisation: the web site. The website will be a sort of marketplace for listing help wanted and resumes. An acquaintance of mine has already implemented this idea for companies and job seekers; this, however, will be a massive bulletin board system for the NPOs to post their `job description'. If, for example, a community center wishes to make up a website, but has not a clue as to how this would be done, they could post a message on the special section of the site which states who, what, and where they are, along with a recommendation of what their expectations are of a person who is to dedicate herself.

The website will also be a repository for code fragments, problems, and solutions, questions and answers. Any tools necessary or developed for one organisation, will be available to all other organisations. It is also important to note that some of these organisations will be conflicting: for example, a `right to life' organisation might request the services of this organisation, but so would Planned Parenthood. Under such conditions, it would be up to the volunteer to sign up for an organisation over the web; and if requested, he cannot be working with an organisation seen as a conflict of interest for the original organisation. However, it must be noted to these NPOs that even though the solutions will be re-exported to the open source community, their business rules, or data will not be.

If there are more than one respondent to the project request from the NPO, there will be a team leader. This team leader will be the contact person for the NPO, in effect acting like the NPOs IT person. With the project information, and goals, as well as the progress thus far, all posted to the national hacker organisation's website, managing the project and people coming into the project would be well informed as to the project's details. This would help ease the initial problem of stagnation, or drift by unfinished projects. It would also give the NPO a support system. Should the initial project be finished, and six months down the road, the web server crashes, or modifications be needed, there is a detailed history of the project available online, that anyone proposing to work with the NPO for this second project can read up on and familiarise herself with the system.

Final Thoughts

I would like to add that this project is very doable as there is a lot of talent in the open source community and they are already in the mindset of helping out a fellow member. Another added incentive for volunteering would be internship credit for the volunteering. To keep control on the quality of work and the outline of requirements noted in this essay, the internship offer and ``credit'' would come from the organisation itself instead of the NPO. Non-profit advertisements in the radio and local papers throughout the country would be another way to target the NPO. Advertisements may also give NPOs the impetuous needed to finally move towards digitising their offices. Everything from doing simple church offerings accounting maintaining a PTA's discussion and announcement list for late breaking news (i.e.: school closings, teacher absentees etc.)

For something like this to last there must be a certain level of commitment from both the NPO's and the national or international hacker organisation. Keeping people up to date, and informed is one way of doing this; It may be very frustrating to deal with clients who really do not even know what they want, much less what they want us to do for them. They may change their minds several dozen times on a particular issue until they finally decide. To avoid this, it is imperative that the client is exactly on par with what we can and cannot do. They must be involved to a certain degree in the decision making process, limiting the everyday decisions. The client should ask for x output, and explain to you what the y input is, but the tools we use, and how we implement them should not be interfered with. What we do is the black box, so long as the input and output correspond to what the NPOs want, and can, deal with, then it is ok to keep using the black box. The difference is that this black box, is transparent, and everyone can copy it and use it if it happens to fit their needs!