I came across Nadia Eghreb first while doing some research on existing metrics that measure the value of open-source. Authored while she was at GitHub supporting open-source maintainers, it is mostly about the precarious relationship maintainers have with their community, funding, and their code. It led me to buy her excellent book “Working In Public” that builds on some of these ideas, and I decided to jot down some thoughts…

The word free in free software does not refer to its cost. It is “free as in freedom, not as in beer”. It is public code that gives the user the freedom to study, share, and modify it. It is cheaper to build, easier to distribute, and flexible to customize. As a development methodology, it is analogous to being able to open up the hood of a car and seeing what’s inside, instead of sealing the engine from the driver’s view.

Open source is how most digital infrastructure gets built. Every website & mobile app, regardless of complexity, can be broken down into smaller components of public code. This is the nature of software development. In JavaScript, npm deliberately encourages each project to be small and modular. The 10,000 foot view of the ecosystem resembles a tower of LEGO blocks that somewhat imperfectly fit together.

Companies use public code simply because it is more efficient than building each piece themselves. Moreover, we can actually observe the increase in permissive licensing over-time — it covers about 65% of all GitHub projects today, and enables any company to profit from building their products on public code.

Most open-source projects are brain-children of creative people who propose an alternative solution to an existing problem. The reality is that their contributions originate from a culture of volunteerism and pragmatism. Their contributions then become critical infrastructure that our economy & society — from billion dollar companies to government services — all depend on. Given how intertwined our lives are with technology, we all implicitly depend on the free & public code that’s constantly running in the background.

Many well-funded successful projects exist, but they tend to be on the extremes of size. For example, remember that time WhatsApp prompted you to rate their call? That's Appirater, a library that...prompts users to rate an app. It is used by almost every iPhone app, and per the maintainer, requires only 1-2 hours of maintenance per week. On the other end, The Linux Foundation, created in 2007, has about 637 employees to help keep the the incredibly invaluable project alive (currently hiring for Event Coordinators!).

In contrast, the vast majority of critical projects are neither simple nor endowed with institutional funding to support more. For example, it was only post Heartbleed that OpenSSL, began receiving material funding via donations, and it was still only sufficient to cover 4-5 full-time developers for 3 years! These projects toe the line between being large enough to require external support, but not large enough[1] to have existing organizations support them. Moreover, the attitude towards these project maintainers is that they should either learn to cope, or that their project is not “good enough” to receive institutional backing.

The transition from a selfless creative pursuit to a critical public infrastructure is…not easy. At tea, we think this underscores the importance finding these projects the support they need, starting by measuring the impact they have had on free & open source software. We call this approach teaRank...more to come soon.

[1] - a typo in the original article that I fixed.