Open Source Software Projects Are Brands

Apologies for the reductive, attention-grabbing title. Clearly OSS projects are communities first, and brands and many other things second. This line of thinking was prompted by some late night doomer reflections on the role of OSS in an LLM-driven future, and I came to this surprising realization that open source projects (or at least federation projects), are largely about creating reputation and establishing community acceptance.

Let’s face it: LLMs are upending the software industry and driving software engineers a bit crazy. I know many real, serious engineers who are using these tools in earnest, and they believe they are building real, high-quality software. The problem is, when you build software this quickly, how do you actually verify your work and create trust in the software? You can come up with all kinds of testing methodologies, but at some level, the programmer needs buy in from their peers, their manager, their org, their industry, and at the highest level, regulators in highly-regulated sectors like automotive software. The process of aligning on goals, reviewing the software, and verifying when requirements have been met is becoming the bottleneck.

Enter open source projects. Historically, open source software usage has mostly been about boosting productivity. Why reinvent the wheel when you can grab a free, off-the-shelf solution? If you evaluate the available OSS projects well, you can select libraries from reputable projects with diversified organizational support. That gives you confidence that a given component will be maintained, and potentially grow new and useful features. Popular projects have a community around them. The existence of the community is what gives you confidence that you can ship that component without worrying about rebuilding it, incurring your own maintenance burden, and creating your own security vulnerabilities. A 2022 Linux Foundation study estimated that 70-90% of any given software codebase is open source code, demonstrating the ubiquity of OSS.

If developers use so much open source code, why hasn’t it taken over the world? Most consumer products run proprietary operating systems and products, and it doesn’t feel like consumer advocates are winning the right-to-repair battle, at least not yet. Part of the answer is that open source software maintenance and development is slower than, and therefore more expensive than, closed-source, proprietary software development. Companies hire product managers and leaders to ensure that teams are aligned on project goals. This does not happen by magic in the open, and the lack of clear goals and objectives makes it difficult for diverse collaborators to prioritize their time and efforts. Open source projects tend to be driven by developers, who design processes suited to their needs and desires, and this tends to create a bunch of gaps around documentation, community management, graphic design, product vision, and the rest of it. The best open source projects tend to solve difficult engineering problems, where a bunch of developers or engineers get together and agree on a good design for a database, a distributed system, a compiler, or something else technical that doesn’t require a lot of graphics and visioning.

Back to LLMs. It has been suggested that, given how “easy” it appears to be to generate new software, open source is going to play less of a central role in software development going forward. Given the lack of overwhelming success of open source thus far (think “year of the Linux desktop”), the competition from LLMs on the horizon, and the pressures on maintenance resources from LLM-generated reviews and vulnerability reports, does that spell doom for open source projects? I don’t think so!

I didn’t bury the lede, my thesis is the title: Open source software projects are brands. A brand is a mark of reputation and quality. Even though open source maintainers are less inclined than ever before to review your code, I think everyone recognizes the huge inherent value of having their code merged into a known, popular open source project. If you build a library for X under the umbrella of an existing open source project (LLVM, Linux, CNCF, Kubernetes, git, whatever), that code gets distributed widely, and it is presumed to have a certain level of quality. The maintainers who approved merging the code are effectively independent auditors, and they must have all sat down and thought to themselves, “yes, this change is valuable, and it’s worth my time to review it, and I’m willing to help triage issues in this code going forward”. That is a powerful statement! Traditionally, maintainers are trading free reviews for free contributions in the hope of mutual benefit, but it’s worth pointing out that if you want to pay for a software audit, that usually has a hefty price tag.

Sticking with this idea of open source projects as uncompensated, independent code auditors, because open source project maintainers aren’t accountable to your boss, they actually have leverage to insist on high quality standards. They don’t have any incentive to rubber-stamp your crappy, two-thousand line, monster PR because it’s important to your mutual great-grandboss or VP. As a maintainer, they are the one most likely to inherit responsibility for that code, so they are incentivized to insist on high standards.

There is, however, a give and take. Fussy maintainers are a surefire way to dampen the enthusiasm contributors have for working on your project, and code review is structured to be a critique. It’s important for maintainers to encourage contributors, and to not insist that everyone do things perfectly, exactly as they would do them. Insisting on unreasonably high or capricious standards is another OSS project failure mode. In this case, the project can stagnate, and potential contributors will look for other homes for their effort.

Circling back to LLMs again, if software becomes cheaper to produce going forward, I still think there is a role to play for slow, messy, bureaucratic, democratic open source software projects. Some discerning customers like sovereign nations are going to start asking more questions. The EU CRA is already requiring SBOMs. I used to worry that the SBOM reporting requirements were pushing companies away from OSS and towards first-party reimplementation, but I think a discerning customer should know that software built from reliable, reputable components with multiple industry stakeholders is likely to be more reliable than something built from scratch. What should I trust, a giant, 100% proprietary app that a contractor vibe-coded themselves, or a project built on off-the-shelf, best-of-breed OSS components from reputable communities?

If we accept the thesis that OSS projects are quality-assurance brands, then I think it suggests that the work of running an open source project going forward is going to skew more heavily in the direction of maintenance activities. Maintenance here encompasses everything a project needs to do to assure quality: testing, fuzzing, security response, code review, dependency analysis, etc. Speaking for myself, when I’ve acted as a maintainer, I’ve always had a guilty feeling like I should be spending more time writing code, but if we accept the thesis, then maintainer time is probably best spent ramping up new maintainers, documenting quality standards, working on project policy, improving testing methodologies, or anything that communicates the standard of excellence that is expected in the project. You probably have to attempt a few code changes to maintain the domain expertise necessary to perform those activities, but the primary focus of making changes is to test ideas and sharpen the skills necessary to judge what makes code good. At the end of the day, the value of an OSS project is tied up more in its community and reputation than it is in its velocity. Which is perhaps just a new spin on the old Apache Way: Community Over Code.