By David McCann, Director of Technology for the T4D Open Source Software Incubator & Accelerator, DIAL
“Global Good” Open Source Software (OSS) products in the Technology for Development (T4D) sector are mature products that have already received millions of dollars in investments and have been widely-deployed. One million dollars–the rough estimate of annual running cost for many existing Global Goods–may seem like a high cost if procured as a one-off, but one million dollars of co-invested funds for a freely-available-to-all product valued in the tens of millions of dollars is a great investment.
Below are three misconceptions or bad practices in bidding, staffing and contract management that have had an outsized impact on the quality, sustainability and reusability of these Global Goods, negatively impacting the long-term ROI of these efforts.
Contract Bidding Process Obscures Sustainability
One common challenge in software development procurement is contracts are written with feature-oriented deliverables solely around what the product must “do,” and vendor selection is typically weighted most heavily towards lowest cost. The challenge is that such a selection process doesn’t capture any real measure of quality or maturity of the deliverable, and methods to measure these attributes are complicated, subjective, and difficult to write into contract language. Often, you get what you pay for: there isn’t a simple conversion factor between the quality of a product built by two junior coders versus that of a product built by one senior systems architect, even if the cost for both options was the same. Cost-cutting means corners will be cut “under the hood,” or out of view of the functional, user-facing requirements.
This cost-cutting typically hinders the scalability, maintainability, or extensibility of the product, and is an example of a failure to apply the principles of Designing for Scale and Building for Sustainability. Gaps of this nature in existing products built within this procurement model are things DIAL aims to help improve, both through direct software engineering support as well as targeted grant-making. Going forward, improvements must be made to the bidding process that places due diligence as the most important factor, rather than cost.
Dirty Jobs Are Important
“Under the hood” aspects of a product may not seem to have direct impact on any particular programmatic mission and are therefore also viewed as “overhead” or “excess” costs when they shouldn’t be. Rather, contract language should include these as separate deliverables, or as intrinsic to every feature-based deliverable, including stipulations about system performance (“the user interface must be responsive even with 1M records in the database”), documentation (“end-user documentation, with screenshots, for how to deploy, configure, and use the system”), and extensibility (“the code must be open-source and publicly available on github or gitlab, it must have 100% test coverage, and it must adhere to industry-standard style checking for the language used”). All of these contribute to more sustainable, performant and extensible/reusable products, and should be seen as responsible allocation of funds instead of a frivolous waste of money.
These symptoms could be seen as a failure to adhere to the following principles: Design With the User, Build for Sustainability, or with the notion of Reusing and Improving existing products in the future.
Labor as Investment, Not Staff Overhead
When staffing directly for software engineers, development organizations often drastically underestimate the effort (and therefore number of staff) needed to create a reusable product, and pay severely below market rate for tech talent that is in high demand in other sectors. This results in hiring under-qualified and inexperienced developers to fill roles to build enterprise-level products they lack the skill to do effectively.
Software products are different from similar work with other types of knowledge products: contracts to do research, produce white papers, and the like are typically immutable artifacts rather than “living” works. Once the initial effort is made to produce them, there is typically no ongoing maintenance cost or need to update them incrementally.
In contrast, software products should be viewed as infrastructure investment, and the labor to build them the same way as any “building materials” investment. As with large physical infrastructure projects, a larger up-front investment in software products can lead to a better return on investment (ROI) and lower the costs to enhance the product in the long term. The policy of calculating an organization’s overhead should be modified to reflect this difference of investment, or at the very least reporting should disaggregate these costs to allow for alternative interpretations to be analyzed by donors and the public.
Innovation Starts (and Stops) with HR and Business Operations
Those working most closely with the software code in the T4D community will find these points about as controversial as the Principles for Digital Development: they are so axiomatic as to go without saying. What’s required is fundamental changes in how we view software engineering labor, software product investment, sustainability, and co-funding for those working further away from the software, in the development sector bureaucracy.
At DIAL, we are working to solve these challenges at many levels of detail. As stewards of the Principles for Digital Development, we aim to promote a community of practice, knowledge, and behavior that will help modernize the development sector writ large, including those whose work focuses on contracts management, hiring and staffing, and procurement. The changes above are a few concrete examples, but more resources for implementers can be found here.
This year, DIAL is also looking to build on the ICT4SDGs work we released in partnership with ITU on the sidelines of last fall’s UN General Assembly, where we called for a whole-of-government approach to software design and deployment. DIAL is building a requirements roadmap to move towards a microservices architecture for products in the space, and will begin to directly fill gaps in the existing product ecosystem to move it towards this structure. And we’re hiring engineers!
We welcome your thoughts on the challenges, what you may be doing to address them yourself and if there are opportunities to work together, let us know. So that we can all work together to ensure interest in Global Goods continues to trend upwards.