An Open-Source Workflow for Spatiotemporal Studies with COVID-19 as an Example

“We do not appreciate being experimented on”: Developer and researcher views on the ethics of experiments on open-source projects

Extensible Business Reporting Language (XBRL) is being adopted by European regulators as a data standard for the exchange of business information. This paper examines the approach of XBRL International (XII) to the meta-data standard's development and diffusion. We theorise the development of XBRL using concepts drawn from a model of successful open source projects. Comparison of the open source model to XBRL enables us to identify a number of interesting similarities and differences. In common with open source projects, the benefits and progress of XBRL have been overstated and ‘hyped’ by enthusiastic participants. While XBRL is an open data standard in terms of access to the equivalent of its ‘source code’ we find that the governance structure of the XBRL consortium is significantly different to a model open source approach. The barrier to participation that is created by requiring paid membership and a focus on transacting business at physical conferences and meetings is identified as particularly critical. Decisions about the technical structure of XBRL, the regulator-led pattern of adoption and the organisation of XII are discussed. Finally areas for future research are identified.

Background: The popularity of the open source software development in the last decade, has brought about an increased interest from the industry on how to use open source components, participate in the open source community, build business models around this type of software development, and learn more about open source development methodologies. Aim: The aim of this study is to review research carried out on usage of open source components and development methodologies by the industry, as well as companies’ participation in the open source community. Method: Systematic review through searches in library databases and manual identification of articles from the open source conference. Results: 19 articles were identified. Conclusions: The articles could be divided into four categories: open source as part of component based software engineering, business models with open source in commercial organization, company participation in open source development communities, and usage of open source processes within a company.

Open Source developers play fundamental determinant role in the life of any open source project. This paper investigates developer motivation in contributing tirelessly to an open source project. Open source Onions were investigated and the developer layer modeled and validated based on ten case studies from SourceForge. Validation was based on Delphi's four rounds of successive stages. Results show that 62% of the developers around an open source development project community are skilled programmers, and that Open source developers are largely motivated by web based development platforms with universal programming language such as Java and that Developers are mostly attracted to the GPL licensed software development project with high project publicity as could be tracked from the hit rate on the project website. Finally, the few Core developers (Project Administrators) of about 19% actually controls and oversees the affairs carried out by about 81% of many developers showing the prominence of Pareto80/20 Principle in Open Source Project development.

Deep learning advanced to one of the most important technologies in almost all medical fields. Especially in areas, related to medical imaging it plays a big role. However, in interventional radiotherapy (brachytherapy) deep learning is still in an early phase. In this review, first, we investigated and scrutinised the role of deep learning in all processes of interventional radiotherapy and directly related fields. Additionally, we summarised the most recent developments. For better understanding, we provide explanations of key terms and approaches to solving common deep learning problems. To reproduce results of deep learning algorithms both source code and training data must be available. Therefore, a second focus of this work is on the analysis of the availability of open source, open data and open models. In our analysis, we were able to show that deep learning plays already a major role in some areas of interventional radiotherapy, but is still hardly present in others. Nevertheless, its impact is increasing with the years, partly self-propelled but also influenced by closely related fields. Open source, data and models are growing in number but are still scarce and unevenly distributed among different research groups. The reluctance in publishing code, data and models limits reproducibility and restricts evaluation to mono-institutional datasets. The conclusion of our analysis is that deep learning can positively change the workflow of interventional radiotherapy but there is still room for improvements when it comes to reproducible results and standardised evaluation methods.

BackgroundInnovation through an open source model has proven to be successful for software development. This success has led many to speculate if open source can be applied to other industries with similar success. We attempt to provide an understanding of open source software development characteristics for researchers, business leaders and government officials who may be interested in utilizing open source innovation in other contexts and with an emphasis on drug discovery.MethodsA systematic review was performed by searching relevant, multidisciplinary databases to extract empirical research regarding the common characteristics and barriers of initiating and maintaining an open source software development project.ResultsCommon characteristics to open source software development pertinent to open source drug discovery were extracted. The characteristics were then grouped into the areas of participant attraction, management of volunteers, control mechanisms, legal framework and physical constraints. Lastly, their applicability to drug discovery was examined.ConclusionsWe believe that the open source model is viable for drug discovery, although it is unlikely that it will exactly follow the form used in software development. Hybrids will likely develop that suit the unique characteristics of drug discovery. We suggest potential motivations for organizations to join an open source drug discovery project. We also examine specific differences between software and medicines, specifically how the need for laboratories and physical goods will impact the model as well as the effect of patents.

