Previous    Table of Contents    Up    Next

Understanding Open Source

Open source forms a commons where certain types of development take place in the open and the artifacts are available for general use. The primary problem software-related companies face at the beginning of the twenty-first century is how to innovate effectively. Innovation is relatively common and easy, but being able to choose which innovations will make the most business sense and then monetizing them is not easy. There is in general a trade-off between doing things in the commons, where innovation is easy because of the large number of diverse people and unfamiliar ideas, and doing things behind closed doors, where it is easy to keep a competitive advantage through secrecy and intellectual property laws. The first step is understanding innovation and creativity and how a commons can be a good venue for them.

Open source itself seems new and is mysterious in many ways. Why would anyone work for free? Where did these ideas come from? What sorts of software are created using an open-source methodology? Open source seems like it comes from a mob, but in reality it comes from a set of communities. These communities are tied together through culture, vocabulary, customs, practices, values, ethics, and morals. Being able to work with an open-source community requires understanding all these things well enough not to be made a fool of immediately and then learning how to work effectively within the chosen community. There is an arc of maturation as you enter an open-source community as a newcomer or foreigner and then progress to becoming an inhabitant, then perhaps to leader, and then on to respected elder. Open source works on principles common to gift economies, which are generally more fundamental, or primitive, than free-market economies (which tend to be overly rational in how they treat value and compensation). Perhaps it's best to call gift economies precapitalistic.

Nevertheless there are many business reasons to embrace open source, all the way from just using open-source software such as Linux or Apache to starting and running open-source projects. The reasons to engage with open source include the following:

• Getting high-quality, free software and software design and development help.
• Making your software ubiquitous through participation and low cost.
• Engaging end-users in design and testing.
• Reducing time to market.
• Doing marketing and marketing research.
• Working with partners who prefer a loose relationship.
• Positioning a company.
• Harvesting innovation.
• Making standards.
• Building a brand through ubiquity and positioning vis-à-vis the open-source community.
• Adopting transparent development processes.
• Changing customer and market perceptions.
• Making a vision pervasive.
• Changing the rules.
• Reducing support costs.
• Injecting discipline into the development process.
• Improving integration.
• Satisfying more customers.
• Porting to otherwise unimportant platforms.
• Avoiding lock-in.
• Changing pricing practices.
• Signing up partners and creating consortia.
• Creating markets.
• Making ethical, moral, and political statements.

All-volunteer open source is the purest form. Projects such as Linux and Apache, before they were noticed and embraced by companies, were examples of all-volunteer open source; most of the projects on SourceForge are also examples. When a company joins an open-source project and especially when a company starts an open-source project, it brings to the table experts and processes that are not usually part of open-source projects. These include usability experts, release management, quality assurance, specification writing, documentation writers, and project management. These other process appurtenances can be carried over to varying degrees, but inevitably they alter the all-volunteer nature of open source, and therefore a company needs to know about how open source works in order to bring these other roles and practices to the table effectively. This is the central topic of this book.

An important legal key to open source is licensing. There is a pervasive myth that open-source software is not owned by anyone and that a company doing open source must give up ownership and control of its property. Actually, open source recognizes ownership and generally the primacy of ownership and its concomitant rights. Software licenses can yield many levels of rights because there is a vast gap between having no rights and all rights. Licenses can give the right to distribute and make changes to source code, but also can limit what sorts of distributions and changes are allowed. The license establishes, to an extent, the legal basis for an open-source project and community. There are a variety of licenses ranging from granting the right to view source, to gated communities, to open source, to free software, to public domain.

Engaging in an open-source project requires understanding the community, its culture and customs, its tools, and its way of working. Open-source projects are distributed and work through email, websites, and other written documents. There are standard versioning tools, compilers, bug-tracking tools, and customs for using them. Building, testing, support, and releases are handled in particular ways. There is a sort of hierarchy to the developers centered on module owners and the concept of a meritocracy, where rights are expanded only after abilities have been demonstrated.

In general, a company starting an open-source project needs to expend energy and resources creating a sufficiently large and robust community that will contribute, regardless of the type of contribution expected. Some managers and executives, upon beginning to engage in open source, are surprised that it seems more like a social activity than a development exercise, but this is the reality. To work with an open-source project--especially to start one up--requires an understanding of the culture and customs of the open-source way.

Beyond figuring out the business reasons for doing open source, a company or project needs to look at a variety of issues to determine whether it makes sense to use an open-source approach. These include whether you and your management buy into the open-source lifestyle, whether the source code is suitable and ready for source licensing, whether you have the resources, and whether your resource expectations are reasonable. Then you have to get the source code ready, get the company ready, choose a license, create a development plan and roadmap, make a budget and get funding, educate your developers, and build a website. Beyond these, there are commonsense things to do to build the community and maintain credibility in the open-source community.

After you've started an open-source project, there is a lot of work to do to keep its momentum building: It's not a matter of throwing the source code over a wall and watching a crowd gather. You need to craft and evolve the vision for the project, keep resources applied to the community, actively bring in contributors and users, evolve the website, keep things active and looking active, grow and mature your community members, and communicate transparently.

There are things you need to do to succeed. You really need to understand and buy into the open-source lifestyle. You need to start a relevant and useful project, not one that duplicates an existing effort. You need to get your code in shape and choose a good license--both for the open-source community and for your company. If you don't seem to have a way to make money or other commercial gain, the open-source community may consider you not with-it enough to risk expending effort on your project. And there are things to avoid. The biggest mistakes you can make involve control. The one characteristic of companies that open-source developers despise is overcontrol. It is natural to want to control a project, but the level of control that makes sense for an open-source project may seem too lax for development managers and executives. In many ways, the development processes in open source seem inefficient because they are based on written communication, and it's easy to fall into taking shortcuts, for instance by making important decisions in local, face-to-face meetings. This can cause tensions inside and outside the project in your company.

Moreover, the community will not arise just by itself. There is nurturing to do. And it's easy to buy into this concept intellectually while still failing to understand or appreciate what it means for everyday work. Most open-source communities need to have an email (or push-based) culture in order to seem vigorous and viable. Pull-type websites need to have compelling content for people to visit every day, and an open-source project is unlikely to have that.

Nevertheless, many companies have embraced the use of open source. In 2002, a study by Berlecon Research (FLOSS--Free/Libre Open Source Software: Survey and Study) conducted for the European Commission found that eight of the world's 25 largest software companies, including IBM, HP/Compaq, SAP, Hitachi, and Sun Microsystems, had a major involvement with open source and that another three companies engaged in lesser open-source activity. This was based on public announcements by the companies of their involvement, and so the actual use of open source is undoubtedly higher.