Posted on
 

Report on GeoNode’s path to open source success

A map of flood zones in Haiti, rendered with GeoNode. Vulnerable areas are highlighted in red, over a base map showing a street map of Port-au-Prince. The mouse is hovering over a menu item which explains that "This map layer modelizes areas of frequent flooding for Port-au-Prince region."
Haiti Flood Zone map. Source: http://haitidata.org/maps/153/view.

Recently, OTS was asked to write a report about the GeoNode project by one of its primary sponsors, the Global Facility for Disaster Reduction and Recovery (GFDRR) a global partnership that is managed by the World Bank.  GeoNode is a facility for sharing and displaying geographical information.  It is “web-based, open source software that enables organizations to easily create catalogs of geospatial data, and that allows users to access, share, and visualize that data,” as we put it in our report.

GFDRR and its Open Data for Resilience Initiative (OpenDRI) work to increase community resilience to natural disasters, in particular by sharing data.  GeoNode helps them do this by providing a way to easily share geographical data – what parts of a city are the lowest and most prone to flooding?  Where exactly has an earthquake hit, and where is assistance needed most quickly?

Why write a report?

OpenDRI began the GeoNode project in 2009, and has been a major contributor to the code and community since then.  In 2016, they decided that they’d like to contribute in another way: GeoNode as a project has been tremendously successful, and they wanted to share lessons about how to incubate an open source project.  Large institutions sometimes sponsor open source projects, and do not always have success involving partners to the extent they would like.  OpenDRI brought in major partners and is now no longer the primary contributor to GeoNode’s development.  They would like to be able to replicate this success in future projects, and wanted to offer an example to the open source community about releasing and cultivating a project like this.  To clarify the example, OpenDRI asked OTS to write a report about the GeoNode project.

Our process

To complete the report, we interviewed participants in the project, from
people who had been involved from the very beginning to more recent
additions.  In general, we strove to get perspectives from people from
different levels of the contributing organizations — not just
developers, but decision-makers and funders.  We also looked back at
tangible evidence from the earlier days of the project: commits, mailing
list archives, blog posts, and documents generated from early in-person
meetings.

Results

These interviews and research resulted in 9 major lessons for organizations starting future open source projects:

  • Run as an open source project from the very beginning
  • Engage other organizations commercially
  • Focus on communications and evangelism early
  • Find and encourage the right partners
  • Invest in collaboration infrastructure
  • Hold events and sponsor attendance
  • Use funding choices as a signal to peer institutions
  • Improve user experience to attract new users
  • Change the nature of your investment as needed

Flexibility and openness were both key for OpenDRI’s success.  While GeoNode benefited from having been built on existing open source libraries and platforms, its widespread use and adoption were due just as much if not more to the openness of its community.  Its early supporters at OpenDRI shared it widely with similar organizations and worked hard to invite in new contributors.

The full report is available from OpenDRI – see their summary and a download link here, and their announcement blogpost for more.

Posted on
 

Attending the Wontfix Cabal

Pile of stickers that read "wontfix_" in green monotype font on a black background.
Courtesy of Jess Frazelle.

GitHub hosted the “Wontfix Cabal” last week in San Francisco, and I was lucky enough to attend, thanks to a pointer from a friend.  The organizers, led by Jess Frazelle, conceived the gathering as a chance for people maintaining open source projects to discuss their particular difficulties and some strategies for addressing them.  About 100 maintainers took them up on it and convened in San Francisco.  At the beginning of the day, we compiled dozens of sticky notes worth of problems that come up in our various projects.  These ranged from tips for maintainers who had received the classic question “Is this project still maintained?” to “Ethics and Exploitation in Open Source.”  In a common unconference pattern, attendees voted on those topics.  The most popular topics were chosen to become discussion groups, and we split up for a morning session and an afternoon session.

In the morning, I joined the “Code Review” discussion group.  At OTS, we frequently advise clients who aren’t familiar with the ins and outs of accepting and reviewing contributions from outside parties.  This group confirmed our best practices around code review, and reaffirmed its importance.  Much of this particular discussion was about projects with an overabundance of pull requests (PRs), which is of course a good problem to have.

A few themes emerged:

  • Encourage contributors to start a conversation before putting in too much time and effort.   The discussion phrased this as “open an issue before submitting a PR,” but really the goal is to avoid a situation where a contributor puts a lot of work and time into a pull request that the maintainers don’t want to accept.  If the person opens an issue for their proposed change, that gives project maintainers an opportunity to respond with reasons why they wouldn’t accept a PR with that change.  For small changes, opening a PR might be enough to start the conversation, and making a separate issue could be too much overhead.  The important thing to communicate to contributors is that they should be checking in with the project’s maintainers on the direction of their work when they begin.
  • Use GitHub’s templates for PRs and issues.  These save time by giving contributors a clear idea of what kind of information the project expects, like a DCO (Developer Certificate of Origin), tests for any new functionality, and updates to the documentation.  Templates also allow projects to use bots for initial review and response to new contributions.
  • Automate initial responses.  Responding to PRs and issues with bots saves time for the maintainers while still ensuring that contributors get a response (to retain contributors, it’s crucial to engage with them — that attention is their reward for contributing).  Another discussion group pointed out that contributors might take more kindly to being corrected by a bot than by a person.  Robots aren’t judging, so the embarrassment of getting something wrong is much reduced when it’s a bot pointing out the mistake.

