Open Source Development

The production and development of open source software (OSS) has received substantial attention recently, following the success of projects like Apache, Perl and Linux. But what are the real dynamics of this ‘new’ mode of production? The National Institute for Space Research surveyed the production landscape of GIS OSS looking for answers. Gilberto Câmara, director of Earth Observation, shares the findings and argues for a new conceptual paradigm

The predominant idea of the open source production model is of committed groups of individuals operating in distributed networks, with each programmer working on a small but meaningful module. These programmers are apparently isolated, communicating by means of a central repository and mailing lists. They have individual incentives to participate.1 Some writers have gone so far as to identify in open source software a new mode of organisational structure: ‘commons-based peer production’.2

At the National Institute for Space Research, we have conducted a detailed study of one segment of the software market: geoinformation technology (GI), which includes geographical information systems (GIS), location-based services, and remote sensing image processing. The survey selected 70 GIS open source projects, mainly using a listing provided by the Freegis.org site. Its findings call into question the idea of open source as it is commonly understood. While carrying out the survey, we considered the following questions: (a) How is OSS developed and produced? (b) Who is actually building Geographic Information OSS products? (c) How can developing countries use OSS to meet their national needs?

Three clear models can be distinguished in OSS development: the post-mature model; the standards-led model and the innovation-led model. The post-mature model is found in strongly consolidated markets, where a proprietary product has gained a large market share. As a product becomes popular, its functionality and conceptual model become so well established that it is difficult for another commercial product to capture market share, even if that product is sold at a lower price. In such cases, there is a strong incentive for newcomers to license their products as open source: for many potential users, the perceived benefits of open source outweigh the cost of switching from the commercial product. One very good example of this is the Open Office productivity suite,3 which provides a Free Software alternative to Microsoft Office. The standards-led model arises when the establishment of a common standard for a product allows others to compete in the marketplace by replicating the standard as open source. Newcomers benefit from the substantial intellectual effort that has already gone into establishing the standard. An example is the SQL database, which has motivated products such as mySQL. Another is the POSIX standard for operating system interfaces, which has reduced switching costs from other UNIX-based environments to Linux.

The innovation-led model occurs when universities, public institutions and corporations produce work that has no direct equivalent in the commercial sector. An example is the University of California’s Postgres database management system.4 After an unsuccessful commercialisation attempt, a private company took over the development of Postgres, added SQL support, named the resulting product PostgreSQL, making it available as open source.

Based on size, geographical distribution and affiliation, our survey has distinguished three categories of OSS development teams:• Individual-size projects: the project team consists of 1- 3 individuals, usually from the same location and working in their spare time. The software products are usually small, specialised applications addressing specific requirements.• Collaborative networks: the project core team consists of a team of 15-30 individuals, geographically dispersed. The developers usually have separate jobs, and do their work in their ‘spare’ time, sometimes allocated in agreement with their employer. • Corporation-based: the project’s core team, usually a set of 3-8 programmers, is part of a corporation. There can be outside collaborators, but the main design decisions are made within the corporation and in some cases also address the company’s commercial objectives. Examples include the PostGIS extension to the PostgreSQL DBMS, and the TerraVision systems for terrain visualisation on the internet.

These results contradict the naïve view of open source software as predominantly developed by committed teams working through peer-cooperation. In fact, only four (6%) of the projects we looked at are based on such a loose network of collaborators; more than half are led by individuals. Corporation-based projects account for 41% of all cases examined. Out of the 29 corporations involved in developing open source GIS, 17 are private companies, eight are government institutions, and only four are universities. Currently, in other words, the academic research community is not significantly concerning itself with direct involvement in long-term open source projects. Maintaining and supporting an open source software project requires considerable resources, beyond the reach of most university groups, added to which there is a conflict between the generation of new research ideas and the need for long-term software maintenance and upgrades. Often, for a research prototype to evolve into an opensource product, another team of developers must take over from the original research team and establish a support and maintenance infrastructure for the product.

