Funding digital infrastructure

This week, a group of funders got together in Philadelphia, for the first time, to discuss software infrastructure.

We had a range of funders in the room, from philanthropic foundations (Ford Foundation, Sloan Foundation, Media Democracy Fund) to software foundations (ex. Mozilla Open Source Support, Linux Core Infrastructure Initiative) to funders with a more private (Union Square Ventures) or public (Open Technology Fund) flavor.

I was keenly aware, coming into the conversation, that we all had very different backgrounds and even definitions of the problem. It turns out we had more in common than I realized.

Here’s a recap of what we discussed.

What is digital infrastructure, anyway?

For the most part, everybody seemed to agree that infrastructure, for the digital age, was:

1) software

2) open source (as a way to legally guarantee public rights to use and consumption)

We also included dependencies as part of the definition (“If we take it away, other things fall apart”). Lego blocks, glue, and bridges were some of the analogies used in conversation.

Where to draw the dividing line on infrastructure seemed to depend on whether we took a social justice (“Internet as a public good”) or utilitarian (“stuff that businesses + developers need to make things”) lens. For example, we had a good discussion about whether Firefox counted as infrastructure, because it’s a consumer application. And if not browsers, what about critical developer tools like GitHub?

What does success look like for projects?

A recurring question among participants was how digital infrastructure sustains itself in the long run. Grants are finite, especially in the digital space. Funders wanted to know where projects could find financial sustainability beyond the life of a grant.

We started by discussing what, exactly, an individual project needs money for. We agreed that most types of contributions should not be tied to money. Intrinsic participatory dynamics are what make open source special, and we wanted to avoid changing them.

We decided projects need money for overhead, such as:

  • Project management
  • Maintainership (i.e. regular code contributions requiring significant time)
  • Infrastructure costs (like servers)
  • Business development and partnerships (ex. even if costs are donated, who finds and manages those relationships?)
  • Sales, customer support (if there is a commercial aspect to the project)
  • Fundraising and grant writing!

These skills are very hard to come by for public software, because talent tends to be heavily skewed towards technical backgrounds. Even community managers, evangelists and documentarians often started as programmers first. And many of the roles listed above don’t lend themselves well to the participatory dynamics of open source (that is to say, they’re full-time jobs).

One participant remarked that “sustainability” seems to have two components: the community and the money. A project with a lot of money, but no community, will struggle to survive. So will a project with a strong community, but no money to support critical, centralized roles. (The equivalent among startups: needing both traction + funding to succeed.)

Next, we mapped out who puts dollars towards this now, in which format, and what their motives might be. Our list included software companies, government, customers, and venture capital, among others.

Long-term sustainable revenue models included:

  • Finding something to monetize and creating a commercial entity
  • Getting a company, university, or other institution to become patrons of the project (ex. by hiring maintainers)
  • Creating consortiums or foundations for multiple sponsors to pay into

We discussed some emerging models, like DAOs and tokens. My personal view (note: there was not consensus here) is that this a problem of sustainability, not innovation. Experimental models will continue to mature, and may become useful as they are derisked, but they are not a panacea. We aren’t going to stumble upon an idea we simply haven’t thought of yet.

In a sense, I find this liberating, because it means we only have to look at “known knowns” and find ways to work towards them, rather than worry about what we don’t know. It means we can take inspiration from other sectors and historical times, and figure out how to apply those learnings here. The road is not glamorous, but it is achievable.

Given finite funding, where are the critical needs?

Several funders expressed feeling overwhelmed by what seemed like an ever-growing list of projects in need. It is strategically unwise (if not downright impossible) for funders to respond by funding each project directly. This would be a poor use of limited capital.

Instead, funders were interested in how they could use their capital to benefit the entire system and encourage the right kinds of incentives. For example, NumFOCUS received a grant from the Sloan Foundation to develop and disseminate best practices for open source projects. Linux CII developed a standard set of criteria for measuring the health of projects.

Some of the opportunities that appealed to funders, at this stage, included:

  • Mapping out which projects were most heavily depended on, and which ones were most at risk
  • Quantifying the economic value of digital infrastructure to help make the funding case to a wider audience (like government)
  • Developing organizational best practices for project communities, and evangelizing them
  • Funding organization development and underrepresented skills for projects

Did anybody learn anything?

At the end of the meeting, we talked about what we got out of the day. Several participants expressed that they were exposed to new perspectives that they had not previously heard before. (I echo this sentiment!)

One funder said that he now felt like he had “10 new people to talk to”, which was a valuable takeaway for everybody. Many funders only knew one or two others in the room beforehand, but by the end of the day, we left with more ways to compare notes and synthesize ideas, which will surely continue beyond this week.

Another participant admitted he had started the day feeling somewhat skeptical about the need. He felt that there was a certain magic to how open source projects were organized, and he worried that funding could disrupt the natural order. (This concern was shared by several others in the room, and we even devoted part of our day to discussing how to reduce harm and anticipate unintended consequences of funding.) But by the end of the day, he concluded there was a paradox:

“If IBM wants a project to exist, IBM will make it exist. But if a community of developers wants a project to exist, they don’t necessarily have the resources.”

Okay, that’s all warm and fuzzy, but now what?

Most funders in the room are now committed to make grants in this space over the next few years, so the question is not a matter of if, but how.

Some action items that we left with, in addition to exploring the opportunities listed above:

  • Quantifying the capital available across funders, comparing portfolios and figuring out where gaps exist
  • Inviting other funders to the table (government and corporate, in particular)
  • Creating “rapid response”-type funds that can be deployed more quickly (grantmaking is notoriously slow)
  • Creating a more formal call for proposals and making funding opportunities better known to potential grantees

P.S. If you’re a funder or someone interested in funding, and you think any of this looks interesting, I’d love to hear from you!

Epilogue: What this means for me

This meeting effectively wraps up my research period with the Ford Foundation. I’ve published a 143-page (!) report about digital infrastructure, its history, its challenges, and a framework for potential solutions. You can read it here. (If you actually read the entire thing, I’ll send you a sticker or something. Maybe just a really enthusiastic emoji. 😃)

The process of researching this report was itself invaluable. Countless interviews helped me get to know many people in this space, and writing things down forced me to better articulate my views. The multiple rounds of reviews challenged my assumptions and strengthened my thesis.

I owe the Ford Foundation (in particular, Michael Brennan and Jenny Toomey) an enormous thanks for supporting my work. If you ever get a chance to take their money, do it. They took a chance on me at the earliest stage, gave me resources and support, challenged me to think bigger, and more than anything else, believed in me and saw what I saw, where so many others had been skeptical. Now a lot of other people see it, too.

I want to emphasize that a year ago, many funders were not aware of these issues, nor putting money towards it. Change rarely arrives with a flash and a bang, but I hope that several years from now, we’ll look back to this moment in time and realize it was the start of something new.

(P.S. What’s next? Stay tuned…)

I’m currently exploring better ways to support open source infrastructure. If you want to stay involved, you can sign up here to get updates when I post something new, or follow me on Twitter.