"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 at the 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.

"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

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 thank you.

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 customizing them.

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 validation services.

By this time, the popularity of the site was raising several eyebrows.

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, and Wiley.

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

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 web technologies.

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.

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 Website)

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 service website.

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 mid-eighties.

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 your neighbor.
• The freedom to improve the program, and release your improvements to the public, so that the whole community benefits.

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.

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 abound.

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.

"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

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?

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 every day.

"...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 them free.

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 Barlow and Dyson both show in their discussions of Intellectual Property in the Information Era, in the digital economy, market share is everything.

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.

"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

Scriptics 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.

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 useful examples.

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 ideals of free software, it did tend to be better for board room discussions.

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 closed environments.

"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 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.

"If you give everyone source code, everyone becomes your engineer" - John Gage, chief scientist at Sun Microsystems.

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 model.

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 into paralysis.

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 possibly afford."

"In the network economy, producing and consuming fuse into a single verb: prosuming" - Kevin Kelly New Rules for the New Economy

"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 November 21)

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 project?

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.

"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.

Originally, the intent of the DevNet was humble. However, the evolution of the DevNet over the life of the company has been astounding.

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.

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 web.

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 the DevNet.

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 their clients.

• 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 member.

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.

  The developer 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 Franks Supply 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 up quickly.

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.

"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 all else.

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 intuitive.

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 simply leeching.

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.

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 their peers.

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 intelligence.

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 results.

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.

"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 resource, CPAN.

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 little input.

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.

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 decisions.

Good leadership was essential, but so long as that leadership was provided, the model produced very scalable, directed and efficient results.

The hub model with its focus on leadership, also had other unexpected benefits

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".