Concerted Disruption, Climb Aboard


The Free and open source software (FOSS) movements continue to change much about the software industry, some would say "disrupt much about the software industry." From development processes; to customer demand and support; to business models; to innovation and invention; to social, political, and legal implications; we are in the midst of reconsidering the interconnection of these elements. It started with the birth of a few concepts, licenses, and software programs, but the community these enable, is what makes its growing impact persist.

The community, a term bandied about at some point in almost every discussion or article concerning open source, is rarely given the credence required in arguments considering the real power and utility of FOSS. I hope to shed a little light on what the community means and how to harness, or better, take part in its potential.

I'll start by covering what a FOSS community is. Namely, who it includes, what it involves, and why FOSS practices enable such a community. The second portion of the article will cover what this community means to the software user, organizations that buy into a FOSS implementation, and why it is so powerful. Finally, it will be time to address the software company that sponsors the open source project itself. How does a sponsor establish, maintain, and leverage its community?

This is Part One of a four-part note. To better understand how the community works and how to keep it flourishing, extensive interviews with FOSS community leaders will follow this article in parts two, three, and four. I'm referring to Jeff Bates of, the OSTG, and co-founder of Slashdot; as well as two people within CollabNet's employ, Karl Fogel, a founding developer of the Subversion project, and Louis Surez-Potts, community development manager of the project.

Who is the Community?

It's easy to see that the community includes developers writing programs and others creating supporting materials, but it also includes end users, software or enterprise services companies, consultants, resellers, and the list continues on and on. Any of these people or groups may access the guts of an open source project and may contribute to the project. In the open source context, the distinctions between software vendors, consulting organizations, and client organizations must be understood differently than one normally would by the traditional buyer/seller boundaries entrenched in the software industry. Furthermore, the notion of companies extending their development processes to include customers' input cannot just be lip service, as a customer can now contribute to a software project and potentially see its contribution incorporated into the software release.

I'd like to assert a new distinction. The basic and broad taxonomy of the software industry's entities has changed from one that included demarcations such as software supplier, consumer, and consultant (or some type of third party, which for example, helps select or implement the software); to a taxonomy that includes a software supplier, consumer, consultant, and now a core project team.

We'll see that this core project team plays a crucial role in the world of Free and open source software. The core project team, in this context, coordinates its community and is responsible for guiding the direction of its particular open source project. The community may have been formed by a software company or it may have formed independently but regardless, it typically thrives from the labor of a company's developers, by resellers, by consultants, by clients of a sponsoring company, and other individuals.

What it Involves—from the Start

The benefit of FOSS communities is the inherently collaborative means by which they must achieve their results. Let's begin with the individual programmer; later I'll expand this to entire organizations. A lone programmer may accomplish a lot, but one programmer cannot do everything. Once other programmers can access the source of a program they may make improvements, add new features, fix bugs, or completely develop new and innovative uses for the project that may not have been envisioned at all by the original programmer.

Compare this, for example, to what artists have long grasped; inspiration can be provoked by different sources, so exposure to, and the interplay of ideas between different peoples' work is vital for one's own new work. Similarly in writing code, one programmer may learn techniques by studying another's code. If our lone programmer's code gets the attention of someone with a similar problem to solve, she benefits because the new person can collaborate with her to close the gap on a problem. Likewise, if the software project isn't entirely satisfying someone's needs, that person can adapt it for his own sake.

By nature, the guts of an open source project are exposed to the public. When a programmer licenses her code under a FOSS license, she is at least asserting her recognition of the possibility that other people may want to study, modify, or otherwise use code she has written. If she did not care to enable other programmers with that possibility, she would not need to put the extra effort into licensing her code with a Free or open source license. This is important to keep in mind, because in the programmer's recognition of how other programmers might be interested in her efforts, we can start considering why the FOSS community is what it is. Namely, it's a community working on projects in a way that transcends the boundaries of the software industry (I labeled these boundaries in what I called a taxonomy earlier).

Different skills come to play in this process too. Take documentation—a programmer might be very skilled in writing code, but perhaps she does not have the skills or time to write a manual for the people that will use the program. Someone else, possibly a user, might decide to write documentation for his own use, why not contribute it back to the source of the project, that way if there is an error, someone could uncover it and others can add to it based on their own knowledge and skills. This is just a little bit of the collaborative work that takes place within a FOSS community. Remember that because the community is a superset of companies and all others that choose to participate, its potential size far outstrips any single one of the world's largest software organizations. Let's see how our programmer's recognition of what her peers might want to do with her code, enables this community to develop.

FOSS Galvanizes Communities

Why does Free and open source software galvanize communities? It not only permits but, in a sense, encourages people's freedom to engage with software in ways that would not be permissible under a non-FOSS style of license. That means the development process expands to an extensive range of people that would normally be prevented from contributing. FOSS licenses often include provisions that ensure the modifications people make, perpetuate the freely accessible nature of the software's source code. The more people work with such projects, the more such licenses aid the project's growth.

Since the Internet is the medium for communication and collaboration, the open source developer finds herself with an immense pool of potentially interested (or as the case may be, uninterested) parties, which also leads to some peculiarities in both managing and encouraging open source communities. I will highlight these as the corresponding interviews will further discuss in-depth.