What are the similarities of open data and open source software when building a business? Despite their differences as phenomena (one is about applications and one is about data), the two also have many similarities. Both for example share the idea that the transparency of the artifact enables contribution. Many developers of open data have experience with open source development. But do the companies that build their offerings on open data and open source have similarities, and if so, what are the similarities? Drawing on fieldwork and interviews with software entrepreneurs and managers, this paper investigates these questions through an empirical focus on openness in business and clarifies the links between commercial organizations engaged with open source and open data. The article reports similarities on how the managers use the terms open data and open source to describe their business dynamic. These similarities are of importance to those who are interested in developing services that rely on open source or open data or who are interested in community management and legal and business issues or policy.

Summary form only given. In spite of the hype and hysteria surrounding open source software development, there is very little that can be said of open source in general. Open source projects range in scope from the miniscule, such as the thousands of non-maintained code dumps left behind at the end of class projects, dissertations, and failed commercial ventures, to the truly international, with thousands of developers collaborating, directly or indirectly, on a common platform. One characteristic that is shared by the largest and most successful open source projects, however, is a software architecture designed to promote anarchic collaboration through extensions while at the same time preserving centralized control over the interfaces. This paper features a survey of the state-of-the-practice in open source development in regards to software architecture, with particular emphasis on the modular extensibility interfaces within several of the most successful projects, including Apache httpd, Eclipse, Mozilla Firefox, Linux kernel, and the World Wide Web (which few people recognize as an open source project in itself). These projects fall under the general category of collaborative open source software development, which emphasizes community aspects of software engineering in order to compensate for the often-volunteer nature of core developers and take advantage of the scalability obtainable through Internet-based virtual organizations.

Abstract: In terms of software, continuous of the software is the best quality assurance. Continuous development requires either the original developer to continue development, or the next generation of developers to take over the development. It has been noted that when the original developer has used a development paradigm in which the source code is kept open to all, highly motivated and competent developers will participate in development. This makes it easier for a project to survive. However, at the same time, when the source code is opened to a broad audience a in the source code tends to occur. When this happens, those with a high level of competence and motivation abandon the development and go their separate ways. In such a situation, it is difficult for a project to survive. In the case of Denshin 8 go, a guardian for the source code was appointed, and the original developer and the guardians avoided this dilemma. Richard Stallman of the GNU project and Linus Torvalds of Linux project act as legitimate guardians to avoid fork.Keywords: software development, open source, fork, buried source code, legitimate guardian, Denshin 8 goIntroductionFor software, continuous of the software is the best quality assurance (Ikuine 8s Fujita, 2013). Continuous development requires either the original developer to continue development or others to take over (Fujita 8s Ikuine, 2013b). When other developers take over, the original developer must share the source code with others. Open Source is a paradigm wherein the source code is shared and made broadly available to others. It has been noted that the project adopting open source can attract competent and highly motivated developers. Thus, some claim that developers can readily ensure the survival of software development projects when the source code is open.However, opening the source code to a broad audience can cause heterogeneity in the source code, even when people continue the development based on the original source code, a phenomenon known as fork (forking). In the case of open source software (hereinafter, OSS), literally anyone can obtain the source code and modify it to develop new software and start up new projects. Therefore, forks often occur in the OSS project, and the impact of forking has been studied for very long (Dibona, Ockman, 8s Stone, 1999; Kogut 8s Metiu, 2001; Nyman 8s Lindman, 2013; Nyman, Mikkonen, Lindman, 8s Fougere, 2012; Raymond, 1997, 1999). Moreover, some studies have focused on how to maintain forked projects, under the assumption that forking will inevitably occur (Gamalielesson 8s Lundell, 2013; Ray 8s Kim, 2012; Ray, Wiley, Kim, 2012).When forking does occur, competent and motivated developers start to abandon the project and go their separate ways, which may affect the survival of these projects. In other words, sharing the source code comes with a dilemma. If one loosens restrictions and shares the source code broadly, that project may survive; however, if the project is forked, competent successors with strong skills and desires will end up working on their own, or perhaps inter-project competition may lead to vying for competent successors. On the other hand, while establishing strict conditions and sharing the source code only with a select few may make the source code easy to control and reduce the possibility of forking, it may become more difficult to find competent successors willing to participate under those conditions. This puts the survival of the project at risk. Ensuring the survival of a project requires that one avoid this dilemma of source code sharing.Research on avoiding the has heretofore focused on developer motivation, licenses, and project governance (Ernst, Easterbrook, 8s Mylopoulos, 2010; Neville-Neil, 2011; Nyman 8s Mikkonen, 2011; Robles 8s Gonzalez-Barahona, 2012; Viseur, 2012). However, forking is a phenomenon not limited to OSS, and examples can be seen in Unix as well (Takahashi 8s Takamatsu, 2002, 2013). …