In the afternoon, I joined a group on “internal versus external contributions.”  That is, what happens if an open source project is primarily sponsored by just one company?  For one thing, sometimes that company’s priorities will not line up with those of the community.  See the full notes here.  Some of the main points were relatively straightforward: make clear to contributors what kind of governance your project has, or if it has none.  Determine early whether this is primarily a community-driven or a company-driven project, and indicate that to everyone involved.  Overall, make sure that the decision-making process is clear.

One part of this discussion that surprised me was how few of the long-lived, well-known projects represented in the group had any kind of formal governance procedure.  Kubernetes was mentioned as an example of a project that does have explicit governance.  Many others, though, do not.  One recommendation that came out of this session was to research and adopt governance practices in more of these single-company-led projects.  This calls back to the determination to “be clear about the decision-making process.”  It’s fine if internal contributors have outsize influence on project direction, so long as that is communicated at the outset.

I was glad to see that this is consistent with the advice OTS typically gives our clients: don’t worry about governance too soon!  Our clients are frequently concerned about how to set up their governance structures before they have a single outside contributor.  The fact that many successful and widely used projects don’t have formal governance until their lack of it becomes a problem is just more evidence in favor of deferring these structures, which can quash early project momentum.  There is little need to worry about governance until conflicting priorities between contributor groups become apparent.  Later in a project’s life, however, more explicit governance is crucial in order to avoid forks.

Most of the conference went on outside these specific sessions.  We spent twelve hours together, talking about current projects, aspirations for our communities, opportunities for mentoring, and more.  I’m thrilled that I was able to attend — meeting the other attendees was fascinating, as was hearing about different approaches to maintainership.  Many thanks to the organizers and sponsors for making this possible.  I don’t yet know if there’ll be a follow-up next year, but if so, count me in.

 

Posted on
 

Sharing data across Red Cross projects: the Smoke Alarm Portal and allReady

smokealarm-allready-link

OTS has been lucky enough to work with the Red Cross of Chicago and Northern Illinois (CNI) for the past year and a half, thanks in large part to the civic data community at Chi Hack Night.  With Jim McGowan, CNI’s Director of Planning and Situational Awareness, we developed the open source Smoke Alarm Request Portal, where you can request to have a volunteer come install a smoke alarm in your home for free.

Now we’re connecting the Smoke Alarm Request Portal to allReady, an open source platform for volunteer preparedness and coordination (part of the Humanitarian Toolbox suite of disaster preparedness and prevention tools).  With help from both open source communities, the two applications will share data to simplify the process of scheduling smoke alarm installations.


The Red Cross and open source

The American Red Cross is a volunteer-driven organization: their disaster relief and prevention campaigns depend on the work of many people who are not on staff.  CNI in particular believes that this focus on recruiting, training, and involving volunteers across their organization means that they should run their software initiatives as collaborative open source projects.  Open source offers their volunteers another way to be involved in their work, and allows people who may not be able to offer time on the ground a way to contribute to the Red Cross’ mission.


Smoke Alarm Portal

getasmokealarm-screenshot

The Red Cross currently has a goal to reduce home fire deaths and injuries in the United States by 25% by 2020 (see their resources page on home fires).  One piece of their campaign to prevent fires is free smoke alarm installation.  Anyone can sign up to receive a free smoke alarm for their home, and Red Cross staff and volunteers will bring and install one or more as needed.

CNI was already accepting smoke alarm installation requests by phone, but they (and the rest of the Northern Division) realized they could manage requests much more efficiently via the web.  They just needed a simple application where users could request a free smoke alarm.  OTS built an open source application and deployed it at getasmokealarm.org.  See the project on GitHub to see the code, or to get involved (as many people have).


Humanitarian Toolbox and allReady

allreadybiglogo

While the Smoke Alarm Portal was being developed, Jim McGowan began working with the Humanitarian Toolbox (HTBox) project on an ambitious open source solution to increase community resilience and disaster prevention efficiency.  The allReady project, as described in their announcement blog post and project page, aspires to “put disaster out of business” by increasing the resiliency of communities across America.  Its goal is to be a central application for coordinating volunteers across disaster prevention and relief campaigns for the use of non-profit groups like the Red Cross as well as town and city governments. (See the allReady GitHub page here.)


Bringing them together

Since allReady aims to be the central warehouse of all disaster prevention data for its users, it’s only natural that it should be used as an interface into the Smoke Alarm Portal.  Even before allReady is in production, OTS is working with the HTBox team to add API endpoints to both projects that will allow Red Cross volunteers to update the status of smoke alarm requests from within allReady, without affecting the workflow for people requesting smoke alarm installation.