The relatively small proportion of innovative projects (19%) in our survey shows that the design of most open source software products is based on the post-mature and standards-led production model, in which the main aim is not directly to innovate, but to lower licensing costs and break commercial monopolies. Perhaps most significantly, the maturity, support and functionality of OSS products differs massively across development scenarios. It seems that the corporate environment is much better suited to long-term software development than the individual-led one. Individuals are constrained by their commitments, and are very rarely able to include full-time support for the software they develop, whereas many corporations rely on earning indirect revenues (e.g., consultancy fees) from their open source products. But the difference between a corporation and a networked team is much smaller in terms of quality and support: a committed team of individuals are able to produce results which are comparable to, or better than, those produced by corporations.

The fact that the direct participation of universities in open source software is limited means that innovative non-commercial projects account for less than 20% of the total; a large proportion (53%) simply aim to provide standardised components for spatial data processing. Two innovative projects developed by a networked team of programmers are GRASS [http://grass.itc.it] and R [http://www.r-project.org/]. Both products have a simple and well-understood conceptual design, and their innovative contribution lies not in their design, but on the analytical functions that scientists develop using these environments.

Many developing nations are currently considering policies to support or enforce the adoption of OSS by public institutions. The arguments in favor of OSS adoption by public institutions include: • Lower cost: adoption of personal computers based on OSS for public use can reduce an initial entry cost by as much as 50%. Easier replication of solutions is also possible. Large-scale public projects can greatly benefit from having a prototype developed and tested, that can then be replicated across the country with no additional software costs.• Independence from proprietary technology: many governments are increasingly concerned with overdependence in some important markets on a small number of vendors.• Availability of efficient and low-cost software: the virtuous examples of some products (such as Linux and Apache) have encouraged statements about the widespread availability of OSS software for public use. • Ability to develop custom applications and to redistribute the improved products: given the ‘open’ nature of OSS, skilled local programmers could adapt the software to fit local needs, and thus increase the efficiency of the services provided by the improved products.5

Our study has significant consequences for developing nations considering OSS. The evidence we have gathered broadly supports the first two claims – but ‘software availability’ and ‘ease of customisation’ are far more problematic. The most successful open source software tools are infrastructural products, such as operating systems, programming languages and web servers. The huge demand in developing nations for enduser applications, especially in the public sector, seems unlikely to be satisfied by the small number of such applications being produced in OSS. Corporations still dominate the development of open source software, taking place around their own strategic interests, and they are unlikely to furnish the full range of end-user applications needed by developing countries. This suggests that if governments in developing nations aim to profit from the potential benefits of open source, they must intervene and dedicate a substantial amount of public funds to support the establishment and long-term maintenance of open source software projects. The benefits of this strategy could be substantial. In the case of urban cadastral systems, based on a spatial database for middle-sized cities, the typical base cost of a spatial database solution for one city is US$100,000. Should 10 cities adopt as OSS solution in a given year, there would be a saving of US$1 million per year on licensing fees; money that could be well used for financing local development and adaptation. Government strategies for supporting indigenous open source software development and adaptation would also result in a ‘learning-by-doing’ process. Such processes foster innovation in the developed world and would likely do the same for those nations supporting emerging economies.

By looking in detail at open source software development in the areas of geoinformation technology, we can see that the ‘Linux paradigm’ is exceptional. Corporations are the main developers of successful open source products built around their own strategic agenda, and peernetworked teams develop only 6% of the all open source GIS products. This result strongly mitigates claims that open source software development defines a significant new ‘mode of production’. In fact, the vast majority of substantial software design and development is still the product of qualified teams operating at a high level of interaction. Developing software in a decentralised manner requires a modular design that is difficult to achieve for most applications, since few software products can be broken into very small parts without a substantial increase in interaction costs. These results have important consequences for public policy guidance. Governments worldwide who try to benefit from the open source software model by establishing legislation mandating its use could be frustrated by the lack of mature, available public-sector applications. In order to create the software they need, governments will have to establish public-funded projects for open source development and adaptation to local needs. Software, whether open or closed source, is still constrained by the essential requirements of its development process: conceptual design, program granularity, cohesion of the programming team and dissemination strategy. Failure to understand the realities of the open source development model could result in a lost opportunity for the developing world: reducing the critical technological gap between rich and poor nations.

The Mute magazine print archive has its first release for sale as an original, limited edition set of all fifty-one issues of the print versions of the magazine, covering twenty years of publishing from 1994 to 2014. Full Details