Establishing Community

Let's look at this from the perspective of a company that wants to provide open source software. Such a company wants to develop a software solution to address some issue its founders have a bit of expertise handling. Its founders wonder about a few things like:

  • What can I do to get my product into the market quickly?

  • How can I introduce my solution to the widest number of potential clients possible?

  • How do I compete with established competitors?

  • How can I take advantage of top development and support methods?

Establishing and nourishing a successful FOSS community can help ease many of the concerns above. This is not without its pitfalls, and when not done with care, can lead to difficulties coordinating the project or even the self-destruction of the project. When done well however, the project can catch the attention of savvy developers, getting an extra push toward its introduction to clients, and find itself launched within a massive viral marketing-like and distribution strategy—namely, the result of the infinitely reproducible Free and open source software.

A company centered around providing or servicing open source solutions participates in a community, which enables it to introduce its product to more clients than other methods afford, as well as tap into that superset pool of potential developers and quality assurance personnel. It can distribute its product incurring little cost to do so. Using FOSS licensing promotes extensive and cost-effective distribution of software solutions because everybody is free to redistribute said solutions. Thus, distribution is not limited by points of contact such as proprietary vendors or networks of VARs, rather it is expanded beyond those boundaries to include its entire user base as potential distributors.

It's not difficult to see the benefits this distribution method potentially garners a company trying to make itself known amidst a mature software industry. Look at the publicly available statistics on This open source development hub alone boasts stats on its front page of more than 1 million users (as of this writing). Open source enterprise darlings have racked up downloads of their products over the last few years in the neighborhood of, Compiere over 800,000 and SugarCRM closing in on 200,000. The office productivity suite has counted over 40 million downloads of its source and software since inception in 2003. Not only do most Linux distributions come pre-packaged with hundreds of such applications, it would be difficult to find a major distribution, which didn't include This is simply to say, there are a lot of people and companies in the world being exposed to, and trying out these systems. While I will not address how such a distribution method relates to revenue, there are plenty of examples (refer to the business models of Red Hat, SugarCRM, ComPiere, or IBM).

Support is a similar story. Companies are rising to support, implement, and customize open source solutions; such services are available with the expertise, for example, of companies like Red Hat. These businesses are enabled via the wide distribution and the development methodology, which is a function of the community—it is the community providing ideas and labor. And the fact is, support and implementation practitioners are not indebted to the open source community, they are part of it.

In supporting a software solution that a) encourages the freedom to participate in making the software into what the customer needs, and b) typically can be obtained and used by any customer without a prohibitive cost barrier, a company providing a service around open source software knows that in seeking business prospects, its clients may have not only sampled its software but already adopted it—certain of existing needs.

Assuming the notion of open sourcing its product appeals to a company, enjoying any advantage of being part of the FOSS community entails an awareness of how to participate. How does it attract developers to its project? Once the project starts gaining traction, how will it keep the interest of people contributing to the project and ensure the project continues on track? What happens when competitors get ahold of the project? What can the initiating company do to engage clients as part of its community and thus support a more complete offering? Because a company decides its project will be open source, does that mean it will attract massive quantities of programmers wanting to build it and improve it? The answer to the last question is a definitive no. Open source is far from a magic formula for brewing software. We can see answers to the other questions from the experience of the community itself, let's consider them.

