Making institutional free software successful
Many large institutions, especially government agencies, would like to distribute their software—including the software of the vendors with whom they contract—as free software. They have a variety of reasons, ranging from the hope that opening the code will boost its use, all the way to a mature understanding of the importance of community, transparency, and freedom. There are special steps institutions can take to help ensure success, some stemming from best practices performed by many free-software projects and others specific to large organizations. At the 2018 LibrePlanet conference, Cecilia Donnelly laid out nine principles for the successful creation and maintenance of a software project under these circumstances.
In her presentation (available as a video), Donnelly focused on a single project: GeoNode. She conducted research on the project as a consultant, co-authoring a report [PDF] with her colleague Karl Fogel of Open Tech Strategies, LLC.
GeoNode makes it convenient to record locations, share geo-locale information, and to display it on maps. The base maps can be obtained from a commercial provider (such as Google or Bing) or from an open-source provider (OpenStreetMap). The project was started by the Global Facility for Disaster Reduction and Recovery (GFDRR) to speed up disaster response. The GFDRR Innovation Lab also funded Donnelly's and Fogel's report. Chapter 3 of the report explains just how frustrating data sharing and coordinated responses were before GeoNode. Proprietary tools were failing; a grassroots and collaborative project was urgently needed.
The GFDRR, in turn, is funded by the World Bank. One could scarcely find a more well-recognized and well-established institution. It was successful in nimbly and transparently turning GeoNode into a thriving community project, not only used over the past seven years by many non-profit organizations, but supported and developed in a highly distributed way. Donnelly said that the public backing of such a respected and wealthy organization helped attract other collaborators. The body responsible for coordinating all this work is now called the Open Data for Resilience Initiative (OpenDRI). The license for GeoNode is the GPLv3.
It is perhaps strategically necessary that the World Bank
focused on return on
investment (ROI) when announcing the report; other commenters
followed suit. Finance is easier to cite than
freedom to justify an
organizational strategy. The official estimate that the World Bank got a
200% ROI is probably an underestimate. As the report says: "The
cost of licensing and configuring a commercial 'off-the-shelf' proprietary
solution would have been even greater, as the total cost would grow
directly with the number of installations, while offering less long-term
flexibility to meet the evolving needs of GFDRR and its partners.
" Free
software is truly a financial boon to those who use it,
based on this research. And we will never be able to count the benefits
that victims of disasters around the world obtained from faster and better
coordinated responses.
Instead of giving you a one-by-one summary of the nine principles in the talk (which you could get by reading the report or viewing Donnelly's video), I will quote a few principles and delve into what they imply about free-software projects conducted by institutions. Some of the following discussion comes from additional material I obtained from Donnelly through an email exchange after the presentation.
If a project is run along the traditional lines, the source code is left
with all sorts of hidden
idiosyncrasies and gotchas, which constitute a maze of twisty passages that
only the
original developers can maintain. Worse still, passwords and other secrets
may be embedded in the source code—even embarrassing and nasty comments
that no one would want exposed to public view. Hence Donnelly's first
principle: "Run as an open source project from the very
beginning.
"
If the code is developed from the start in the open, outsiders can point to maintenance hazards and programmers will police themselves better. If the principle is not followed, Donnelly said, organizations become afraid of opening the code at all. If they do, they need to go through a review process to scrub any security problems, private comments, and license-compliance problems before opening the code. Such tasks are much less costly if the code is open from day one because they are integrated into ongoing development work.
"Engage other organizations commercially.
" A similar goal propels
this principle. The GFDRR brought in multiple development teams from
different vendors, all reporting to the GFDRR. This required explicit
cross-team communications and encouraged good documentation, which in turn
enabled outsiders to join the free-software project. GFDRR luckily found one
contractor, OpenGeo, that was familiar with free-software development and
enforced good principles. Bringing in multiple vendors is also beneficial
because the resulting knowledge of the code is spread across all of them,
allowing for more competition in later phases of development.
Focus on communications and evangelism early." This principle builds on the previous one. When development is distributed, communication channels must be clear. Evangelism—in other words, communications with the outside world—must also start early to draw in potential collaborators.
"Invest in collaboration infrastructure
". This principle ensures
that the communication can take place. Donnelly's example of
collaboration infrastructure was simply a public mailing list. Most
free-software projects have learned that any serious project discussion
must be
done on the open list, and any important decisions reached through private
conversations on IRC or elsewhere should be documented on
the list or an issue tracker. Donnelly confirmed with me after the
talk that a distributed version control repository for the code would also be
important.
"Hold events and sponsor attendance.
" In-person events were
valuable for a wide range of contributors. The events help
new contributors get both enthusiastic and effective; this process is commonly
called "onboarding". They also help form important personal bonds among
more experienced contributors. In short, they build trust. Such experiences
drive this principle, she said.
At one in-person summit, personal interactions allowed stakeholders to make a crucial commitment to long-term funding for the project's stability. Donnelly suggested paying for key potential contributors to come to these events. In the case of GeoNode, the report estimates that 5% of the World Bank's one-million dollar investment went to in-person events, along with another 11% in outreach and training (Chapter 4 of the report, page 21). Investments were also made to produce documentation.
"Improve user experience to attract new users.
" The GFDRR consciously
invested in promotion and user recruitment, which illustrates this
principle. Existing users always want new features and will take up all the
developer time on these if they are allowed to do so. Donnelly says it's
crucial to put some effort into making the tools easier and more inviting,
thus increasing the user base.
Donnelly pointed out that researchers rarely get access to such a rich and detailed resource as she did at the World Bank for determining the results of a large organization's investment in free software. As the report shows, there were still areas of uncertainty where the researchers had to extrapolate the best they could from available data. But their insights should help many more institutions make the leap to free software—and to do it in a productive way. Donnelly ended her presentation by urging attendees to return to their companies and encourage them to start free-software projects, using the principles from the talk as guides.
| Index entries for this article | |
|---|---|
| GuestArticles | Oram, Andy |
| Conference | LibrePlanet/2018 |