|
Items in cart [0] |
Questions? Call 888-624-8373 |
PAPERBACK Free Resources |
|||||||||||||||||
|
|||||||||||||||||
The following HTML text is provided to enhance online readability. Many aspects of typography translate only awkwardly to HTML. Please use the page image as the authoritative form to ensure accuracy. presentation closes with an example of our vision that we are trying to initiate: an open-source/open-content approach applied to land use/land cover change modeling. PRINCIPLES OF OPEN-SOURCE PROJECTSThe basic principles of open source are grounded upon an innovation in software licensing. While there are a variety of open-source license types, in general they require the free distribution of the software coupled with readable source code. These licenses often allow new derivative works to be developed from the digital content (program source code). If you are a programmer, you can interpret the programming logic and have the opportunity to contribute new functionality to that software, with one catch: many open-source licenses (e.g., the GNU General Public License) are of a “viral” nature, requiring improvements to follow the same licensing agreement. The licensing in open source is a critical component in how these projects work. The Linux operating system and the Apache Web server are two high-profile open-source success stories. They provide examples of how the open-source collaborative paradigm can produce solutions to very complex problems. The question is whether these are anomalies or whether there is really something to this collaborative approach that could be applied in other complex problem contexts. To explore this we should understand better how these projects work. Based upon a review of recent literature,2 a key attribute of Internet-based open-source collaboration projects is an established team of volunteer programmers and testers. In some cases (Linux being one prime example) there are organizations (e.g., IBM) that actually pay employees to work on the project. Modularity and parallel development are also important design principles for open-source projects. The idea is that by dividing the project into modules or small compartments, people around the world could select a particular module to improve, without interfering with anyone else who is working on the project. Improved modules can be resubmitted back to the project, subject to a peer review. If the improvement is deemed useful, it is added to a future release of the software. Typically open-source projects are initiated by an individual or a small group who have a critical need for software functionality that is currently unavailable or is too expensive to purchase. They then develop a “kernel,” a core piece of software with some promise for potential innovation and growth. For a high-quality project to emerge highly skilled or prominent people in this particular area are required in order to give it promise for later participatory growth. Internet-based collaborative infrastructure is also important for open-source projects to work. Here version control systems are crucial. These systems keep track of various changes to existing modules and allow the project administration to control and keep a record of different releases of the software. The Concurrent Versioning System is one of the most popular softwares of this type and is used in many open-source programming projects. Project governance—including rules related to participation and conflict resolution and norms of behavior—is another potentially important aspect of open-source collaboration. To date there is very little literature addressing this subject,3 but our hypothesis is that this is a very important factor that leads to the success or failure of these projects. For many projects the goal is ultimately to achieve growth both in developer participation and in a user base. From a developer perspective this is really the law of numbers, where with more eyes problems are more easily solved.4 The idea is to get a large participating group, hopefully globally, working on these problems. The high-profile success stories have achieved this; Linux and Apache enjoy a large community of developers with regional coordinators working in many languages. In the case of Linux there are approximately 18 different languages represented, and it is a potentially complex system of coordination and core staff.
|
|
||||||||||||||||
