Open source

XIV.6 November + December 2007
Page: 35
Digital Citation

Working with open source


Authors:
David Schlesinger

Open source software has become more popular and more widely used every year. It runs most back-office server applications (Google runs its search and index system entirely on open source), is used in projects like the “One Laptop Per Child” initiative, and is making major inroads with cell phones and other mobile devices. There are a lot of exciting things happening, and—unlike with proprietary software—you can be directly involved.

There’s much interest in the open source world for user-experience programmers and designers. Currently, full user-interaction stacks like GTK+ are powering everything from desktop systems to cell phones, and high-end graphics and effects work, such as the compiz-fusion project, are producing “eye candy” effects that rival or exceed what’s available on proprietary alternatives like OS X or Microsoft Vista.

Working with open source code and projects for the first time can be somewhat daunting, particularly if one has worked mainly on proprietary efforts. There are many differences both in outlook and method among open source projects, but the distinctions between the way things are done in the “open source community” and in commercial enterprises are much greater.

In addition, working with open source, or releasing your own work under an open source-style license, can also be intimidating. There are numerous choices as to license, and the advantages and disadvantages of one versus another are not always clear.

Open Source Projects vs. Proprietary Projects. When we work on proprietary efforts, we tend to work in pretty structured ways:

  • We work according to a schedule and plan according to deadlines.
  • We work to meet specific, preconceived requirements.
  • We work until we finish (or maybe until a project is canceled).
  • We work to meet specific quality goals.

We also tend to work in a hierarchical organization, with roles that are not self-selected, etc. The advantage of working in a proprietary context is that we can have complete control over our efforts, and (in theory, anyway) produce a predictable result in a planned timeframe. (Engineers know that “in theory, there’s no difference between theory and practice, but in practice, there is.”)

Open source projects differ in all these areas:

  • A typical open source project will have only a rough idea of a specific release schedule, if any at all.
  • For the most part, a typical open source project is driven not by specific, preplanned requirements; rather, it’s more common for people to implement features that they personally would like to have, and to fix bugs that they’re personally running into.
  • Participation in an open source project is almost always voluntary: People work on it as long as it holds their interest, or until they find something better to do.
  • Quality levels on open source projects can be a lot more negotiable than on proprietary efforts. If you complain that something is broken, a typical response might be, “Well, fix it!”

Open source is as much a social phenomenon as a technological one

 


Open source projects normally run as rough meritocracies. Providing working, well-written code tends to be the most highly valued activity, and a consistent record of providing such code will almost guarantee a degree of influence within a project. Other valued activities include participation in project-related mailing lists, IRC chats, providing documentation, etc. Indeed, the most complex projects tend to develop more structure over time, particularly as they become more critical to the operations of dependent components. The structure is not generally very planned, but develops organically, according to the kind of criteria just described.

Working With an Open Source Project. When beginning to work with an open source community, recognize that each one has its own set of practices, idiosyncrasies, and personalities. Get on the mailing list(s) associated with the project and read the archives; get to know the participants, particularly the “maintainers” (who will critique and approve suggested changes proposed for the project). Try to get a handle on the general goals and directions for the project as a whole.

Every community has its own set of practices, foibles, and “lore” around things like submissions, bug reports, documentation, and copyright assignment—many projects require this to allow easier administration of licensing terms. It’s really worth the time to familiarize yourself with these process elements, or your contributions may be viewed as requiring additional work on the part of others to integrate into the project.

Open source development turns out to be as much a social phenomenon as a technological one. Going to conferences, “hackfests,” or other forums where you can meet face-to-face with other people working on a project adds a lot of value and helps future online interactions immensely. There are a number of major open source conferences, many of which are more or less specialized, either in subject or geography or both. As you learn your way around a project, you’ll undoubtedly learn which get-togethers are most favored by that particular project.

