|
Open
Source Development Model
Executive
Summary
Audience
This
report does not target one specific audience, but is instead applicable
to many different people. Any manager within XYZ company Pipelines’
Information Services Division will be interested in the ideas I have
presented below. Also, any student interested in a programming position
at XYZ company Pipelines will be interested in my description of the
organization of XYZ company Pipelines’ IS Division.
Prerequisites
There
are no prerequisites, except perhaps for some experience in using the
Web and other technologies like Newsgroups and such.
Purpose
The
purpose of this technical document is to describe the structure of
XYZ company Pipelines’ IS Division, then outline the strengths and
weaknesses of aforementioned structure, and finally propose the use of
the Open Source Development Model as a remedy for many of those
weaknesses.
Introduction
and Background
XYZ company
Pipelines’ IS Structure
One
of the main purposes of XYZ company Pipelines is to move natural gas
along its 4000 kilometers of pipes to its buyers. To that end,
XYZ company Pipelines has a unique structure that enables it to focus on
many things at once. IS is divided into three groups: Functional
Services Teams, LITs, and Shared Resources, each of which is designed to
support a group of users and enable them to do a better job.
Because
I worked as a Field Support FST (or also called Regional Systems
Analyst) in the Field Operation Support Team (FOST), all my ideas and
observations are from that perspective.
Business
Partners
Business
Partners are not part of IS, they are people in XYZ company Pipelines
that make decisions regarding any aspect of the pipeline and its gas.
They are ultimately the whole reason for the existence of IS, which will
be explained below.
Field
Support Team
A
Field Support Team (FST) is linked to a specific group of Business
Partners. The two exist together; one has no meaning without the other.
The Business Partners expect the following things from an FST:
-
develop
software that makes the Business Partners’s job easier.
-
implement
purchased third party software.
-
support
the software that they develop.
-
support
the desktop the Business Partners use.
-
research
new technologies that would enable them to make better business
decisions.
Essentially,
each group of Business Partners contracts out an FST which then develops
software for them and supports them.
Each
FST is composed mainly of programmers and a few managers (Leaders).
Local
Infrastructure Team
A
Local Infrastructure Team (LIT) supports and implements the corporate
wide standard technology that the FSTs and Business Partners use. Each
LIT is shared across many FST’s. When a Business Partner or FST has a
problem with one of the components of the corporate standard, they call
on their LIT. A typical problem could range from a network failure to a
failure in one of the Integrated Development Environments used.
Shared
Resources
The
last group in XYZ company Pipelines’s IS Division is Shared Resources.
This is a group of highly trained people who have more detailed
knowledge in the technologies that XYZ company Pipelines uses. When an
FST has a question that a LIT can’t answer, they come to Shared
Resources.
Another
of their duties is to research new technologies and perform comparisons
among competing products. Shared Resources ultimately suggests the
technologies that become the new corporate standards.
Analysis
Strengths
and Weaknesses of XYZ company Pipelines’s IS Structure
One
thing that quickly became apparent to me is that members of an FST have
many job duties. They have to understand the business needs of their
Business Partners. They have to support them, and in the case of
programmers, develop their applications, test them, and write
documentation for them. Thus there is no Quality Assurance people or
Documentation people. This makes sense because each FST is developing
different applications for different needs, and they understand the
product best, so they are the logical choice for dealing with all
aspects of it. This cuts from absolute coding time, but it means the FST
member has many roles that they have to do, which decreases the chances
of the person becoming bored with their job.
This
also means that a programmer’s knowledge is diverse and varied,
instead of just being limited to one stage of the product development
cycle. This in turn lets them develop better products because they can
understand all aspects of making it, instead of just writing the user
documentation for it and having no idea what went into programming it.
Another
huge benefit is that the Business Partners drive the creation of new
products because they pay the FSTs their budgets. This means the FSTs
are always developing products to solve a problem, instead of just
creating things that they think would be useful, and then shoving them
off to the Business Partners. This is easily the biggest benefit of
XYZ company Pipelines’ IS structure.
On
the other hand, because people are grouped into FSTs, LITs, and Shared
Resources, it is very difficult to talk across and find out what another
group is doing. For example, FSTs have implemented separate solutions
using Excel and
Open
DataBase
Connectivity
(ODBC) to retrieve data from a
Sybase database. This could have been avoided if each group had been
aware of what the others were doing.
Another
problem with this system is that it can be hard to find someone outside
of your group who has a specific piece of information. This is because
people can come and go on a regular basis, and phone numbers and email
addresses can suddenly stop working. I found this to be the single
biggest problem in my stay so far. If no one in my FST has an answer for
my question, who do I contact?
These
problems form a classic information management problem. The solution
comes from an unlikely place: the Open Source development model that is
being used to create some of the most advanced and stable software on
the planet.
The
Open Source Model
To
understand why this would work for XYZ company Pipelines, an overview of
how the Open Source model works is in order. Note that this model has
been used for years, and is, for example, responsible for Apache, BIND,
Linux, Perl, and SendMail; literally the glue that holds the Internet
together. The people that develop that software are distributed across
the world, almost never seeing each other, only communicating through
email and newsgroups. And yet they produce software that is vital to the
Internet’s functioning. How is this possible?
The
answer is clear once we examine the common elements in these projects.
Note that the following is a simplification, but most well run projects
contain the following:
Official
Site
Each
project has an official site (almost invariably a web site), where the
most up-to-date information exists (there may be mirror sites around the
world). This is the best place to find out information about the
project. It typically has news and links to other sites that may be
contributing in some way.
Source
Code
This
is the most important aspect of the Open Source Development Model, and
is where it gets its name from. “Open Source” means anyone,
anywhere, can download the source for the project and look at it, modify
it, and resubmit it. With tens, hundreds, or even thousands of
programmers looking at the source code, it is inevitable that someone
will spot a previously hidden bug, or know a better algorithm than the
one currently implemented. Also, people can work on whatever aspect of
the project that interests them, or that they have knowledge of. This is
why Open Source software can evolve so quickly.
In
addition, a Revision Control System is almost always used in large
projects to manage the source so that only one person can have a module
checked out, and so that the Maintainers know who has what checked out
at any time.
Official
Maintainers
Small
projects may just have one maintainer who handles all the modules. Large
projects may have one or more maintainers for each module. Design
decisions are often made through consensus. These people control what
code gets included into the official source tree.
Bug
Database
A
list of current bugs is available or can be queried from a database.
People can sign up to fix them, which are then routed through the module
maintainer. As each bug is fixed, the solution is posted in the database
and it is taken out of active status.
Documentation
Every
form of documentation related to the project is available, whether it is
user documentation, installation guides, or a known issues document.
Frequently
Asked Questions
A
set of FAQs of varying complexity exists and can be browsed. Some
projects just provide FAQs for casual surfers, while others provide
detailed FAQs for developers. Often, questions and answers are taken
from the project’s mailing list and newsgroup. Sophisticated sites can
have interactive pages that allow a person to post a question or answer.
This cuts out contact with the Maintainers and lets anyone in the world
ask a question or answer one.
Mailing
List and/or Newsgroup
No
matter how small the project is, it almost always has a mailing list,
even if it is only a group of people who carbon copy (CC) each other.
The bigger projects can have both a mailing list and a newsgroup, or
even multiple mailing lists and newsgroups, ranging from the general to
the specific.
The
reason for the popularity of mailing lists and newsgroups is that access
to information is extremely flat. That is, everyone can read and post
directly, without going through someone else. Newsgroups are perhaps
more advanced in that they maintain a history, which can be read at the
reader’s leisure, and are centralized, whereas emails must be sent to
everyone and often get deleted because they don’t seem important at
the time.
Some
sites offer a web interface to the newsgroup, and can also have any
emails sent on the mailing list automatically converted into a web page.
This lets anyone in the world get access to the information in case they
don’t have access to email or news.
Discussion
We
have explained how the Open Source model works, but why does it work?
The skeptical readers may be wondering why an Open Source project
doesn’t immediately splinter into a hundred competing products, with
so many people able to download the source and make changes. In fact,
the opposite occurs, and the simplest explanation is that the people
that work on Open Source software form a Gift Culture. In a
Gift Culture status is gained by what you give away. Thus, people who
devote a lot of their time writing documentation, testing software,
coding, etc, are looked upon highly by other members in the Open Source
culture.
In
contrast, people who work against the common goal of providing better
software by distributing rogue patches, or worse, forking the source
tree, are often shunned. Therefore, they get no status. It is much
easier for your name to be recognized when you have negative status.
Advantages
So
how would XYZ company Pipelines benefit from adopting the Open Source
Development Model? The answer is simply to treat every project and
technology in XYZ company Pipelines as an Open Source project. I believe
this will work because of the nature of XYZ company Pipelines’ IS
Division: lots of small groups working with similar technology, where
knowledge and information is distributed among people who don’t have
knowledge of each other. This exactly mirrors the Internet.
The
result is that every project and technology gains a standard format
which allows information to be searched for across FSTs, LITs, and
Shared Resources.
If
this is done, I foresee the following benefits:
Single
Point of Contact
Each
project or technology will have a web page that will never move, and
that will contain a list of all the people working on it. This means
people will no longer have to worry about contacts moving to different
departments, etc. The web page will always have a name that they can
contact about that project or technology.
Better
Searches
Because
each project site is set up identically, advanced searches can be
performed. For example, searches could be performed on one or more
source trees, which would let programmers quickly find example code, or
better yet, reuse code.
Or,
if someone was so inclined, they could search through the newsgroups,
mailing lists, documentation, FAQs, or bug database themselves, looking
for some piece of information.
Access
to Knowledge Base
People
have extremely easy access to the knowledge held by others. Through the
use of newsgroups and FAQs, et cetera, people can just post a question
knowing that someone skilled is probably monitoring it.
This
leads to an even bigger benefit in that people begin to rely less on a
few individuals for knowledge of how to do something, and more on each
other. This means the reliance on expensive consultants can decrease
because there is a much greater likelihood of finding someone within
XYZ company Pipelines who knows the answer to your question.
Obviously,
there would have to be a web page that lists every one of these sites,
and that allows searches to be performed. This would allow managers to
find out about other FSTs that are doing similar projects (or have done)
and contact them for help.
Disadvantages
There
are no obvious disadvantages of deploying such a system, except for the
headaches that come with bringing change to any existing system. Once
you are done convincing the right people, there are big budgetary
constraints, followed by huge time commitments, and tremendous initial
training and help.
Conclusions
Obviously,
creating all these web sites, newsgroups, and FAQs, will be a major
undertaking. But the flip side, not doing anything, is perhaps worse.
People can spend days trying to find someone who knows the answer to a
particular question, or has expertise in a particular area. Worse, each
time someone leaves, they take all the knowledge they gained with them.
It could have all been written down in a FAQ or other document.
While
some may believe that this will increase the beauracracy, under closer
inspection this is not true. Once each web page, newsgroup, FAQ, etc, is
set up, it will only need to be maintained. The only thing project
members have to do is commit to keeping things updated and participate
in answering other people’s questions. This is a small price to pay
for having all currently known information instantly available, along
with a pool of professional people available to answer your questions.
But
in the end, it is important to realize that the Open Source Development
Model is just that, a model. However, it is a model that has evolved
over many years from the actual usage of thousands of programmers spread
across the world. We can assume that its features have arisen to satisfy
some need rather than by accident. And as XYZ company Pipelines
struggles to deal with managing its software projects, it should look at
a model already successfully in use.
Source
|
