Introduction
Open source software is the cheapest and most efficient way for a
company or organization just starting out to manage the informatics
sector of their businesses. Yet, this well kept secret need not be
reserved to for-profit organizations. Those organizations needing
cheap (free), highly customizable, and stable software to run on older
donated, or cannibalized hardware must look towards open source as a
legitimate route with regards to their information management.
Several weeks 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 digitized 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 utilized 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 this was very
relevant to my direct studies of industrial sociology at the time, 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 organizations. The purpose of this paper will be to
demonstrate the ability for an organized national association of
hackers and open source guru's to be able to maintain a myriad design
and support services for non-profit organizations (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 Organizations
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 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 world for each NPO to have an IT
department or even just an IT contact person. This person, or
department, would be the coordinator 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 organization's main purpose. Rather than being the person
'directing' the IT department for the organization, 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 organization of
coders and hardware technicians who can volunteer their time to
support the NPO of their choice. In order to get this organization
started, it will have to have the support of already existent hacker
organizations. Examples of such supporting organizations 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-organization. The assets of these existing organizations
are not necessarily any material, or financial assets, but most
importantly the social capital.
There are long histories related to each of these organizations 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
organizations gave 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
organization 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 organizations, there needs to be a small amount of financial
capital to support the most integral part of this organization: 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 organization, will be available to all other organizations. It
is also important to note that some of these organizations will be
conflicting: for example, a 'right to life' organization might request
the services of this organization, but so would Planned
Parenthood. Under such conditions, it would be up to the volunteer to
sign up for an organization over the web; and if requested, he cannot
be working with an organization seen as a conflict of interest for the
original organization. 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 organization'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 familiarize 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
organization 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 digitizing 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 organization. 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!