An Open Source Licensing Primer. The Open Source Institute (www.opensource.org), which maintains the core definition of what is and isn’t a valid open source license, recognizes no fewer than 58 licenses, ranging from “academic” to “zlib.” They vary widely in the requirements they place on the use of the software they cover, and they range greatly in clarity. Only a few of these licenses are widely used, and many tend to be variants of those core licenses, so getting a grasp of these can help cover a lot of ground. The main licenses in use currently are:

  • The GNU General Public License (GPL): This is the original “free software” license, developed by Richard M. Stallman of the Free Software Foundation and Eben Moglen of the Software Freedom Law Center. The most widely used version of this license is v2; a v3 license was released in June 2007, but has yet to gain wide acceptance. The GPL is a reciprocal license and requires that derivative works—i.e., modifications of, or improvements to the code as it was received—be distributed under the GPL as well. The GPL takes a very broad view, however, of what constitutes a “derivative work,” and some experts argue that it exceeds the definition of “derivative” in copyright law (see L. Rosen, Open Source Licensing).
  • The GNU Lesser General Public License (LGPL): Similar to the GPL, the LGPL relaxes the requirement that when linking to code covered by the license, the code doing the linking also be distributed under the same license terms. This allows, for example, proprietary code to link to LGPL-licensed open source code without needing to publish the proprietary portion.
  • The Berkeley Standard Distribution (BSD) License: Unlike the GPL and LGPL, the BSD license is nonreciprocal. You can use, modify, improve, or otherwise utilize BSD-licensed code in any way you choose, and are under no obligation to republish those changes. The original “4 clause” BSD contained a requirement that the original creator of the code must be “advertised” in a statement in documentation or a dialog, but this became quite unwieldy. Currently, the “3 clause” BSD license, which removes the “advertising requirement,” is generally used.

Under most circumstances, if you get involved in working on an open source project, you’re not going to have any choice in the licensing terms of the project. Depending on your goals, however, you may want to consider whether the license used is compatible with them. If you, for instance, want to ensure that useful changes made to your own contributions are also made available, a project using a BSD or BSD-like license may not be a good choice.

An alternative to the licenses mentioned, which may be more suitable to works that are more design-oriented and less about actual code, can be found at the Creative Commons (www.creativecommons.org).

The Creative Commons provides easy-to-use tools that enable creators to specify the particular freedoms that they wish to allow users of their works, in a simple, checklist form. With these tools, you can specify whether reuses of the work must be attributed, whether derivative works can be created and whether those works must also be shared, and whether commercial use may be made of the work. To its credit, the Commercial Commons provides a range of expressions of the selected license, from a simple “badge” for Web pages and the like, to a basic explanation of the rights and requirements, to a full-blown legal license document. For many types of works, this is a more appropriate alternative than would be most of the common open source licenses, which are, for the most part, very oriented toward licensing actual code.

Don’t Let Any of This Scare You Off! Working in open source may be a change from what you are used to; the way work gets done differs. In spite of this and the complications of issues like licensing, working on an open source project can be incredibly rewarding, both in terms of what can get done—since, with any luck, you’re not doing all the heavy lifting—as well as working closely with a widely diverse, but like-minded, group of talented people.

Author

David Schlesinger
ACCESS
lefty@access-company.com

About the author

David “Lefty” Schlesinger is director of open source technologies at ACCESS Co., Ltd., working principally on open source strategy and community relations, and representing ACCESS in a number of industry and community initiatives. Lefty is responsible for open source licensing compliance practices within ACCESS, and is the author of ACCESS’ internal “open source best practices” curriculum, as well as acting as the administrator for ACCESS’ main open source release, the “Hiker Project” (www.hikerproject.org), a suite of application service components for the development of seamlessly interoperating mobile applications. Lefty’s paper on the Hiker Project was published in this year’s “Proceedings of the Ottawa Linux Symposium.”

©2007 ACM  1072-5220/07/1100  $5.00

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.

The Digital Library is published by the Association for Computing Machinery. Copyright © 2007 ACM, Inc.

 

Post Comment


No Comments Found