BekahHW
8 mins read
In December 2021, the software world faced a crisis that would later be known as the “Log4Shell” vulnerability. The critical security flaw was found in Log4j, an open-source Java-based logging utility widely used across various applications and services. This vulnerability allowed remote code execution and exposed millions of systems to potential exploitation. Despite extensive efforts to patch and mitigate the issue, the Log4j vulnerability continues to plague the software industry, highlighting both the strengths and vulnerabilities of the open-source model.
According to a 2023 article by Connor Jones, even two years after the Log4Shell vulnerability was disclosed, nearly 25% of apps may not have updated their Log4j library after the vulnerability was fixed. The issue isn’t just the vulnerability, though; it’s also the ongoing challenge of maintaining up-to-date and secure dependencies within the open source ecosystem. There’s a broader problem of dependency management and the need for more awareness within the development community to effectively decrease these risks.
If we look at Apache Log4j 2, in the last year, for example, we see that majority of the commits are coming from two contributors, ppkarwasz and vy. While we couldn’t say for sure what would happen if ppkarwasz left the project, we can confidently say that the project would feel the impact for a while.
Our entire digital infrastructure is a house of cards built on good faith. One burned-out maintainer, one vulnerable dependency, one "I'm taking my ball and going home" moment, and suddenly we're all scrambling.
Jana Iris brings up another perspective in the problems with open source in her episode of The Secret Sauce, "it's actually the biggest thing I always talk about is building developer trust, but also building trust in the enterprise. The biggest thing is like, they don't want to start adopting a solution and then all of a sudden you're not here in a year."
Companies are in a constant state of digital FOMO - they want to innovate, but they don’t want to bet on the wrong project. Imagine adopting a solution only to find out a year later that the maintainer has decided to become a goat farmer in the Andes. It’s like the xkcd comic that haunts every developer's dreams - the entire world relies on a project maintained by a single volunteer. It's funny because it's true, and it's terrifying because it's true.
But here's where it gets really interesting: this isn't just about managing risk. It's about shaping the future. The projects we choose to support today are the innovations we'll be using tomorrow. It's like we're all time travelers, using pull requests and commits to shape the future.
So, what's the solution? It's not simple, but it starts with dialogue. We need to be talking about this - not just after a major outage, but openly and constantly. We need to rethink how we understand, value, and support open source projects, contributors, and maintainers. Because here's the truth: in the world of open source, we're all maintainers now. Every line of code we use is a responsibility we inherit. It's time we started acting like it.
But it goes beyond the dependencies we’re using. It’s also about looking to the future and the projects that are driving innovation. This is another one of the problems with open source software : redundancy in efforts and lack of visibility into past projects. We often rebuild solutions because we don’t know similar efforts were made before. Tools like StarSearch can help by providing a comprehensive view of past and present contributions, preventing redundant work and saving valuable time and resources.
While we see these challenges across the open source landscape, they are significant in open source AI because it’s moving incredibly quickly and they represent a frontier. Addressing these issues will impact the whole landscape, including AI.
Supporting open source AI promotes transparency and accountability in AI development, allowing for greater examination of algorithms and models to address concerns about bias and ethical considerations. This openness is incredibly important as AI increasingly impacts our daily lives and decision-making processes.
Because researchers and developers worldwide can contribute to and build on existing projects, we’ll see benefits for the entire field. This collaborative approach also facilitates cross-domain applications, bringing AI to a variety of sectors.
Open source AI isn't just another tech trend. It's our best shot at democratizing one of the most powerful technologies of our time.
Take a look at the Open Source AI workspace. Projects like PyTorch, scikit-learn, and llama_index have high activity and low lottery factors.
By focusing on open source AI, we can tackle key open source issues and drive innovation by increasing contributor confidence, providing clear growth pathways, and ensuring project sustainability.
One of the most pressing problems with open source software is the long-term sustainability of projects. To be a sustainable project, you need returning contributors and viewers who are willing to engage and support the project as a contributor. What does that mean? That means going beyond looking at stars and forks as metrics of success and understanding if those actions translate to contributions in the open source ecosystem and your own project.
At OpenSauced, we call this Contributor Confidence. For instance, if your project has a lot of stars and forks, but not a lot of those translate to contributions, then it indicates the project isn’t effectively converting initial interest into contributions.
In a conversation from The Secret Sauce podcast, Jordan Harband discusses the sustainability problem and highlights a potential solution. He mentions that while companies have resources like money and people, individual maintainers often lack these, leading to project stagnation:
“I get a lot of complaints from people and companies about where we're blocked. We can't, well, companies have money and people and people have time. And that's, those are things that I don't really have at the moment. So if anybody showed up and was able to come up with enough money that I could justify, like at the moment, not looking for a new job for a month so I can work on this instead, I would be happy to do it. And similarly, if any company showed up – one tried and then ended up bailing on it – If any company showed up and said, we have people to put on this. Can you help them? Like you have my axe, like I'm here. I will jump on video calls.”
There’s a disconnect between individual contributors and corporate resources. Companies have the means to support open source projects but often lack the commitment or follow-through to sustain them. Maintainers shouldn’t have to wait until the point of complete burnout to receive the support they deserve from users.
Another one of the issues with open source software is the new contributor experience. @bdougie captures some of the challenges that we don’t talk about enough in the Secret Sauce:
"sometimes we need like way more context and intro conversations around that, which is like how to be a good beginner.” The open source community has traditionally focused on initiatives like "good first issue" and "first-timers" to encourage new contributors. However, as the ecosystem continues to grow, the sheer volume of projects and contributors can be overwhelming for new contributors and maintainers alike. "There needs to be like a step before, which is like, this is cause as you mentioned before, like when you got an open source and same when I got an open source, it was a smaller ecosystem."
This lack of introductory guidance and often experience on the part of first-time contributors creates a contributor confidence gap. They might struggle to navigate the open source ecosystem, understand complex codebases, or feel unwelcome within established communities. The result? Potential contributors leaving before they can even begin to contribute. This ultimately weakens the foundation of open source.
But what if the contributors aren’t ready to contribute? What if they need more experience? Encouraging contributors to dive into projects before they are adequately prepared can be counterproductive. Instead of creating a supportive environment, we risk overwhelming them, leading to frustration and disengagement. Additionally, pushing unprepared contributors into active development roles can result in low-quality contributions that require extensive revisions or even rejection, hurting their confidence and willingness to participate.
This premature push not only affects the individual contributor’s experience but also the health of the project. Experienced maintainers may find themselves spending more time than they have correcting errors or providing basic guidance.
If we want to manage successful communities in open source, ultimately, the goal should be to nurture new contributors, providing them with the tools, guidance, and gradual introduction they need to build their skills and confidence.
To be a good contributor, you have to understand how to be a maintainer, so you can appreciate the challenges and responsibilities maintainers face. This will allow contributors to have a sense of self-awareness about their role in the project’s ecosystem and how their contributions can best support its long-term success.
Open source is messy, complicated, and absolutely essential. It's a beautiful contradiction - a system built on freely shared code that powers trillion-dollar industries. But here's the kicker: this paradox isn't a bug, it's a feature.
The very qualities that make open source so powerful - its openness, its collaborative nature, its ability to evolve rapidly - are the same ones that create its biggest challenges. It's like trying to build a rocket while it's already in flight. Exciting? Absolutely. Easy? Definitely not.
By leaning into these challenges - sustainability, contributor experience, dependency management - we're not just fixing problems. We're unlocking the next level of innovation. It's like we're collectively leveling up the entire tech ecosystem.
And let's talk about companies for a second. If you're still treating open source like a free buffet, you're doing it wrong. It's time to step up, get strategic, and start actively nurturing the communities you depend on. The future of tech isn't just open - it's wide open. And it's waiting for us all to make our mark.
Bekah graduated from a coding bootcamp in May of 2019 and since then has spent time as a frontend developer, started the Virtual Coffee tech community, spent time in DevRel and has continued to mom her four kids. She currently co-hosts the Compressed.fm and Virtual Coffee podcasts, lifts heavy things in her free time, & works as the Developer Experience Lead at OpenSauced.
Recent Posts
bdougie
2 mins read
OpenSauced joins Linux Foundation, making AI-powered open source analytics freely available while expanding beyond GitHub to serve the broader open so...
#kubernetes
John McBride
5 mins read
How the OpenSauced engineering team made a near-zero downtime migration to Microsoft Azure