It's time to recall the notion I put forth at the beginning of this piece regarding the taxonomy of entities in the software industry, namely the distinction of a core project team. In the FOSS community sense, this is the team coordinating the project among its participants. The existence of such a project team and community manager seems to have evolved from the development requirements of groups who are not only physically dispersed but sometimes have differing objectives toward collaborating on a project. This person or team has a number of responsibilities that will be key to ensuring the project's success. Any company that doesn't take care to heed these things will have a hard go at breathing life into its open source project or reaping any rewards from it.

  1. Engage developers or support people, and other contributors in ongoing, meaningful discussion about their work and the project's direction

    This seems to be the top item on the list for maintaining developer interest. The individuals I spoke with for this article were unanimous in claiming that a thriving project needs both regular communication and recognition between its participants. Participants must be a part of the decision-making process. The project needs its managers to respect the efforts of its community. When the managers do not engage the developer community with interesting challenges, constructive feedback, and especially, positive recognition or high-quality criticism, the developers will indeed lose interest and leave the project—diminishing the activity of its community.

  2. Ensure there is a low barrier toward participating

    The easier it is for developers to get an understanding of a project and contribute, the more likely it is to hold their interest. This involves basic technical requirements for the infrastructure to make it both easy and possible to be involved in the project. It includes usable access to things like file repositories, bug trackers, discussion mailing lists, and other tools related to a development process that takes place entirely via the Internet.

    It's important to remember that FOSS development gains the critical mass it requires, by-and-large from taking place through collaboration that would not exist without the worldwide connectivity of the Internet. This implies a responsibility on would-be developers to uncover the methods employed by a given project's community for contributing to that project; if they cannot easily understand and use these, they will probably give up on the project.

  3. Make the community aware of project roadmaps

    It sounds simple but it's sometimes neglected. The roadmap showing the project's targets and milestones achieved, offers developers a sense of the problems, tasks, and challenges on which to latch their interest. It's also important for the sake of the end user. When users can understand the direction in which the software development is aiming, it helps them decide whether it will align with their needs down the road, whether it will be a good choice to pursue. Indeed, users ought to be provided a means for influencing the roadmap. After all, users are as much a part of the community as developers, and their feedback will help drive improvements to the software.

  4. Seed credibility by communicating clearly and honestly between the various groups participating in the project (this includes sponsoring companies, individual developers, end users, support personnel, etc.)

    When the project is initiated by a sponsoring company, clear communication and participation help demonstrate to developers outside of the company's employ that the project, while perhaps guided by an active group within the company, does not intend to just sponge off of the work of others. Users and third party support should see that their participation in the project can go two-ways. For example, if an end user organization deploys the project's software internally, with the understanding that one of its strengths is its open source community, the organization's decision will be positively reinforced when that community is maintained in a healthy, constructive manner, and not ignored to the point of disappearing.

    When the open source project is started by a company as a focal point around which it builds business, it cannot afford to alienate any part of its community because that implies the risk of also losing its clients. This can even include its competitors, since they may be just as much a part of the community. It will be in the competitors' interests to contribute in a like manner to the project—their interest toward its improvement is as great as anyone else's. This would be a case where the core project team or community manager takes on the role of liaison. Since a hallmark of Free software licenses is that they perpetuate the openness of changes, additions, improvements, etc. in the software, the source of such changes, whether it be competitor, client, or individual developer, is beside the point.

    One way that this can be exhibited is for the sponsoring company not to give its developers special advantages over others in the community. For example, Karl Fogel mentioned CollabNet does not give its own developers rights toward committing changes to the open source Subversion project without going through the same community process, which includes "posting patches, receiving review, being nominated for commit access, and being voted on by all the existing committers."

  5. Verify that the software matters

    A company initiating or sponsoring an open source project generally does so for one of two reasons. Either it needs a software solution or some type of custom add-on to an already developed system for its own use, or it intends to build or maintain business around supplying, implementing, consulting, or offering some otherwise related service based on the software.

    In the first case, the technology matters to the company itself. However, if it doesn't matter to anyone else, the company may have a difficult task in fostering a community. There are a number of reasons they may have chosen to develop it as a FOSS system. For example, if the requirements for developing the software are outside the company's real business focus, it may not want to direct the necessary amount of its employees' efforts toward developing the software completely in-house. Because the software may be potentially useful to others, the idea that an extended community can contribute to its improvement suggests at least the potential of a cost benefit toward obtaining the software. That is, the company may dedicate some development resources to the project and bring it to fruition with the aid of the community, but would not seek a third party from which to purchase the software.

    In the second case, the impact may be greater. If a company intends to maintain or build business around supplying or offering services based on the software, it had better determine that the software will matter to its audience. If nobody cares about the software it will be very difficult for the company to attract developers, users, competitors, and build its community.

The User/Consumer Entity

Finally, of all the pluses we entertain FOSS means to the enterprise business world, things like cost savings, absence of vendor lock-in, security, reliability, and perhaps a lower likelihood of future support problems, the most important and fundamental aspect is the community.

End-user organizations don't believe that a vendor just giving you access to its source code is providing even remotely the same thing as obtaining Free and open source software. You will be a singular instance, isolated from the collaborative growth of a real community. You will be the proverbial child raised by wolves, maturing with no conception of how to operate in human society. What do I mean? There are vendors who will provide software, allowing their clients to view some or all of the source code, under certain agreements, which in fact restrict the client's freedom to modify, reuse, redistribute, or share it with others. Licenses with restrictions on modification, redistribution, and sharing prevent entities from forming a FOSS-style community. In some instances, such vendors will even use wording that promotes the impression that their licenses are somehow similar or "as good as" Free or open source counterparts. In many cases, vendors themselves will say that many clients never have an interest in modifying the source code so, the vendor would argue, it's really not that important. This however, is just side-stepping the real issue and has little to do with what is really important about FOSS access to source code.

The real importance is that the ability to examine, modify, and redistribute the software's source code fertilizes the interplay of ideas, development innovations, and promotes cost-effective labor collaboration across a boundary-less global community (even if the impetus for these things does not come from the end user). It permits those involved, an expanded capacity to address their objectives with access to greater sources of support. As the basis upon which the community builds, it is the disruptive type of FOSS source code availability, which has put software solutions within a more accessible reach of user organizations. And that ought to be appreciated by any software consumer.

This concludes Part One of a four-part note. Part Two features an interview with Jeff Bates, Vice President of Editorial Operations for the Open Source Technology Group (OSTG). Jeff Bates's experience in developing and managing and Slashdot communities sheds light on maintaining participants' interest as well as the technology, which is useful in aiding development efforts. Parts Three and Four feature two people within CollabNet's employ, Karl Fogel, a founding developer of the Subversion project, and Louis Surez-Potts, community development manager of the project.

comments powered by Disqus