The drilling industry has substantially improved performance based on knowledge from physics-based, statistical, and empirical models of components and systems. However, most models and source code have been recreated multiple times, which requires significant effort and energy with little additional benefit or step-wise improvements. The authors propose that it is time to form a coalition of industry and academic leaders to support an open source effort for drilling, to encourage the reuse of continuously improving models and coding efforts. The vision for this guiding coalition is to 1) set up a repository for source code, data, benchmarks, and documentation, 2) encourage good coding practices, 3) review and comment on the models and data submitted, 4) test, use and improve the code, 5) propose and collect anonymized real data, 6) attract talent and support to the effort, and 7) mentor those getting started. Those interested to add their time and talent to the cause may publish their results through peer-reviewed literature. Several online meetings are planned to create this coalition, establish a charter, and layout the guiding principles. Multiple support avenues are proposed to sustain the effort such as: annual user group meetings, create a SPE Technical Section, and initiating a Joint Industry Program (JIP). The Open Porous Media Initiative is just one example of how this could be organized and maintained. As a starting point, this paper reviews existing published drilling models and highlights the similarities and differences for commonly used drillstring hydraulics, dynamics, directional, and bit-rock interaction models. The key requirements for re-usability of the models and code are: 1) The model itself must be available as open source, well documented with the objective and expected outcomes, include commented code, and shared in a publicly available repository which can be updated, 2) A user's guide must include how to run the core software, how to extend software capabilities, i.e., plug in new features or elements, 3) Include a "theory" manual to explain the fundamental principles, the base equations, any assumptions, and the known limitations, 4) Data examples and formatting requirements to cover a diversity of drilling operations, and 5) Test cases to benchmark the performance and output of different proposed models. In May 2018 at "The 4th International Colloquium on Non-linear dynamics and control of deep drilling systems," the keynote question was, "Is it time to start using open source models?" The answer is "yes". Modeling the drilling process is done to help drill a round, ledge free hole, without patterns, with minimum vibration, minimum unplanned dog legs, that reaches all geological targets, in one run per section, and in the least time possible. An open source repository for drilling will speed up the rate of learning and automation efforts to achieve this goal throughout the entire well execution workflow, including planning, BHA design, real-time operations, and post well analysis.

This study presents sector-coupled PyPSA-Earth: a novel global open-source energy system optimization model that incorporates major demand sectors and energy carriers in high spatial and temporal resolution, to enable energy transition studies worldwide. The model includes a workflow that automatically downloads and processes the necessary demand, supply and transmission data to co-optimize investment and operation of energy systems of countries or regions of Earth. The workflow provides the user with tools to forecast future demand scenarios and allows for custom user-defined data in several aspects. Sector-coupled PyPSA-Earth introduces novelty by offering users a comprehensive methodology to generate readily available sector-coupled data and model of any region worldwide, starting from raw and open data sources. The model provides flexibility in terms of spatial and temporal detail, allowing the user to tailor it to their specific needs. The capabilities of the model are demonstrated through two showcases for Egypt and Brazil. The Egypt case quantifies the relevant role of PV, exceeding 35 GW, and electrolysis in Suez and Damietta regions, for meeting 16% of the EU hydrogen demand. Complementarily, the Brazil case confirms the model’s ability in handling hydrogen planning infrastructure, including repurposing of existing gas networks which results in 146 M€ lower costs than building new pipelines. The results prove the suitability of sector-coupled PyPSA-Earth to meet the needs of policymakers, developers, and scholars in advancing the energy transition. The authors invite the interested individuals and institutions to collaborate in the future developments of the model within PyPSA meets Earth initiative. • Open-source sector-coupled energy model with global coverage and high resolution. • Readily available workflow for supply, demand and transmission data worldwide. • Future demand scenario forecast tool with the option of custom data integration. • Global sub-national demand database with assets geo-locations, based on open data. • Showcases for hydrogen export and infrastructure expansion in Egypt and Brazil.

