ICTworks

Much has been said about the power of open source software for ICT4D, but there’s seemingly little on how to navigate the decisions around how to use, build, or grow open source from a technical perspective. To understand the ins and outs of what makes open source work (or not), we return to those who first started the open source movement more than 30 years ago: software developers.

I turned to the software developers and product strategists around me at Caktus Group to write this article. Over the years, we’ve seen many ICT4D open source implementations in different circumstances. Using that experience, here is a distillation of key points to remember when approaching open source.

When proprietary and out-of-the-box solutions make sense

For organizations that can find a commercial product with all the features they need, at the right price for today’s and tomorrow’s usage, a proprietary product is really an ideal solution. Open source does not make sense in every context, but it’s a factor worth considering in every scenario. Amongst our clients, the most common reasons to consider an open source solution is that they have outgrown their existing software or it is a grant requirement.

One of our clients had built a prototype SMS system that assisted HIV-positive users with medication adherence and education. The prototype was built upon a proprietary system designed for the pilot. Expanding adoption of the proprietary system would’ve entailed not only more usage costs, but also the cost of custom feature development with no (low cost) flexibility for future growth.

As a result, building a new version of their system using UNICEF’s open source RapidSMS became a viable solution. They could innovate upon existing technology, control their own system, and build new tools for themselves and others. But had they not wanted to expand usage and maintain the same feature sets, sticking with their original proprietary system would have made sense.

Open source doesn’t mean free, but it also doesn’t mean 100% custom

Open source means the code is freely available, but it’ll always take the efforts of developers to transform that code into a solution for your needs. Whether the developers are internal or external, staffing a technology project is not the same as having to build software from scratch. Open source software provides a foundation of features and functionality out-of-the-box that can be further enhanced.

As a result, organizations can have novel solutions that feel highly custom, but under the hood, it represents the best of global collaboration. The cost savings of not having to reinvent the wheel is substantial not only for the organization, but other organizations with similar needs. The greatest everyday benefit is to users who save time with a system that can reflect their workflows instead of having to adapt to the software.

Open sourcing is most cost effective with planning

Open sourcing is most effective (read: fastest and cheapest) when it is planned for from the start, including navigating the complex license type determinations. The end goal of open source is innovation and that can only be done through the collaboration with others.

On a purely practical level for an organization, this ideally means more developers working on the project after it’s initial completion at no additional cost. A healthy open source community around a project will identify and fix bugs and build new features that capture their interest.

Laying the groundwork for an open source developer community takes effort which, at minimum, includes creating a welcoming space: clean code and clear documentation. The more effective approach also includes having contribution guidelines for other developers and avenues for new developers to communicate with those experienced in the project.

The code in and of itself is not enough to enable innovation. Like any community-building effort, communication is critical to unifying people and process around ideas. The resources made available and tone set by the founding development team directly influences how others feel about contributing to the project.

For those who aren’t developers, what all this essentially means is to leave room in your project timeline and budget for open sourcing. Examples of critical components of the open sourcing process developers includes the following:

• Security-minded system architecture. Planning for open sourcing from the start also changes how developers approach security. Knowing that components will be made public ensures that the team, in constructing the foundations of the system, separate out potential security risks so that it can be readily stripped during open sourcing. Otherwise the cost to retroactively do this can be cost prohibitive.
• Documentation. Providing robust documentation for future contributors is easier as the software is being created. The documentation of IRC’s Commodity Tracking System is an example of best practice. It contains precise deployment guidelines and explanations of each component of the system and how it fits into the overall system architecture.
• Open source system testing. All systems undergo testing, but a new open source project has to undergo a different kind of testing—how replicable is it? Developers unfamiliar with the project attempt to follow the documentation and deploy the project. The process highlights challenges future developers will have in deploying the project so the team can correct issues before they make the code public.

Secure open source software should always be the goal

In the Principles for Digital Development, there’s a principle for open source software and also a principle for addressing privacy and security concerns. Some have taken this to contradict the idea of open source and open data, but they must go hand-in-hand.

Many of the most impactful open source ICT4D projects also must manage highly sensitive data. UNICEF’s seminal Project Mwana, for example, is an open source project that sends HIV status information to clinics. Libya’s SMS voter registration project, now open sourced by Caktus as SmartElect, similarly managed highly sensitive data. Assessing security and privacy risks is essential prior to open sourcing.

One method for organizations to approach open source software security is to use threat modeling, a process detailed by Rehal Dette in this excellent ICTWorks article: What’s your ICT4D Threat Model. Done in conjunction with developers, threat modeling helps identify weaknesses and raises appropriate responses. In open sourcing SmartElect, for example, knowing that those who would want to attack the system were technologically sophisticated, the developers on the team recommended a third-party security firm to attempt hacks on the system.

Technological security and privacy, however, is just one component of overall security. In our experience, especially when working in-country, it’s the process of data collection and data dissemination before and after it enters the system that often opens up security compromises. The way information is stored, especially in remote locations that may rely on paper processes, depend heavily upon how individuals approach securing data.

Open sourcing is the beginning of a journey (not the end of the road)

Once you have laid the groundwork for a community around an open source project, you begin the real work of open sourcing: maintaining your project and managing external contributions from other developers. It should be noted that open source contributions reflect the interests of volunteers, not necessarily the needs of the organization like security updates or new features.

Ongoing project maintenance and support of this nature often can stretch internal teams and put organizations in a difficult spot— their mission is to serve stakeholders, not to be a software firm. Technology consulting firms can provide this service, creating a best of both world’s scenarios: open source software with commercial support.

Open source will help us all impact more people

Open source, at the end of the day, is one tool of many in increasing impact for stakeholders. Its popularity across all industries and governments is tied to its ability to build faster, smarter technologies. However, building open source in a sustainable way requires approaching it from a developer’s perspective, especially in building a healthy community around any project.

The growth in open source since the beginning of the movement (nearly 65% of corporations use it!) is encouraging and we can’t wait to see more ICT4D projects being made available for all.

By Hao Nguyen of the Caktus Group