Once this work is complete, end users will only need to interact with getasmokealarm.org, while administrative users (Red Cross volunteers and staff, in this case) can sign in to manage smoke alarm requests and other kinds of prevention work from within allReady.  If a Red Cross staffer knows that a volunteer team is going to a neighborhood to install smoke alarms, they might also be able to stop and drop off supplies for a family in the same area that recently suffered a different kind of emergency.  Once the volunteers update the smoke alarm installation status in allReady, that application will also update the status in the Smoke Alarm Portal.


Next steps

Linking allReady with the Smoke Alarm Portal is still in progress.  We’re happy to work with anyone who wants to to improve and test the endpoints on both projects, to review documentation, and to give feedback on design.  Most importantly, though, let your local disaster prevention groups know about allReady and the Smoke Alarm Portal, and check the batteries in your smoke alarms!

Posted on
 

What OTS Does.

When I tell people that I work at an open source consulting company, I often get puzzled glances (or those agreeable nods that mean “I have no idea what you’re talking about”). What does “open source consulting company” mean? What does OTS do, exactly?

Who are we?

At Open Tech Strategies we do open source development and process consulting for corporations, government agencies, and non-profits who want to produce or use open source software more effectively.

Okay, but what does that mean?

Why open source?

Formally, “open source” just means software code released under a free license. But publishing code that way often turns out to have very powerful effects, so a more useful way to think of open source is as a way of aligning your organization’s goals and its production processes. When you are trying to extend the life or the applicability domain of a software project, improve transparency and accountability in your organization, collaborate more effectively with partners or volunteers, increase user engagement with a service, promote user privacy, or grow a vendor ecosystem, open source provides a ready-made set of practices and promises that enable your natural allies to find & join you in the effort.

Open sourcing a project doesn’t necessarily mean giving up control, except insofar as you decide that that doing so better serves your goals, but it makes it possible for a project to grow beyond the interest or budget of just one organization; we’ll look at some examples of that in later blog posts. And building on open source software means that organizations don’t need to pay to re-invent technological wheels like content management or databases and can focus on their own specific needs.

(See also Ben Balter’s excellent post “Why open source” for a more in-depth look at why organizations choose open source.)

So that’s open source. What exactly does OTS do, though?

Usually, I describe our work as falling into one of a few different situations: building, opening, and buying.

Example Client #1: Builder

This first example client, Builder, needs a piece of software to complete their mission work. They might be a non-profit fighting homelessness or youth violence or a corporation that needs a new research tool. Builder decides to use an open source custom-built solution for reasons of cost-effectiveness, transparency, or one of the other points I mentioned above. Over the course of an agile development process, we meet with the end users of the product and involve them in testing as soon as there’s anything to test at all. All of our development takes place in the open, and we maintain install documentation so that anyone could set up a sandbox instance of the project to try out. When this process is done, Builder has a working piece of software in production that can be set up and maintained by any software development team using our open code and documentation. Their partners can set up the same system, extend it, and share any enhancements they make with Builder. We often continue to work with the customer beyond this point, of course, but the software’s “developer surface area” is now much greater than it would have been were it proprietary: both we and Builder have the ability to welcome new partners into the project, and being able to exercise that ability has proven quite useful.

Example Client #2: Opener

Another kind of client, Opener, comes to us with an existing software product. Possible Openers are a data visualization and outreach engine for astronomers or a transparency tool for governments. While the software product is not the entirety of Opener’s mission, it is a crucial part of the work and face of the organization. For Opener, we focus on code resiliency, partner collaboration, contributor engagement, and (where applicable) development of a commercial ecosystem around the project. When we complete our work with Opener, they have a usably open source project that has clearly-documented code, findable discussion forums on the web, an issue tracker in use, and all the other affordances of a well-arranged open source project. The project is well-positioned to invite new collaborators and engage users.

Example Client #3: Buyer

A third type of client can be called Buyer. This client is an organization that wants to use and/or contribute to open source software, but needs advice on adapting their procurement processes and on how to invest strategically in software technology. Buyer might be a government agency that needs to set up definitions and standards around procuring and using open source software, or could be a foundation or corporation that wants to invest in open source but needs some advice on how to select and support the right projects. For Buyer, OTS researches the state of the field in their area of interest and provides recommendations for investment and/or procurement routes. When we complete our work with Buyer, we often deliver a highly specific report on the best ways they can use or invest in OSS. They are prepared to interact with open source in the way that best advances their strategic goals.

That’s the story (mostly).

Naturally, not everything we do falls neatly into these categories of building, opening, and buying open source software. For example, we also offer advice for companies that want their employees to be able to contribute to upstream open source projects and helps open source projects draft CLAs or think through their business strategies. If you’re a Builder, Opener, or Buyer or just have questions, feel free to reach out. Thanks for reading!