The plan to develop Evergreen, the open-source consortial library software, was announced in June 2004 by Lamar Veatch, state librarian and head of the Georgia Public Library Service (GPLS). Evergreen went live in 2006. That two-year period was filled with activity. It was a major decision by GPLS to develop new software of a scope never before attempted, but it was undertaken only after it had exhausted all other alternatives to run PINES, the resource-sharing public library consortium in Georgia. Evergreen was to be designed from the ground up as a new thing: a consortial library system, that is, an integrated library system for a large, geographically dispersed, resource-sharing consortium. Why did GPLS take this path and how did it go about doing it? The decision came about after a long chain of events made over many years in Georgia as it, like all states, wrestled with how best to provide public library services to its citizens. Policy decisions over many years followed a consistent direction. Local library organizational patterns commonly follow a model of treating each library separately resulting in what today are commonly called information silos, resulting in largely separate collections with weak communications among them. Resource sharing among the libraries in most state systems is through an interlibrary loan (ILL) process. Georgia, on the other hand, has consistently chosen another direction: joining the many small public libraries into larger resource-sharing regional libraries. Other states have worked on the idea, abandoned it, taken it up again and so on. It was an idea that the library community liked in theory, but before recent developments in computer technology, Georgia's path was unusual. The fundamental problem that all states must wrestle with in providing public library service - indeed for all entities providing any library service - is the great disparity of size, wealth and resources of the many libraries that exist. There are a few very rich libraries; however, most have only modest resources. Consider these figures from the latest national-level data we have for U.S. public libraries (FY 2005). Table 1 shows that the top quartile of these libraries by their total expenditures - that is, the 25% of public libraries that spent the most - spent $7.9 billion that year while the bottom three quartiles (the 75% that spent the least) spent $1 billion in total. Indeed, to press the point, the top 10% spent $6.5 billion. Think about that: Ten percent of the public libraries in the United States spent about 6.5 times as much money as the smallest 75% of the libraries. The big libraries are very big, and the small libraries are very small, and the disparities in expenditures that these figures demonstrate are consistent across other variables such as collections, resources and staff. Moreover, they are consistent with the pattern for other types of libraries. However, our story is centered on public libraries in the United States because of decisions made by GPLS. It is useful to note that the two largest open source library systems running in the United States, Evergreen and Koha, were developed for small public library settings. If you look at the expenditure figures above, it is not hard to imagine why - the large proprietary vendors prefer to concentrate their efforts where the money is. Within the open source framework, however, Evergreen and Koha have different approaches, with Evergreen being consortial for reasons that are discussed here. The disparities in resources outlined by the data present a profound information policy question for a consensual democracy: In a system of government that relies on an informed citizenry, are such disparities acceptable? Is it acceptable for the “haves” to have access to so much more information than the “have nots”? If not, how do we ameliorate the results of this disparity? Public library service as it is configured in the United States today developed before Google and other modern software developments that have relentlessly broken down information silos in other fields. Their configuration cannot adequately provide the vast pools of information and materials that are now available to the citizenry. One step in the right direction is consortial resource sharing, and another is to use these consortia to pool money to buy access to enhanced content for all the libraries in the consortium - especially those that could not otherwise have afforded this content - the “everything everywhere” library consortium. In its history (at least by the 1940s), Georgia decided to follow its subsequently consistent policy - with the normal stops and starts involved with politics - to bind the small public libraries in the state into larger, regional entities for resource sharing. That strategy was Georgia's way to get library resources to the “have nots.” The state provided both funding and direction toward that end. Although Georgia's largest libraries are typically independent, the smaller ones today are mostly in regional systems. In 1998, David Singleton, then at GPLS and now at Charlotte-Mecklenburg Public Library in Charlotte, North Carolina, suggested a universal borrower card for Georgia's public library users. Such a card would allow all citizens of Georgia to borrow an item from any library. Given both the amount of state funding and state strategic practices to group libraries into regions, such an idea was possible. Of course, the idea was not new to Georgia, but it fell on receptive Georgia soil since the infrastructure and the general acceptance of the idea of sharing resources were in place. Because of years of preparation, state guidance and vision, the idea would work. Y2K - the computer problem that existed because of the way computers handled dates - in the end was what led to the creation of PINES (the Georgia public library resource sharing network - the network of Georgia's regional library systems). Y2K money was allocated by the state, and an RFP for a statewide system was issued. One vendor's product stood out, and PINES was born in 1999 with Phase 1 linking 26 library systems with 90 outlets (central libraries, branches and bookmobiles). PINES was an immediate success. PINES users liked being able to borrow books from a larger set of libraries with a richer set of collections than one local library. They liked access to the longer tail, and PINES added more libraries and more users. Library users altered their behavior, and many bypassed their local libraries to have access to the larger, virtual collection. PINES grew until it started having problems with the underlying software that, famously, resulted in the system's production servers having to be rebooted during the middle of the day in order to be able to handle control of the transactions load. The software had reached a previously unknown limit. Given that the software that ran PINES is running other systems that have higher circulations and larger bibliographic databases than PINES, what limit had been reached? There were several, but the central one was the system could not keep up with the update load. The software was not designed for a consortium spread over a large area with updates such as checkouts, check-ins and cataloging changes to the central database coming from so many different places. In such a system, there are many people logged into the system changing the database at any one time, and the database, to be useful, has to be current. It should reflect what is checked in or out (transactions) and what the system owns (inventory) so that users searching will know if an item is available and librarians will know the state of items in the system. These functions are basic to a modern inventory control system. In PINES, there are thousands of terminals across the state logged into the database making changes, and each change has to be reflected in the database by “reindexing” it. While rebooting in this old system allowed the system to catch up with the changes, it could not be done frequently enough. The limit reached was a hard one, and there was no solution using that software. Meanwhile, more libraries wanted to join PINES. All the while, the circulation load was large and increasing. Any large piece of software has a design architecture: how it organizes its elements, what tools it uses, that is, how it does what it does. The design architecture, in turn, is a function of various factors, the two most important being system architecture and computer costs. Many old versions of old software still litter the ILS ecosystem. The software then running PINES began development in the era when mainframes ruled the earth. This legacy software has been adapted and changed and added to over the years. Elements had been bolted on and kludged, but, it is a fact that updating deployed software has proven to be an almost impossible task almost every time it has been tried. There are a thousand problems, and what most vendors of library software have done is start over using the more modern updated practices of the time. When the original PINES software was developed, computers were immensely expensive and software comparatively primitive. Better practices and more capable small computers existed when Evergreen was envisioned, and the developers used more modern software development processes to run on more capable computers that no longer cost a million dollars each to buy. An examination of alternatives in the market found none that had the capabilities necessary to run PINES then or in the future. What was Georgia to do? Limit PINES? Give up and abandon a policy direction it had followed so consistently and that had produced such benefits? Over software? After much discussion, GPLS embarked on a revolutionary path - an open source, consortial library system to run PINES. Work began on Evergreen mid-2004. The later a software system is developed, the more modern practices can be used in that development. Evergreen, for instance, was web-aware and used Unicode for text storage and representation from the beginning. To implement these capabilities, Evergreen did not require the costly and difficult rewrites to the foundational code necessary for ILSs that had their basic code written before Unicode had been developed. Unicode is important because it allows a system to handle non-Roman scripts, including characters in Chinese and Arabic. Evergreen's development began with practices then in place in the business world. These practices today result in software that is modular, scalable and relatively easy to update - at least compared to legacy software that is even as little as five years old. Evergreen uses a service-oriented architecture (SOA) with representational state transfer (REST) and “n-tier” architectural design concepts. Let us explore these concepts a bit. The development philosophy behind these elements is that software is based on distributed services that communicate and collaborate through a set of standards, that is, it should be “service oriented.” In Evergreen, the open scalable request framework (OpenSRF, pronounced “open surf”) is such an SOA framework. OpenSRF is, in many ways, the key to Evergreen because it does so many things. OpenSRF provides load balancing and is robust and scalable. It also allows the development of software without requiring a detailed knowledge of Evergreen's structure. In effect, the Evergreen layer consists of a number of applications each of which rides on top of OpenSRF. The result is that the developer need only know the APIs and what information the program elements require and what they will reply to write new capabilities into Evergreen. OpenSRF handles the details of implementing a stateful, decentralized service architecture while the Evergreen code supplies the interface and business logic. OpenSRF is now a separate open source project. Networking follows a design philosophy that is often introduced to students with the OSI Reference Model. The model describes seven layers that pass information among each other to provide network services in a manner similar to what one finds with SOA. “N-tier” application architecture is a related idea where the tiers communicate and collaborate with each other by established standards. We see these operations in our daily lives. If, for example, a new version of Firefox comes out, we can change the old version for the new one without changing the operating system or reformatting our hard drives. We usually do not even have to reboot. Why? Because of the underlying architecture where each program communicates with the other parts of the network software by established rules - application programming interfaces (APIs) - that specify how the various elements involved exchange needed information. So, to change a part or one tier does not require a massive rewrite of the entire code, just what needs to be adjusted. As mentioned, the Evergreen middle layer rides on top of OpenSRF, and the user interfaces (the OPAC and staff client) ride on top of Evergreen. In short, REST is a set of principles that establishes an architectural style for large, scalable applications. Evergreen also uses other open source projects - there are no proprietary pieces in Evergreen - to supply needed functionality. One advantage of open source applications is that a developer working on one project can use what is already tested and proven by other projects. PostgreSQL (“Postgres”) is an enterprise-grade relational database system with over 15 years of development. It was chosen for Evergreen because it was virtually the only open source database system that had the capabilities to support a system with the database structure and the transactions load the size of PINES. Another key application is XUL (pronounced “zool”) which stands for XML user interface language. Developed by the Mozilla project, XUL allows fully featured cross-platform web applications. Perhaps the best known XUL-driven application is the Firefox web browser. There are, as you see, a number of pieces to the Evergreen puzzle. These modules work together, and each can be changed when necessary without affecting the others as long as the changes do not affect the communications among them. Using these practices, coupled with the open source framework, provided a flexible method for very rapid development of Evergreen in the early days and continues to this day. Focus groups were formed to ask library staff and patrons what features they would like to see and how they would like the OPAC to perform. How well they did that job is indicated by the increased usage that followed the introduction of Evergreen. For instance, year-over-year, holds increased by 30% - same libraries, same network, but a new interface that users found easier to use, and they did. The general process for development was “release early, release often,” a process followed to this day. Small, iterative changes were made and released for comment and testing - not rare mega updates. If there were a problem, the software could be fixed relatively quickly. In addition, the software was open source so that it was developed in the open, not secretly by a small group. Many eyes looking at software makes better code. Another aspect of Evergreen's development is “scratching an itch.” That is, development tends to focus on the problems that people want fixed, not necessarily theoretical problems or capabilities dreamt up by product managers in response to real or imagined competitive pressures. Any kind of software development will have its strengths and weaknesses. Scratching an itch will solve problems people really have, but the community does need a mechanism to guide development strategically to make sure that while solving this or that problem the software stays a coherent whole. As a result of what was learned about the first iteration of PINES, there were several key results expected from Evergreen. The original charge was to build something “scalable, robust and fault-tolerant.” And, of course, open source. What do those three new terms mean? Scalable means that the software can be deployed in different-sized libraries and that adding capacity is relatively easy. At the point where the decision was being made to move from the proprietary system that ran PINES, the server upgrade for the old system would have cost $1.5 million for a large server. Evergreen development cost the GPLS much less than that. Learning that lesson, Evergreen can be upgraded by adding “commodity” servers - that is, servers from any manufacturer or any do-it-yourself builder, and they can be added as needed. OpenSRF, clearly, allows Evergreen to scale easily. Because Evergreen is easy to use - remember the focus groups - as a library's users learn the software, they use it more, and growth can be done by adding relatively cheap, redundant servers, not million dollar boxes running proprietary software. Add a server or two, load OpenSRF, and you have upgraded. Evergreen runs on laptops, is currently running on a home library, and runs PINES with 16 million circulation transactions. Robust. Evergreen was designed to be able to keep functioning in dire circumstances. When a backhoe severed the PINES network, the Evergreen staff clients allowed libraries that were disconnected from the central databases to continue checking out books. When the network was restored, the database was updated by an established procedure. There was no need to write down transactions on paper. Consider: PINES has had a number of days recently with 100,000 circulations. If half the network were down for a half a day, that could be 25,000 sheets of paper to be managed. Not with Evergreen. Fault-tolerant. Servers can fail, and the system will keep on functioning. The use of redundant servers allows one to fail and the others to keep on functioning. Evergreen was designed as much as possible to never go down. Reflecting its history, Evergreen does not have acquisitions nor serials modules. Work on these two services is ongoing with releases expected by Spring 2009. It is a development project, but one coming from the library world to solve library problems. As was observed above, it has been quite difficult in the past to update software to reflect new demands on it. It did prove relatively easy to add web awareness to most existing library software but rather more difficult to add Web 2.0 capabilities and Unicode. Consortial capabilities have proved daunting. And as a result of Evergreen such capabilities are now touted by software in the market that may soon have those capabilities, too. How does Evergreen avoid these kinds of pitfalls of obsolescence? Maybe it doesn't but Evergreen's practices reflect the current best guess about how to engineer software so updating it is never as painful as it has been in the past with code bases even a few years old. Welcome to the future, version 1.

The open source model is a form of software development in which the source code is made available, free of charge, to all interested parties; further users have the right to modify and extend the program. Open source software (OSS) methods rely on developers who reveal the source code under an open source licence. Under certain types of open source licence, any further development using the source code must also be publicly disclosed. In this brief survey, we will focus on several key aspects of open source software.

The goal of the study on Fun and Software Development (FASD) is to precisely assess the importance that fun has as motivation for software developers to engage in open source projects. A survey carried out both under open source developers and programmers working in Swiss software companies yielded that the fun motive accounts for about 27 percent to 33 percent of open source developers’ motivation. Fun is a pervasive feature of software development, not only for open source programmers but in the area of commercial software development too: Open source developers that are paid for their work are observed to be very motivated and prepared for future effort, especially if they enjoy their development time. Furthermore, the fun that programmers experience functions as a good proxy for their productivity. Therefore, employers that want to enhance the programmers’ productivity can safely invest in an environment of fun for developers in their company.

Community-based development through collaboration amongst software developers and researchers distributed globally has led to a wealth of feature-rich applications of Free and Open Source Software for Geoinformatics (FOSS4G). In the FOSS4G, development model online source code repository, mailing lists, and a Wiki provide the software developers and users with a virtual and ubiquitous platform for the implementation of new methods, algorithms, and tools as well as for refinement and enhancements of the existing code. For end users, this development model provides highly interoperable, sophisticated software at no cost. This approach is both flexible and immune to vendor lock-ins. Further, the reproducibility of results and quality assessment of methods is greatly facilitated since full access to the underlying algorithms is guaranteed. The source code is typically published under free and open source software licenses with end-user rights to run the program for any purpose, to study how the program works, to adapt it, and to redistribute copies including modifications. The FOSS4G offers software libraries for map projection and data format conversion, desktop Geographic Information Systems (GIS), Web mapping/Web–GIS, spatial databases, geostatistics, and metadata catalogues. Most FOSS4G software packages run natively on common operating systems and may be installed and used without restriction in any commercial or non-commercial environment at no cost for the end users. Open Source Geospatial Foundation (OSGeo, http:// www.osgeo.org) serves as an umbrella organization whose mission is to support the collaborative development of FOSS4G and promote their widespread use. OSGeo provides a common forum and shared infrastructure for improving cross-project collaboration. Acceptance of a project to OSGeo depends on a successful incubation process which includes a detailed source code audit to identify any license incompatibilities in the code. This incubation process also confirms that the project is supported by a healthy community, including validation of the rules and processes governing the project's management. Since its inception in 2006, OSGeo has been providing organizational support for building a vibrant international community to advance geospatial technologies and solutions using open source software, open data and open standards. This special issue is brought forth with the aim of presenting the rich capabilities of FOSS4G to foster original research and enable deployment of innovative solutions. The issue covers a broad range of topics, highlighting the diversity of methods, tools, and applications of FOSS4G. The first two papers introduce new tools and applications for vegetation analysis, first as a M. A. Brovelli (*) Environmental, Hydraulic, Infrastructures and Surveying Engineering Department, Politecnico di Milano-Campus Como, Via Natta 12/14, 22100 Como, Italy e-mail: maria.brovelli@polimi.it