a case study in open source software
Selena Sol Public Domain Script Archive
"I am happy to say that we have been using your Web Calendar within
our UNIX Systems Administration group for nearly 2 years now. Our
group of 15 admins support over 100 servers here at "site 0" the
software development center for the mammoth new Enterprise-wide
Distributed System here at Boeing."
- Gene L. Huft of Boeing
In the summer of 1994, the Selena Sol Public Domain Script
Archive went on-line with user documentation and source
code that had been written by Eric Tachibana for use
Electronic Frontier Foundation (EFF) website. The Archive was developed
primarily out of a desire to provide documentation of web
technologies and applications that Tachibana considered
fundamental to the future web infrastructure.
Initially, the archive was to be a public service for
other web application developers who were facing similar
problems in the early days of the web revolution.
The idea was that no web application developer should
duplicate research or expend energy solving a problem
that had already been solved by someone else. If all
web application developers worked together, Tachibana
reasoned, they as a group, could advance with far
greater efficiency and build a web infrastructure of
which they could all be proud.
Furthermore, releasing public domain code ensured that
all developers, regardless of race, gender, nationality,
class, education, or creed, would have access to web
applications and technology.
Joe Web's Fish Store, Tachibana believed, should
have as much right to reliable software on the web
as IBM or AT&T.
Finally, Tachibana figured that if he were lucky, people
might help him improve the code.
Little did he know!
The Archive Takes Off: Intellectual Property - Just Say No!
"I want to personally thank you for putting all these CGI scripts
on the web. I am working on a website for my dad's custom tailoring
business in Hong Kong. Your site is making a difference. And
I'm glad to make my dad happy too." - Shirley Chang
Along with the similarly-oriented site run by Matt Wright,
the Public Domain Script Archive was instantly a success
in the growing web application development community.
The applications, which at that time included WebStore,
WebBBS, WebResponder, WebGuestbook and SiteSearch,
began to show up on hundreds of web sites on every
continent. Scores of e-mail letters poured in from
developers who were using the code and who wanted to
report feature improvements, submit bug reports AND
bug fixes, or who just wanted to say
By then, Tachibana had left the Electronic Frontier
Foundation to work at The
National Center for
Human Genome Research. There he met Gunther
Birznieks, and together they further developed
the initial group of web scripts into a suite
of CGI/Perl applications based on the initial
code as well as the code, comments, and criticisms
submitted by hundreds of developers in the ether.
The suite added a Database Management and Search
Application, Groupware Calendar, Banner Rotator,
Site Administration and Access Control Library,
Animation Examples, a real-time Chat Application,
and several other miscellaneous applications and
development libraries in Perl and, in time, Java.
By 1996, most of the applications on the Archive had
been revised four or five times each, with every
iteration based upon the feedback received from the
thousands of developers now using, installing, and
These developers sent in a constant stream of feature
wish lists, benchmark and efficiency reports, bug fixes,
and security enhancements, as well as third-party extension
code and supporting tools.
There was also several incredibly active
discussion forums on which clients could ask each other questions, find
freelance support, or simply talk about common usage issues such as
advertising within a WebStore or better credit card
By this time, the popularity of the site was raising
The site was awarded dozens of net achievement awards,
was featured in several online and offline magazines,
was mirrored on five continents, and eventually attracted
the interests of publishers such as WAITE, M&T Press,
Together, and with several other authors, Tachibana
and Birznieks went on to write Perl 5: How To, CGI
For Commerce, Programming with AFC, CGI: How To,
and the classic Instant Web Scripts with CGI/Perl
that documented all the web applications in the archive.
"When people ask me whether open
source is credible, I ask, 'Do you
believe in the Internet?'" - Tim O'Reilly
All the while, Tachibana and Birznieks remained true
to the ideals of information sharing. Even when they
published books and magazine articles, they demanded
contractually that all work would remain in the public
domain. M&T Press even agreed to publish
Scripts with CGI/Perl online.
By 1997, Tachibana and Birznieks felt that the site had
fulfilled its original mission.
However, a serious problem was emerging.
Specifically, both Birznieks and Tachibana were becoming
overwhelmed with e-mails and opportunities generated by
the archive. For example, despite the availability of
complete FAQS and detailed documentation, Tachibana
received over 100 e-mails every day with questions about
web application development from specific customization
questions, to general questions with technologies including
SQL, HTML, CGI, and Java. Also, Birznieks and Tachibana
were both inundated with freelance turnkey installation
projects that began to eat away at all their spare time.
Meanwhile, both Tachibana and Birznieks realized that
the applications in the archive needed to be rewritten
in an object-oriented framework to take advantage of
concurrent technologies being developed in the web
application development community such as Perl 5,
Active Server Pages, Servelets, Mod Perl, and other
It also was clear that new methodologies were needed
to increase scalability and enhance security. Additionally,
a wizard was needed to make installation and
customization more user-friendly.
To be frank, the original applications had never been
designed to handle World Wide E-Commerce Web 2000.
Unfortunately, Birznieks and Tachibana both had full-time
jobs that demanded their full-time attention. Maintaining
the archive became quite frustrating as developers around
the globe continued to clamor for solutions.
The Free Software Solution
Free software is a matter of liberty, not price. To
understand the concept, you should think of "free
speech", not "free beer." - Richard Stallman (from GNU
Then, in early 1998, Birznieks and Tachibana devised
a possible solution to the dilemma. The two would
leave their full-time jobs and devote all their time
to developing the applications to an enterprise level.
However, true to the original ideals of the archive, they
decided to form a company based upon the same ideals which
had made the site so successful.
Users should continue to enjoy the freedom to download,
use, modify and copy the software produced by the
"for-profit" company just as they did when it was a public
Fortunately, such a business model was not as absurd
as it might sound. Several working and respected
business/development models had grown up during the 80s
and 90s based on the changes being wrought by the digital
economy and which took for granted the idea of "free
software." These new models incorporated, evolved from or
grew up in parallel with the "Free Software" model
developed by the Free Software Foundation in the
Essentially, the new models of software development
argue that it is possible to run a profitable company by
granting your customers the ability to freely copy, distribute,
or even change the software that you provide.
The Free Software Foundation puts it like this:
"Free software" refers to the users' freedom to run, copy,
distribute, study, change and improve the software. More
precisely, it refers to three levels of freedom:
The freedom to study how the program works and adapt it
to your needs.
The freedom to redistribute copies so you can share with
The freedom to improve the program, and release your
improvements to the public, so that the whole
And "free" doesn't only refer to the "freedoms" granted
the users. In many cases, free also refers to the price
of the products. In today's economy (not just the software
market), it is not unheard of to see companies giving
away their technology for free.
In fact, some proponents of the new business/development
models argue that this free distribution model, and similar
models, will be the most successful models for an
information-era economy, in which it is impossible to protect
intellectual property in the form of products.
"In regard to my own soft product, rock and roll songs, there is no question that the band I write them for,
the Grateful Dead, has increased its popularity enormously by giving them away. We have been letting
people tape our concerts since the early seventies, but instead of reducing the demand for our product, we
are now the largest concert draw in America, a fact which is at least in part attributable to the popularity
generated by those tapes." - John Perry Barlow
The whole concept might sound a little odd, especially
since we have all grown accustomed to the traditional
business models, in which you invest capital into developing
a product that you can later sell for a profit. Without
selling a product, how can you make any money?
And what's more, how can you afford to invest in product
research and development in the first place?
Indeed, the free software models are fairly
avant-garde and sometimes counter intuitive business
models. However, examples of successful implementations
of the models as well as successful variations of the models
That is to say, these were not simply academic business models.
Over the years, real-world implementations forced the
models to take shape. By the late nineties there were a
host of companies which represented a complex ecosystem
of free software model "species."
Tachibana and Birznieks decided that the new company would follow
in the footsteps of these other successful free software and
quasi-free software companies that had already taken
advantage of new business models.
So the two began researching business models oriented
around free software.
Let's consider some of the important ones...
The Red Hat Software Approach - Leveraging the Product Halo
"The ancillary market is the market. The software is free, but the
manual is $10,000. That's no joke. Cygnus Solutions rakes in $20
million per year in revenues selling support for free UNIX-like software.
Apache is free but you can buy support and upgrades..." - Kevin Kelly
New Rules for the New Economy
Consider the case of
Red Hat Software which
produces Red Hat LINUX - a multi-million dollar company which
adopted a fairly pristine implementation of the free software model.
Red Hat makes the bulk of its profits not
from subsidiary products to its free ones, but from
the vast service sector (the "Product Halo") that develops
"around" its free product.
If you go to the Red Hat website, you will see that Red Hat LINUX
and many development tools are freely downloadable.
If you read the intellectual property notice, you will
see that they may also freely be resold. Finally, you will
see that Red Hat will sell you the code as well
as printed documentation on a CD-ROM.
So why would people buy from Red Hat at
all if they could get the code themselves for free?
The reason is because there is something to be said
for the "convenience" of a book and a CD-ROM. In fact,
many clients prefer a book in their hands to online
documentation and ftp access to source code. Even though
people could get the code for free, many choose to buy
it from Red Hat because it is simply convenient to do so.
Further, developers often complain that, though
they are very happy with open source code, their managers will
only accept something "in a box." Managers sometimes
fall prey to the fallacy that open source code cannot
be good code (We will discuss why this is a fallacy later on in
this document). Instead, they feel better with something in their hands
that they have paid for.
Nonetheless, although Red Hat's "convenience
products" are profitable, they do not necessarily represent the majority
of Red Hat's profit.
Red Hat makes most of its money in another type of service,
one based upon its reputation and experience.
Red Hat has gained a reputation
for doing good business and for helping its customers
solve their problems. Reputation, like status and experience, is vital.
Customers often are willing to pay a little extra to make
sure that their problems are solved by the best. In the end,
hassles can cost more to an organization than a support fee.
Who better to hire than the original developers themselves?
Red Hat, perhaps more than any other company
to date, has done an incredible job at leveraging the product halo.
In fact, they have been so successful that
they can afford to maintain a research and development department
of six full time developers working on theoretical tangents.
The GNU Project - Free Software Purists
The GNU Project that has
been providing free software since the 80's.
Long before Red Hat entered the scene,
GNU was writing and distributing volumes and volumes of high
quality free software. In fact, if you are a UNIX
developer, you most certainly use GNU products several times
And like Red Hat, GNU sells the code formally as a convenience
product as well as providing consulting services for related
application development projects. Essentially, they use the
free software side of their business
to prove their capabilities and to develop tools that
they can use on other projects.
The Netscape Approach - Gaining Market Share
"...Ubiquity drives increasing returns in the network economy.
The question becomes, What is the most cost-effective way to
achieve ubiquity? And the answer is: give things away. Make
Indeed we see many innovative companies in the new economy following
the free. Microsoft gives away its Internet Explorer web browser.
Netscape also gives away its browser, as well as its valuable source
code. Qualcomm produces Eudora, the popular email program,
as freeware in order to sell upgraded versions....And
of course Sun passed Java out gratis, sending its stock up and
launching a mini-industry of Java application developers." - Kevin
Kelly from New Rules for the New Economy
Next, consider the case of Netscape
Communications Corp. which in a few short years grew to
become the envy of every web-based software company by
giving away their Netscape Navigator product, and later the
source code for that product, for free (to certain users).
By giving away their software,
Netscape gained an incredible market share in a
short time. And as
both show in their discussions of Intellectual Property in the
Information Era, in the digital economy, market share is
Netscape realized that the trick about software was that
once a customer has grown accustomed to your software product
he or she is less likely to switch to a competitor's product
because of the cost of relearning and retooling. "If it ain't
broke, then don't fix it," is the unspoken law of most IS
departments around the globe. Thus, the first software product
to capture a customer will be the software product that the
customer will tend to stick with.
In the end, Netscape became synonymous with
the World Wide Web and as a result, Netscape was able to sell
its server product line (which was not at all free)
with great success. Netscape Navigator essentially ran as
a loss-leader for the Netscape Server product line and the
company cleaned up.
Though this is not even close to a pristine implementation
of free software according to the definitions set forward by
the Free Software Foundation, it was a very successful
version, and one of which we should all take heed.
The use and management of free (in terms of price) software
are important for free (not just in terms of price) software
Scriptics - Besting the Credibility Hurdle
"In early September 1998, the 500,000-plus software
developers who rely on Tool Command Language, or
Tcl (pronounced "tickle"), cheered Scriptics' launch of
the first official development tools for the ten-year-old
programming platform. Founded by Tcl creator John
Ousterhout, Scriptics joins a slew of recent commercial
ventures built on freeware, or software code available in
the public domain. These businesses hope to cash in on
the vast installed base of technologies that have been
given away for many years. Supplying downloads to
almost 50,000 users each month, Scriptics serves a
market of programmers starved for Tcl tools, extensions,
and support services." - Deborah Claymon, The Red Herring
is a great example of a free software group which
leveraged the reputation, respect and trust of years in the
public service to form a company which brought corporate
room credibility to an already awesome product.
TCL is a cross-platform reusable command scripting
language which has been shepherded over the last
decade by its creator John Ousterhout. Over the years it
has developed a large body of dedicated supporters
and clients. However, like many free software products, it
suffered from a credibility problem. Large companies
worried about investing in a purely free technology with
no 1-800-SUPPORT number.
By forming Scriptics, Ousterhout brought the respectability
Tcl needed to become a major force in application development.
Scriptics also allowed Ousterhout to take advantage of the
thousands of existing clients who were happy to "give back"
to the people who provided them with the tools they needed to
do their daily jobs.
The Open Source Business Model!
The ability of the OSS [Open Source Software] process to collect and harness the collective IQ
of thousands of individuals across the Internet is simply amazing. More
importantly, OSS evangelization scales with the size of the Internet
much faster than our own evangelization efforts appear to scale.
- Microsoft Internal Policy Memorandum
As you can see, there is quite a range of successful free
software companies in the market today. There is also
quite a range in the degree to which these companies
adhere to the noble ideals of the free software movement.
Some companies, like GNU and Red Hat, adhere closely
to the ideals of the free software ideology.
Others, such as Scriptics (as well as sendmail and ActiveState)
have as Tim O'Reilly notes, "explored hybrid models
which rely on [free software] ... for spreading the word,
fostering innovation, improving product quality, and
giving back to the community, but reserve certain products
as value added so that they can make money and survive to
further the cause."
Many more companies such as Netscape and Microsoft,
seem to adopt the model only when convenient to do so.
However they implement the theories, these companies all provide
Because, the range of actual implementations of
the free software model is so broad, we found it
useful to adopt the more broad term of "Open Source"
which came into vogue in the mid 90s.
The Open Source Model and Free Software Model in theory
are synonymous. However, the term open source came to
be used to describe a larger set of companies which
did not adhere to all the qualities of a free software
company, but perhaps some or most of them.
Another reason we chose to adopt the term "open source"
was because the term "free software" tended to scare off
some people, especially investors and large clients.
Though "open source" was not necessarily the best term
to describe the
free software, it did tend to be better for board room
For these reasons we chose to call ourselves an open source
company although we continue to support the ideals set
forward by the Free Software Foundation and the free
The Open Source Software Development Process
Recent case studies (the Internet) provide very dramatic evidence ...
that commercial quality can be achieved / exceeded by OSS projects.
- Microsoft Internal Policy Memorandum
As you can see, there
are many reasons why the open source business model works in the
information age market place. But, perhaps more importantly to clients,
the open source "software development" model also works.
The Open Source Software Development process produces
applications which equal or best applications produced in
Let's look at why this is...
Open Source is Robust Source
"It's a rare (and foolish) software outfit these days that does not
introduce its wares into the free economy as a beta version in some fashion.
Releasing incomplete "buggy" products is not cost-cutting
desperation; it is the shrewdest way to complete a product when
your customers are smarter than you are." - Kevin Kelly New Rules
for the New Economy.
The open source model produces
extremely robust code. Think of it this way, our code has been
in the public domain at thousands of sites for years.
If there were serious bugs or security holes, they would
most certainly have been found by now. In fact, over the years
we have had many bugs and some security holes reported to us.
These bugs we have fixed over time so that by now, our applications
are extremely robust. Further, we have also had customers
send in improved or more efficient versions of algorithms.
Because the customer can see the inner workings, they can
help us look for code inefficiencies.
Eric Raymond is one of the premier
supporters of Open Source Software Development. His site
is a warehouse of useful information. He makes the following
case for the robustness of open source code...
"Internet and Unix hackers, as a rule,
already understand the technical case for open source quite
well. It's a central part of our engineering tradition, part
of our working method almost by instinct. It's how we made
the Internet work....We all know how astonishingly reliable
the running gears of the Internet are relative to their
nearest commercial equivalents. TCP/IP, DNS, sendmail, Perl,
Apache...these open-source programs have demonstrated a level
of reliability and robustness under rapidly changing conditions
(including a huge and rapid increase in the Internet's size) that,
considered against the performance record of even the best
closed commercial software, is nothing short of
Open Source is Secure Source
"...The reason the closed source model doesn't work is that security -
breakers are a lot more motivated and persistent than good guys
(who have lots of other things to worry about). The bad guys will find
the holes whether source is open or closed.
Closed sources do three bad things. One: they create a false sense
of security. Two: they mean that the good guys will not find holes
and fix them. Three: they make it harder to distribute trustworthy
fixes when a hole is revealed." - Eric Raymond of opensource.org
Eric sums it up pretty well. Open source ensures that your code is submitted to the most
harsh and penetrating peer review possible. Such reviews include
bug checking, security attacks, and benchmarking.
What is better is the fact that the
people trying to over run your code are not hackers but customers! If a
bug is detected, it is usually detected by a friend first.
And, as Eric Raymond says, open or closed, the "bad guys" will find the holes. The
security through obscurity of closed
source is only an illusory veil of security. Security hole announcements
in such closed systems as Windows NT have been as regular as those
announced for open source code such as sendmail. The big difference
between the two lies in the emergency response time.
The rate at which security holes are patched in open source companies
is far shorter because the whole community can mobilize to deal
with any emergency.
Open Source Keeps a Company Small and Flexible
"If you give everyone source code, everyone becomes your engineer" - John
Gage, chief scientist at Sun Microsystems.
We are where we are today only because of all the hard work that has come
out of the community of developers and users that has grown up around the
code. These developers have tirelessly sent in their ideas for fixes,
features and extension technologies. They have kept us close to them and we have
always kept our ears open.
The fact that the network of developers around the applications has been
so prolific is more than just gratifying, it is a crucial feature of
The fact is that we could never hope to hire enough talented people to
write all the code that this market will support. We could never afford
to find office space for them and we could never hope to get them all to
physically move from where they are to where we are. Even if we
could manage that, actually hiring all those developers would bloat us
Fortunately, as Eric Raymond writes, "Even a small open-source project can muster more
brains to improve a piece of software than most development shops can
We know from experience that every line of code you write for
the community is returned many times over. The generosity
of open source development is certainly a form of enlightened
self interest. If you have a moment, check out some of the fabulous
"hacks" that have been submitted back to us by the community.
Open Source is Market Driven
"In the network economy, producing and consuming fuse into a single
verb: prosuming" - Kevin Kelly New Rules for the New Economy
There is another benefit of bringing your clients into the development
process. You become extremely sensitive to the demands of the market.
There is no period of isolated research and development. The fact that
the customers can play with the code means that
they truly understand what is possible. They are the best source of
direction that we could imagine since they are actually using the code
to do work. And they, as a group of thousands, are endlessly, 24-7, demanding
"By releasing Open Source Software, you contribute to the
overall health of the programming community...[however]
You benefit from the entire ecosystem, not just from the
input of the community into your own specific
project." - Tim O'Reilly (www.oreilly.com/ask_tim
After doing our research, we started discussing our ideas with a select
group of clients who we thought would give us useful input about how they,
as clients, would like to see our business evolve.
We were initially very concerned that people would feel betrayed
that we were moving from the not-for-profit sector into
the corporate world. However, that is not at all what happened.
Every one of the interviewees expressed that they were thrilled about the
evolution of our site and code to a more professional form and were happy
that it would mean more regular and powerful upgrades to the applications.
The key of course, was how to develop a sustainable business model. How
could we make enough money to afford to devote all our time to the
Check out why we named
Leveraging the Product Halo and Gaining Market Share
Well, as you can see from our Product Purchase
Plans page, we developed several plans, most similar to Red Hat's
We are selling two license agreements that provide customers with CD-ROM
distributions, printed documentation and support. We also sell a larger
support package that lasts longer than the license agreements.
Yet clients need not purchase the licenses at all. Our applications
are still free for anyone to download and install. This is
important because of our desire to remain true to the idea that
everyone on the net, regardless of income should have equal
access to the basic technologies of websites. Providing
software at no price also helped us continue to maintain
and expand our market share.
Because our applications are open source, clients are welcome
to download applications for free and follow the
installation documentation in order to get them working.
However, the fact that the software could be obtained at no
cost, did not mean that we did not "sell" products.
Although we are proud of the
user-friendliness of our documentation, clients often find
that installation and customization might take some time,
especially if they have limited programming experience.
The fact of the matter is that Web
Applications are not exactly the easiest things to implement.
In the end, clients must ask themselves, "Do I
want to spend my extra time learning to program or
selling my products?" The answer is often that they do not want
to learn programming. And that answer means a sale for us.
Besides our license and contract products, like GNU, we also have
developed a host of support services such
as training, tech support, turnkey installations and custom app
The Care and Feeding of Networks: The Hub Model
"In the past two decades, largely because of the ease, speed and
low cost with which information technology allows people to keep
track of who's doing what, coordination has become faster, cheaper
and easier. Economic logic favors outsourcing....Virtual enterprises
can spring up overnight as networks of free agents come together
for a single project. Costs and risks are distributed over an
entire network....Nothing could be more flexible - ready to turn on
a dime, to grab any new opportunity." - Robert Reich in Fast
Company November 1998.
We also created The eXtropia Developers Network (DevNet).
Originally, the intent of the DevNet was humble. However, the
evolution of the DevNet over the life of the company has been
Originally, based upon what we knew about the market, we realized
that once we seriously went forward with eXtropia,
we would get far too many requests for custom app development
and turnkey projects, in too rapid a succession, to possibly
keep up with.
At the time eXtropia first opened it's doors, we received an
average of seven requests for contracts per week. During the
first quarter of eXtropia's life, that number scaled to 20 per
week. In the second quarter, we expect to see that scaling
continue on its non-linear track.
We also knew however, that we did not want to make the same
mistakes that other startup IT companies make of scaling/staffing
up too quickly. It was essential for us to stay loose and nimble, yet
it was also essential for us to address the needs of the market.
We needed to "staff up" in order to meet the demand, but
we did not want to hire, train, and provide office space for
developers who if drawn from a single geographical locale
would most certainly not represent the best of the
We needed to create a virtual distributed network of world-class
developers who could be assigned individually or in commando
programming teams anywhere in the world, for any number of
very proprietary and tough projects.
The DevNet was our solution.
At the outset, the DevNet worked like this. Developers were
offered the chance (via a web page advertisement) to apply
for positions in the network. The application process
involved a developer submitting a resume and a list of references
and/or code samples to us as email.
As applications came in, we reviewed the
qualifications of applicants, browsed code or reference sites,
and initiated email chats with candidates to get a feel for their
personalities (in many cases of course, we already had
known the applicants because they had been part of the eXtropia
community for a long time).
If the applicant met our criteria, we would offer them a position in
Our criteria for accepting applicants went as follows:
The applicant must have an exceptional ability to code or
customize web applications. As such, they should be fluent
in HTML and Perl/CGI, but should also have skills in some
other area(s) such as Java, XML, ASP, COM, or SQL.
The applicant must be a pleasure to work with in a
distributed group programming environment. The applicant should
be patient, dependable, considerate, careful, trusting, trustable, humble and not
prone to jumping to conclusions or into flame wars.
The applicant must be serious about freelance web
consulting. Preferably, the applicant should have his
or her own freelance web programming company rather than
doing web programming on the side. The applicants livelihood
should depend on providing quality, full-time services to
The applicant should introduce diversity into the group.
For example, as the membership expands, applicants with
supplementary skills should be chosen over equally skilled
applicants with duplicate skills. Also, a mix of races,
genders, ages, and nationalities should be held as an ideal
even if it means, for example, letting in an ace student with
little real-world coding experience over someone with more
experience but with duplicate lifestyles to other DevNet members.
If the developer accepted our invitation, they would pay a
membership fee, and would then be accepted as a DevNet
So what does a DevNet member get for their membership fee?
Developers who joined the DevNet received a host
of services such as training, free
software and support, and easy access to us. However,
the primary benefit of DevNet membership focussed around
a job referral system and a members-only discussion forum.
Developers knew that their $1,000.00 investment would pay off because
they would be getting a steady stream of contracts from us. Currently,
DevNet members count on an average of 1 contract per week. Most
contracts average between $500 - $1000 per project and rates across
the DevNet are kept standard at $75 - $100.00 per hour.
As we said, aside from the job referral program, developers had the
opportunity to participate in three members-only online discussion
forums. The forums included:
The Jobs Forum: On this forum, new jobs are assigned to members,
and members can comment on the progress of current contracts.
The Tech Forum: On this forum, developers ask each other
technical questions about projects, bug fixes, or just any old thing
of interest. In this forum, the developers can work together
so that anyone can ask for free technology help from the
network and get quick, reliable advice.
The beauty of this is that members can rely on the core
capabilities of other members. Why
should one learn MSQL for example, when we have someone
with that skill already in the group. Each member becomes
a programmer with the skill set of the entire Network
at their disposal.
And clients know that. Clients know that they are hiring
more than a single developer but an entire network.
We also harness the collective knowledge of the network
through our tutorial series. In short, every two to
three weeks a developer is responsible for preparing a
short online tutorial on some web-based technology
for presentation to the DevNet membership.
is also responsible for answering follow-up questions.
Because we have capped our membership at 20 until the
summer of 1999, each developer only has to prepare
one tutorial per year, but has the benefit of learning
a new topic every few weeks.
The Open Forum: On this forum, members discuss
miscellaneous issues such as small business tax,
freelance consultant pricing strategies, liability law,
or just talk about their families, lives, and interests.
However, no less important than the job referrals and
discussion fora, were the less obvious benefits to members...
Members gained the opportunity to work with "the best"
web developers on the web. The Developer Network has a
reputation. "If you want your job done right, done
quickly, and done securely," clients like
Co. say, "talk to the eXtropia Developer Network gang!
They are worth every penny"
This reputation benefits everyone involved. As in real
estate, if you get all the big names to setup shop on a
strip of land, the value of everybody's investment goes
The network also allows us to organize "commando
programming" teams for "LARGE" corporate web site
work that none of the developers could
get or manage individually,
but which pay a much greater amount of money.
Further, projects can pop up anywhere (in the US for now)
and we can be relatively sure that we will be able to find
a DevNet member on the ground.
Also web design firms can subcontract us out. This is an
important feature of the DevNet. Just as each developer
creates a link in our private network, so does the network as
a whole create a link on a greater network of web professionals.
Many web design firms have chosen to work with us to expand
their capabilities. They can focus on honing their
design talents knowing that they can depend on us
for outsourced backend development.
Members also gain a sense of security and team which
can be very important to someone who has struck out
on their own into the world of self-employed-dom.
Further, members have the benefit of seeing the new
technology first. To a large part, we rely on the
DevNet members to be our first line of beta testers!
DevNet members gladly provide beta testing services for free
because they will be the ones called upon to customize
and install new libraries and applications. And because
there is some competition out there, they have
a special interest in getting to know the technology
before anyone else does.
Finally, DevNet members have an especially profound impact on
the direction we take with our company and products. Through
their comments and discussions, we glean many important
insights into how to better design our products. Though we
are careful to be very sensitive to the outside world, because
of their proximity, the voices of the DevNet members are
always the loudest.
As we write this study, we are approaching the end of the
first quarter of the existence of eXtropia. However, though
only a short time has passed, we have learned a great deal.
Granted, we as an engineering-based management team have
learned all sorts of things about sales, marketing, management,
finance, and law. Starting a software business has
surprisingly little to do with creating software.
However, more interestingly, we have learned a great deal
about how to run our own brand of open source software.
Some of these things will be very useful to other
companies in our situation. So to conclude this
document, we would like to distill some of the knowledge
we have gained.
"The network economy is founded on technology, but can only
be built on relationships. Start with chips and end with trust"
- Kevin Kelly, from New Rules for the New Economy.
Probably the most important lesson that we learned was that
in a distributed network, like an open source community, or
a decentralized network or developers, trust is central to
Trust is essential because control is impossible.
What do we mean by this?
Well, the first thing to understand about networks is that they are
anarchistic, decentralized, lawless, and shapeless creatures.
In a true network, there is absolutely no central authority which
dictates communal direction. There is no structural basis upon
which to form consensus. No laws, no leaders, no police force.
As in the case of the Internet, order in a true network must emerge
from nothing but the interaction of fully independent network nodes
(people or other networks in our case). As the science of complexity shows,
emergence of order from nothing is possible, but sometimes counter
Consider a beehive.
"The marvel of 'hive mind'," writes WIRED editor Kevin
Kelly in his book Out of Control,
"is that no one is in control, and yet an invisible
hand governs, a hand that emerges from very dumb
members. The marvel is that more is different. To
generate a colony organism from a bug organism
requires only that the bugs be multiplied so that
there are many, many more of them, and that they
communicate with each other. At some stage the level
of complexity reaches a point where new categories like
'colony' can emerge from simple categories like 'bug'.
Thus, there is nothing to be found in a beehive that is
not submerged in a bee. And yet you can search a bee
forever with cyclotron and fluoroscope, and you will
never find the hive."
The hive emerges from the bees not because the bees intended
to create the hive or because they were programmed to
do so. The hive comes about as a property of the system created
by many bees in a network.
The emergence of the hive from a jumble of bees is Extropy.
Networks that work, like beehives, for all their lack of authority,
are not at all chaotic. However, their order is self-emergent rather
than dictated by law or force.
I say networks "that work", because not all networks succeed.
Extropy is not at all guaranteed by collecting a horde of
independent nodes and allowing them to communicate.
It is true that extropy depends on the free flow of information
and the uninhibited interaction between the nodes. But it is also
true that this in turn, depends on trust.
Each node must be able to trust other nodes in the network or
they will not interact or communicate.
Nodes must be sure that every other node is working for the
benefit of the whole by facilitating the network, and not
Of course, "working for the benefit of the whole" is not some simplistic
stereotypical call for a Marxist utopia of self-negation. Nodes can trust
each other and work for the greater good of the collective while at the
same time pursuing their own self interest.
This is because the network's collective strength can be leveraged by
each node (like when a developer doesn't have to learn MSQL). In the
post-industrial economy marked by hyper-speed, hyper-specialization, and
hyper-customization, serving one's network is the smartest selfish
strategy. it is enlightened self-interest.
Selfish actions, so long as they do not threaten the collective, are
good and to be rewarded. After all, it is in the best interest of all
the nodes to allow and to facilitate the growth of any other node in the
network. As we said before, the value of any member's network membership
increases as any other network member gains prestige.
It is only when network members are forced into a prisoner's dilemma
that emergence of the network is threatened. The minute you cannot
trust your back to the other network members is the minute the network
stops generating a value greater than the sum of its parts.
That is, there is a right way to be selfish in a network and a wrong way.
Network economies can be far more creative and lucrative than
shortsighted selfishness-based models, but shortsighted nodes
can certainly ruin the network by disrupting the ties of trust.
The trick in creating the self-emergent network is to structure
it such that "good" selfish behavior and node interaction is
supported and "bad" selfish behavior is punished.
This rule was made clear to us early on when we were
figuring out how to assign jobs to the developers in the network.
In the first weeks of eXtropia, we decided to post jobs to ALL the
DevNet members as those jobs came in. We thought, somewhat idealistically,
that jobs would somehow emergently, magically distribute themselves to
the right developers. Members would decide amongst themselves who would
do the job. Unfortunately, we did not get the desired results. No
self-emergence occurred. Instead, this free-for-all style of job assignment
turned out to undermine trust within the network.
For one, different developers were online with greater frequency
than others. Also, each developer had different personal style. Some
were far more aggressive than others. In the end, jobs would be grabbed
up unfairly and not efficiently.
After a great deal of discussion among all the members, we decided to
try the same idea on a smaller scale. We would assign jobs to three
developers at a time. We thought that this methodology would give the
client a better choice, would facilitate emergent order, but reduce the
amount of unfairness in a free for all.
That method too, did not go over well. Clients were confused by
multiple proposals and developers felt as if they were being pitted
against each other when they did not want to be.
In the end, we decided on a simple random rotation system in which jobs
would be assigned in a turnstyle order to the list of developers as
they came in. The randomized system promoted fairness by its very
structure. Members could feel as if they did not have to fight with
However, though structural randomness did promote trust, it did not
promote fairness or efficiency.
For example, through the luck of the draw, we found that some developers
would have streaks of bad luck and end up with a run of cruddy jobs.
Others would end up with more work than they could handle. Further,
random job assignment did not take advantage of the natural strengths
within the network. A Sybase job was assigned to the next developer in the
rotation not to the Sybase specialist
As a result, we modified the random turnstyle approach by increasing the discretion
of the "job assignor". The job assignor was given the responsibility and authority to
take a certain degree of liberty with the basic randomness. If a
developer seemed to be getting shafted too often, they would get an extra job
every now and then to make up for it. In the end, the developers need
not make the same money from jobs, but should at least meet a
minimum standard. Further, jobs could be assigned with a little more
This modified random assignment system has worked very well. Over time,
randomness modified by honesty and reason proved to facilitate an even
greater degree of trust between members. That fact that job assignment was
handled with reason and humanity, increased the respect the members had
for the system.
The next time we were forced to deal with issues of trust was when
we faced the problem of how to deal with code developed by DevNet
members. Specifically, within the open source community, how were we
to deal with the ownership of original works.
Some of the DevNet members believed that all the code developed in
the context of network jobs or the eXtropia application base should
be "returned" to the Open Source community. In their minds, it was the
responsibility of the DevNet to set an example for the outside world.
Open Source should be embraced by those closest to the source. Further,
they argued, too much of the development of the code was tied to the
community for it to be commodified.
Others appreciated what eXtropia did and what open
source stood for, but felt that they could not compete in the
marketplace while supporting such high ideals. They wanted to keep code
proprietary, or at least shared only within the DevNet so that they could
extract some value from it while there was still value to be extracted.
The problem of ownership was in fact a general problem,
even with developers outside the DevNet who were contributing code.
The schism between the two camps caused quite a bit of tension and many
developers felt used by others. The fact in an open source community
is that there will be as many purely parasitic fringe members as
their are true contributors.
In the end we took a very liberal perspective, and one which supported
trust systematically. We decided that no one should be forced to do
anything they were not absolutely comfortable doing. We, Gunther and Eric,
would set a good example and continue to commit all our code to the
public domain, but would not require anyone else to do so.
The good example and the extension of trust, as expected, had positive
In the end, the majority of code developed within the network was
submitted to the public domain and those who did not, were accepted
into the community nonetheless. This accepting of the rights of others
glued the community together in a powerful way and later, those who
worried about their code, ended up submitting it anyway in many cases
because they saw from example that doing so did not hamstring them
in the marketplace.
On a grander scale, our attitudes about open source gained us trust from
the clients and general web development community as well. In fact, it
could be argued that the seeming selflessness of public domain
contribution was the primary factor in our success. Good will was paid
back in trust and trust could be capitalized upon; Capitalized upon in
ways that further supported trust.
The maxim we learned from the experience was that in the open source community,
profit for profit's sake alone was not the right mission. Yet good will
for good will's sake was not right either. An open source company, we discovered,
must seek good will for profit's sake. For only by following an
enlightened capitalistic path could we both bring positivity to the
marketplace while still surviving in it.
"There is another kind of skill not normally associated with software
development which I think is as important as design cleverness to bazaar
projects -- and it may be more important. A bazaar project
coordinator or leader must have good people and communications skills."
- Eric Raymond, from the Cathedral and the Bazaar
Once we had created a network structure which facilitated trust between
members, we were faced with another dilemma.
Originally, we had assumed that software development would sort've take
care of itself if we created the network. "Get them together, and it will
be built," was our motto.
However, in reality, that model did not work. To organize a massive,
distributed programming effort seemed to require some type of
organization. Software applications did not simply emerge from
a network, even if it were built for emergence.
The problem was determining exactly how to direct the developers. In
discussions with our core team, and in researching open source
development models through resources such as opensource.org,
we identified three possibilities:
The Cathedral Model
The Network Model
The Hub (Bazaar) Model
The Cathedral Model was actually most similar to the model used by
Selena Sol's Script Archive in the early years. In this model, a core
of developers writes applications and application libraries from start
to finish. Once completed, this code was released to the general
public. Bug fixes and enhancements would then be emailed back to the core
team, and a second round of development would commence. With this approach,
the only difference between a traditional software house (like Symantec or Microsoft)
and an open source software house was the fact that the code was available to the
client. This design process was the same
The Network Model (which was most similar to the model used by Selena Sol's
Script Archive from years two through five) followed a different path.
In this model, development was be opened up to all developers
in the community and a central repository (website) would be used to distribute
all the resultant code. This model was used successfully by the open source
Neither of these models worked for us in the long run however. The
main problem with them was that neither of them scaled particularly well
in our case.
As we said, during the first couple of years of the Selena Sol's Script Archive,
the Cathedral model was used as the development model. Gunther and Eric would
spend a certain amount of time interviewing customers, gathering feedback and bug
reports, and investigating competitive products. Then, the two would go into
seclusion while they brewed up the next versions of the applications.
However, we realized fairly quickly that the Cathedral model was not
scalable at all because we did not have enough time to keep up with
all the modifications requested from the community.
Further, because we kept code to ourselves during the
development process, we got far too many things wrong. Either we would add
options which clients didn't want, or we would not add options that clients
did want. The Cathedral model became far too much work with far too
The amorphous Network Model was meant to replace the Cathedral Model
for us. By the third year, we found that we could rely on a avid and
vibrant community of developers to send in their own modified versions
of our code. In fact, we got thousands of lines of free code which
went into our massive offsite resources list.
Unfortunately, the Network Model turned out to be unscalable as well
because there was far too much duplication of work as well as schisms
and inefficient sharing of ideas. There were dozens of developers all
developing similar ideas in tandem, writing code which was almost, but
not easily combinable.
Truthfully, in the later three years of the
archives life, much less functionality was actually produced even
though double or triple the amount of lines of code were added.
eXtropia goes with the Hub Model
By the time eXtropia was formed out of the Selena Sol Script Archive,
we had realized that another development model was necessary.
The new model was the Hub Model (essentially like Eric Raymond's
Bazaar Model but with a but more control exercised by the lead
project developer) which we found to be the only
way for us to manage a scalable open source project.
In the Hub model, a core team of developers provided
open standards and sample implementations and documentation.
These standards would be released and supported, but the community would
be relied upon to implement the standards into real world applications.
This model seemed to take the best of both of the other models. On the
one hand, we controlled the standards absolutely. However, we did so
with care. We sought feedback from developers but at some point we
ultimately made decision about architecture and direction,
and the developers grew to trust us implicitly based upon our history of
Good leadership was essential, but so long as that leadership was
provided, the model produced very scalable, directed and efficient
The hub model with its focus on leadership, also had other
For one, the hub model allowed for the network to be represented by
a figurehead or a unified entity. This was of crucial importance
for marketing and sales. Without a collective identity, the network
found it difficult to advertise itself. The "Developers Network"
was much less marketable than the "eXtropia DevNet".
Further, internally, the adoption of a central shepherd
was an important rallying point for raising morale. The hub
gave us all a banner to wave. Certainly, the network was its own
complex creature, but people, need simplicity in order to get behind a
cause. Having the eXtropia banner was what was needed.
Redesigning the Code for the New Model
Finally, settling on the Hub Model, had several major ramifications on
the design of our applications. Click
here to read about the technical changes.