STORMY PETERS

Is AI Killing Open Source Software?

2026-04-12T14:06:57Z

I love giving talks that explore big questions — the kind that are facing all of us right now and that nobody has fully figured out yet. “Is AI Killing Open Source Software?” is exactly that kind of question. It actually reminds me of a talk I gave really early in my career where I was worried that paying maintainers to work on open source would kill open source. (Spoiler: it didn’t.) I like doing research, having lots of conversations, and then bringing it all to an audience to start a bigger conversation.

That’s what I did at SCALE 23x in March, and I was super excited that the audience participated fully. I learned a lot from them, and I’m hoping we will all continue this conversation.

What I Thought Would Happen with AI

When I first started exploring this topic, I thought the answer would be pretty straightforward. AI makes it so easy to create software now that nobody will bother to share it. If it takes you 20 seconds to generate a feature, why would you bother contributing it back to a project? Anybody else could generate it in 20 seconds too, so it just wouldn’t feel worth your time.

And then when I talked to people, I found another layer. They wouldn’t contribute back because the code didn’t feel like theirs. They didn’t understand it as fully as code they’d written entirely by themselves, and they didn’t feel like they could maintain it if they contributed it upstream. So there’s this strange thing happening where AI helps you create code faster, but it also creates a kind of ownership gap.

I think both of those things are real. But when I brought up the topic, people’s main concern wasn’t what I expected.

The Slop Problem (and How Big It Actually Is)

What people really wanted to talk about was slop contributions. These have gotten a lot of press, and for good reason. Some really big projects – cURL is the famous example – have had serious problems with people submitting AI-generated PRs and bug reports that overwhelm maintainers who are already facing burnout. Daniel Stenberg ended up shutting down cURL’s bug bounty program after six years because the flood of low-quality, AI-generated security reports was taking so much time to deal with, and none of them actually identified a real vulnerability.

I think the projects most affected by this are the really famous ones, especially those that offered financial incentives like bug bounties. If you’re paying people to submit bug reports, and AI makes it trivially easy to generate plausible-sounding ones, you’re going to get a lot of them from people trying to make money.

But during my talk at SCALE, very few people in the audience said their own projects had been overwhelmed by slop PRs. In fact, one person told me that AI was actually making it easier for new people to contribute. They were getting new community members that way! And anyway we can encourage new contributors is really important right now.

The New Contributor Problem

A real problem we have, that we don’t have a good answer for yet is, how do new maintainers get started in this world of AI?

The traditional path used to be pretty clear: you find a “good first issue,” you submit a small PR, it gets reviewed, you learn something from the feedback, and you gradually build up from there. But AI has broken that. If a new contributor wants to contribute quickly, AI often helps them create a PR very fast (and we encourage people to use AI to learn!) But that first contribution, even with the help of AI, is frequently “slop”, because they don’t have the experience to review what the AI generated. They’re submitting code they don’t fully understand, and the whole point of that learning loop is lost.

I asked the audience at both Planet Nix and SCALE how they thought new contributors should get started instead. Multiple people (as if they couldn’t even hear each other in the room) suggested the same thing: new contributors should review PRs instead of submitting them. That’s the work maintainers don’t want to do anymore, and it would teach newcomers a lot about the codebase.

But then someone pointed out that AI could help them review the PR too.

There’s another path that’s closing off too. Documentation used to be a great way for new contributors to get started. You’d contribute to docs first, learn the project, and then move on to code. (Same with localization. People started translating docs.) But now some projects are generating all their docs with AI, so they’re not even taking docs contributions anymore. That’s another getting started path that’s disappearing.

Who’s Admitting They Use AI?

One fun data point from my research: 84% of developers are now using AI tools to code, but only about 29.5% are disclosing that they used AI to help write their code. Turns out, whether or not a developer admits it depends a lot on which tool they used. If they used Claude, they’re most likely to divulge that they had AI help (80.5% disclosure rate). GitHub Copilot users? Only 9%. And that is probably at least somewhat attributable to how those tools help you. GitHub Copilot is usually in your IDE where as Claude Code is a standalone tool.

So… Is AI Killing Open Source?

No. But it is for sure changing it.

AI is creating noise. It’s corrupting some incentives. It’s changing the type of project that will be successful. Small utility libraries, for instance, might get replaced by people just asking an LLM to generate what they need. (And that was another path to maintainership.) And it’s making things more time-consuming for maintainers in the short term, even as it promises to help in the long term.

But it’s also changing the way we create software solutions, and that’s really good in many cases. 36% of developers are using AI to learn new skills. AI-assisted tools are helping some projects with triage, finding real bugs, and managing review workloads. When used right, AI really helps drive better solutions.

There’s a lot of really good data available on how AI is affecting open source. I’ve included some of it in my slides. (These were generated by Claude and are useful and editable, but kind of ugly. For a previous talk I used NotebookLM slides and they were beautiful and not editable.)

I encourage you to keep reading about how AI is affecting open source software, thinking about it, and talking to others about how we can use AI tools to make open source software processes better.

What We Need to Do

We need to make sure maintainers have tools that enable AI to help them, not just tools that generate more work for them to review. And we need to give them time to figure out how AI is affecting their projects. We already ask a lot of maintainers. 60% are unpaid. 60% have considered quitting. 44% cite burnout. And now we’ve sprung this massive technology shift on them without giving them two weeks off to go figure out what to do about it.

If we want open source to thrive in the AI era, we need to support it: fund it, contribute upstream, submit quality bug reports and PRs (whether you use AI or not), and be transparent about when and how AI helped. Good documentation helps everyone, including the AI tools, navigate your project. And take a hard look at your dependencies: understand what you depend on, reduce where you can, and support what you can’t.

This transition is far from over, and I’d love to hear your thoughts. What are you seeing in your projects? How is AI changing the way you contribute? Let’s keep talking about it, learning, and trying new things.

The post Is AI Killing Open Source Software? appeared first on STORMY PETERS.

How to Own Your One-on-Ones and Boost Your Career

2026-03-28T13:10:23Z

Your one-on-one meetings with your manager aren’t just another meeting. They’re one of the most powerful tools you have for advancing your career. And here’s the thing that might surprise you: you own those meetings, not your manager.

I know there are a lot of guides out there telling managers how to run better one-on-ones (I’ve even written one myself), but the truth is, as an employee, you have way more control over these meetings than you probably realize. So let’s talk about how you can actually take ownership and make these conversations work for you.

This post also has a video version:

Why One-on-Ones Matter More Than You Think

Think about it—your one-on-ones are where the magic happens. It’s where you make sure your goals actually align with what the organization needs. It’s where you sync up your work with everyone else’s. It’s where your manager finally understands what you’re really working on. And most importantly, it’s where you ensure your hard work gets recognized.

Without effective one-on-ones, you’re basically working in a vacuum, hoping someone notices your contributions. Don’t do that to yourself.

Step One: Prepare (Yes, Really)

I get it—preparation feels like extra work for a pretty informal conversation. But trust me on this one. Create an agenda. Even better, start a shared document that grows each week with your agenda items and meeting notes. This becomes your career documentation over time.

Start your meeting with relationship building.

Especially if you’re working remotely, take a genuine minute to connect as humans. You don’t need to share your deepest secrets—even chatting about the weather or something interesting in the news works. The point is to acknowledge that you’re both people, and establish how you communicate with each other.

The Golden Rule: Problems + Plans

Here’s where most people mess up their one-on-ones: they come with complaints but no solutions. Don’t be that person.

If you’re bringing up a problem (and you should—that’s part of your job), always come with a plan. Maybe your plan involves your manager’s help—perhaps they need to network with one of their peers or reach out to another team. That’s totally fine! Just frame it right.

Instead of: “This project is a disaster and nothing’s working.”

Try: “I’m hitting some roadblocks with this project. Here’s my plan to address them, and I could really use your help connecting with the design team. What do you think?”

You can even present options: “I’ve thought of three ways to tackle this. Which approach do you think would work best?”

What to Actually Share in Your Meetings

Progress updates that matter. Focus on what you accomplished, not just what you worked on. There’s a big difference between “I spent time on the JJ software” and “I fixed 3 bugs in the JJ software and reviewed six pull requests from other team members.”

Decision-making insights. Share the priorities you’ve set and the trade-offs you’ve made. Your manager wants to understand your thought process, especially when you’ve had to make tough choices about what to focus on.

Networking opportunities. If you need introductions or if you’ve heard about work that might interest your manager, speak up. This is one of the most valuable ways they can help you.

Industry news and internal updates. Be your manager’s eyes and ears. If you’ve heard something they should know about—whether it’s internal company news or industry trends—share it. They’ll start doing the same for you.

Team highlights (if you’re a manager as well). Always highlight people doing great work. Did someone give an amazing demo? Finish a challenging feature? Get married? Tell your manager and suggest they reach out. Everyone wins when recognition flows upward.

The Art of Asking for Feedback

Don’t ask “How am I doing?” It’s too vague and puts your manager on the spot.

Instead, get specific: “In yesterday’s review, how do you think I handled the schedule questions? What went well, and what could I do better next time?”

This makes it easy for them to give you actionable feedback in the moment, rather than trying to remember and summarize everything you’ve done lately.

Three Questions to Ask Yourself

Before every one-on-one, run through these:

Do I need help with anything? Don’t miss your opportunity to get the help you need.
Will my manager be surprised by anything? If there’s a potential issue brewing—a delayed release, a struggling team member, a client concern—give them a heads up now.
How can I help my manager? Always end by asking what you can take off their plate.

That last one is crucial. Your manager is juggling a lot, and offering to help makes you look like the collaborative team player you are. (Don’t be surprised if they don’t come up with anything right away, but they will remember you offered when opportunities come up in the future.)

The Follow-Up That Sets You Apart

Here’s what separates the pros from everyone else: follow up in writing. Take those meeting notes, clean them up, answer any outstanding questions, add relevant links, and send it all to your manager.

Whether it’s email, Slack, or your shared document, get those key points in writing. This creates a paper trail of your contributions and shows you’re serious about execution.

Making It All Work for You

Your one-on-ones are happening anyway—you might as well make them count. Use them to share your wins, communicate your strategic thinking, get the help you need, and position yourself as someone who thinks beyond just their immediate tasks.

Remember, you’re not just reporting what happened last week. You’re actively managing your career, building relationships, and ensuring your work has the impact it deserves.

The managers who get promoted, the employees who get recognized, the people who seem to always be in the know—they’re not necessarily smarter or more talented than you. They’re just better at owning their one-on-ones.

So take control of that calendar invite. Come prepared. Bring solutions, not just problems. And always ask how you can help.

Your future self will thank you.

The post How to Own Your One-on-Ones and Boost Your Career appeared first on STORMY PETERS.

Is AI Killing Online Collaboration? The Decline of Stack Overflow, Wikipedia, and What It Means for Open Source

2026-03-28T13:11:09Z

Participation in online collaborative sites is decreasing, and the numbers are striking. Matt Asay recently wrote an article about how there are fewer people asking questions on Stack Overflow. If you look at December 2023 to December 2024, the number of questions that were asked dropped by 40%.

You can watch the video version of this article on YouTube.

Since ChatGPT has been released, he pointed out in 2023, there’s been this dramatic decline in the number of questions asked on Stack Overflow. However, the number of questions asked on Stack Overflow has been dropping since 2018, as shown in the graph. Perhaps there’s something else also going on.

The Wikipedia Connection

In the comments of this article, somebody wrote that Wikipedia was also seeing a drastic drop in the number of people reading articles on Wikipedia. They proved this by showing a graph that demonstrated a larger percentage of internet users were using ChatGPT than using Wikipedia.

This assumes more people are going to ChatGPT to get an answer than are looking it up on Wikipedia. This raised the question of whether fewer people contributing to these tools. If fewer people are asking questions or looking for answers there, does that mean contribution goes down?

Stack Overflow’s Model and Declining Contributions

Starting with Stack Overflow, I don’t have exact numbers, but I think you could probably make a reasonable argument that this would be true because of Stack Overflow’s model. Stack Overflow works by having people ask questions and others answer them. So if you have fewer questions, you probably have fewer answers.

Wikipedia: A Different Story

If you look at Wikipedia, I think it’s a little more complicated than that because of the way that Wikipedia rewards contributions. I went to Wikipedia’s metrics site to examine the percentage of users contributing to Wikipedia.

The growth rate has been flat for the last couple of years, which is interesting. But it hasn’t dropped off like we saw in Stack Overflow. It’s been flat since 2018 again, suggesting there’s something else other than just AI going on there.

But at least the fewer people reading Wikipedia has not caused fewer contributions to Wikipedia, although maybe it has stalled the growth rate. It’s unclear from this graph and unclear from the data that I have.

Why Wikipedia is Different

I think it’s because Wikipedia’s model is very different. Wikipedia doesn’t publish how many people read your answer, and doesn’t reward you in numbers like Stack Overflow or YouTube does.

Instead, Wikipedia’s contributors are probably more motivated by seeing articles completed, or how many articles they wrote for the community that they’re participating in, or the community of contributors that they have.

So it seems like a drop in the number of people reading the article would have a less direct impact on people contributing to the article.

The Financial Impact

Now Wikipedia did go through an effort recently to move from getting most of their financial contributions from companies to getting most of their financial contributions from readers. And so ultimately, if there were fewer readers, you could imagine that Wikipedia’s Wikimedia Foundation would be affected and that would affect contributors eventually.

What About Open Source Software?

Now, does the Stack Overflow and Wikipedia trend, if they’re accurate, this decline in people asking questions and reading articles, does that relate to open source software?

In the open source software world, I thought this would relate to people using the software. So I thought what we would want to look at is the number of people downloading packages like software ready to consume.

The NPM Data

I went to NPM, a package manager, and looked at the statistics for the top projects on NPM. There is not a dramatic decline in the number of people downloading packages from NPM.

You could argue that the number of users of open source software, the number of people that download the software to use, would fall much later after people have stopped contributing because the software is still very useful as it is. People don’t need changes. And so if people stopped contributing to open source software, there might be some kind of delay.

Looking for Better Metrics

A better intermediate metric might be how many views of the code we had. How many people went and looked at the code to learn from it? Did they learn from Copilot or ChatGPT or Claude instead of going to the code to look at it?

We don’t have really good data on the number of views of open source software, and we have statistics like stars that we can see if people liked it or not.

The Big Questions

Do you believe the Stack Overflow and Wikipedia story that there are fewer users and readers of their data? Does that mean that eventually there’ll be fewer contributors? If so, what does that mean for the future of open source software? Which metrics would you use to figure it out?

Let’s start a conversation—drop a note in the comments.

The post Is AI Killing Online Collaboration? The Decline of Stack Overflow, Wikipedia, and What It Means for Open Source appeared first on STORMY PETERS.

Successful Open Source Software Leaders Are Great Communicators

2025-05-22T00:41:18Z

Successful open source software leaders are great communicators. I realize I’m cheating a little when I say that because I think in order to be a great communicator in the open source software space, you have to be technical, you have to be authentic, you have to be passionate, you have to delegate, you know, build community. But I think all of those are part of being a good communicator. And it’s the communication that’s key.

You can watch the video version of this post:

Let me give you a couple of examples.

Evan You: Clear Communication from Day One

Let’s look at Evan You who created Vue. I would say from the very beginning he showed that he is a great communicator. He wrote a really clear and thoughtful blog post explaining why he created Vue, and it was written in a way that really invited discussion.

He went on to keep really well reasoned release notes and roadmap updates, always in a style that’s very transparent and non-defensive.

He did this with authenticity. He leads quietly and humbly, he lets the project speak for itself, but his passion shows through. He wanted to create Vue because he wanted to build something elegant, and he’s focused on the developer experience.

And he’s shown that he can delegate through how he communicates, both by inviting the feedback that he does, and also by empowering people to lead the ecosystem, people such as Sarah Drasner.

He doesn’t cling to control. He communicates very clearly on technical topics with authenticity, passion and a community building aspect.

Linus Torvalds: The Controversial Communicator

The next example may be a little more controversial. I am going to say that Linus Torvalds is a great communicator. He started out the project with some really good documentation. The README and Git documentation that he wrote were really direct and very reasonable, very new for the time. That wasn’t the style at the time.

And I would argue that even his rants are really clear and technically rigorous. I would not say that they are effective, but he is very authentic in all of his communication, love them or hate them. It’s brutally authentic. He is obviously passionate. He’s continued to work on the Linux kernel for decades and shown a deep commitment to it. And he delegates. He created the Linux subsystem maintainer model, which is a model that many open source software projects have copied since then.

He is a good communicator when he wants to be, with very technical background, very authentic, very passionate. And he delegates, created the delegation model that many projects use.

Kelsey Hightower: Breaking Down Complexity

The next example definitely is not as controversial. I don’t think anybody would argue with me when I say that Kelsey Hightower is an awesome communicator. He is famous for breaking down really complex infrastructure in the Kubernetes space into something that’s very relatable for a wide audience, and even makes it fun.

He’s very authentic. He shares things about how he grew up without a traditional tech background. He shares failures as well as wins. He’s super passionate. You can tell that he loves what he’s talking about.

And he also really loves growing other people and empowering other people. You can feel his enthusiasm as he’s talking about his topics. And he’s really good at growing the community around him. He’s known for talking about making himself replaceable. He’s also really well known for being a mentor and for helping early career developers grow around him.

Definitely an extremely good communicator, but also very technical, authentic, passionate and dedicated to growing others.

Selena Deckelmann: Cross-Community Communication

The next example I also think is not controversial. If you look at Selena Deckelmann, she’s now the CTO of the Wikimedia Foundation, but a long time Postgres contributor.

She communicates really clearly across technical and non-technical communities. She started out on Postgres, talking about transparency and governance and using product focus stories to tell the technical side of Postgres.

And now she’s at Wikimedia talking about Wikimedia infrastructure and values in a way that the public can understand.

Very technical, very authentic. If you met her and talked to her, you feel that personal honesty and she shares successes and leadership changes openly. She’s very passionate. She’s committed to open knowledge and Postgres and it comes across in her communications. And she also delegates.

She inherited the Wikimedia model, but she’s definitely leading large teams through decentralized decision making and encouraging volunteers to lead things. A very good communicator across technical and non-technical communities, very authentic, very passionate, and definitely works in a very distributed, delegated model.

Deb Nicholson: Bridging Policy and Community

Next example of a great open source software leader who demonstrates that they have great communication skills is Deb Nicholson. She’s the Executive Director of the Python Software Foundation, and a long time free software community member and contributor.

In her communications, she often bridges legal, community, and policy issues with a lot of clarity and conviction, which shows she understands the technical aspects of the topic she’s discussing, and she translates that big picture strategy into things that the community can act on.

She’s very authentic. She talks about the challenges of community building, and she talks a lot about ethics and issues facing us in the world in politics and tech in a way that genuinely comes from her without any spin. She’s very passionate. She has a long track record of working on open source software licensing, on governance, on software freedom.

She’s developed participatory leadership systems in organizations such as the Python Software Foundation and the Software Freedom Conservancy that have this delegation, community building aspect to it.

Five Examples of Communication Excellence

There are five examples of open source software leaders that demonstrate that open source software leaders have great communication skills.

I would love to hear what you think in the comments, either about Evan You, Linus Torvalds, Selina Deckelmann, Kelsey Hightower, or Deb Nicholson or any other leaders that show that open source software leaders have great communication skills. And it’s a key part of being a successful open source software leader or maintainer.

The post Successful Open Source Software Leaders Are Great Communicators appeared first on STORMY PETERS.

Why AI Is Actually Helping New Coders!

2025-05-15T22:59:22Z

There are two widespread beliefs about AI that I’m certain are wrong:

1. AI is not killing the role of software developer. It’s definitely changing it. It may kill open source software, but I do not believe it’s killing the role of software developer.

2. AI is not making it really hard for new developers to get started. On the contrary.

Let me explain both of these points. Here is the video with the text version below.

AI and Software Development: The Photography Analogy

When I said AI was potentially killing open source software, many people interpreted this to mean AI was killing the role of software developers. But I believe AI is to software development what the cell phone was to photography.

The Evolution of Photography

When photography first started, equipment was expensive and had a huge learning curve. You had to set it up and be stationary in one room. Very few people had access to it—you had to pay someone to do it for you.

Then came personal cameras, then point-and-shoot cameras, then cell phones with cameras in everybody’s pocket. Did photographers worry during that time? I’m sure they did. I’m sure they thought their jobs would disappear because everyone could take pictures.

Cell phone cameras have absolutely changed the way we live. We take photos and videos and share them with everybody, changing how we tell our stories. But my cell phone camera has not made me a photographer.

You would not hire me to be your baby photographer. You would not hire me to do your wedding photos. I am not a photographer, but I use photos every day.

AI Will Do the Same for Software Development

I think AI will democratize software development in the same way. Everyone will be able to use software development tools to tell computers what to do in their everyday lives. But you’ll still need software developers.

Someone needs to maintain those data centers, send satellites into space, and handle your medical treatment software. You better hope there are software developers behind that. So no, AI is not going to kill software development.

AI Actually Makes It Easier for New Developers

I don’t think AI is making it harder for new developers—quite the contrary. AI is making it easier for people to learn how to code.

The Diamond Age Reference

The story I love is from Neal Stephenson’s “The Diamond Age,” where a little girl finds an illustrated primer that teaches her how to read. I think AI is a bit like that—it’s bringing tools to people who would never have had access to them.

Democratizing Access to Learning

AI is bringing the ability to learn anything, including software development, to:

People in developing countries
Kids in rural areas
Those without access to libraries, dedicated teachers, or mentors

AI is becoming that universal teaching tool.

Learning Through AI Code

With AI, many more people will be able to learn how to code and write code. They might not be writing everything from scratch, but they’ll be creating things that direct computers to perform tasks.

Ashley Willis had a great post where she mentioned a mentor who said that reviewing AI code as a new coder is like joining a team and looking through a legacy codebase, trying to make sense of it.

Is Learning About Creating or Recreating?

This raises an important question: Is learning about creating things from scratch, or is it about recreating and copying things that already exist? I think it’s probably a bit of both.

Looking at careers like architecture or art—in any career, you start by trying to recreate and understand things other people have created before you go on to create something new.

New coders will tell AI to do something, then try to understand how it did it in order to change and improve it.

Historical Parallels

We can look at examples like putting a camera in every pocket and what that did to photography. We can look at the printing press and what it did to learning around the world. Yes, some careers change and evolve, but the fundamental skills remain valuable.

AI is not killing software development careers, and it’s not making it harder for new developers. It’s actually making it easier and bringing coding to many more people.

The post Why AI Is Actually Helping New Coders! appeared first on STORMY PETERS.

What is Open Source AI? Why It Matters and Where We’re Headed

2025-05-14T19:16:14Z

The debate over open source AI continues to rage after years of discussion. Despite all the arguments, we still don’t have clear answers about what open source AI actually means, why it matters, or how to make it work.

Let’s examine the different definitions, the challenges we face, and what history teaches us about navigating this complex landscape.

This was originally posted as a daily walk, share, and discuss video. The written version is below.

A Brief History of Open Source

To understand open source AI, we need to look back at how open source software began. Free software was built on four fundamental freedoms: the ability to use software, examine and learn from it, modify it, and redistribute it.

We used copyright law to make these freedoms enforceable. But here’s the problem: copyright law was designed for books, letters, and written works. Later it expanded to cover art and movies. Applying it to software was already a stretch.

Now we’re trying to apply copyright law—created for simple written works—to AI systems that include datasets, training software, model weights, and complex algorithms. It’s like using a hammer to work with microchips.

Why Open Source AI Matters

This complexity doesn’t make open source AI less important. We’re using AI everywhere—from camera stabilization to major business decisions. We need to understand and trust the systems we depend on.

The EU AI Act recognizes this importance by creating specific provisions for open source AI. But these regulations also create new challenges about how we define and implement open source AI principles.

Three Approaches to Defining Open Source AI

Definitions of open source AI vary widely, but they generally fall into three categories:

1. The Model-Only Approach

This view says you can tweak, retrain, and redistribute the AI model itself—but not necessarily access the original training data or software.

Critics argue this isn’t enough. Without access to the training process, you can’t truly examine how the model was created, whether you can trust it, or how it handles your data. Some also claim this approach just enables free community product management for large AI companies.

2. The Everything-Included Approach

This definition requires access to everything needed to recreate an AI model: all training data, the training software, original weights, and all components.

Hardcore advocates of free software push for this approach, and I appreciate their position. But the reality is complicated. AI models are becoming almost like people—could you recreate a person even if you had their DNA, knew their upbringing, and could somehow model every random encounter they’ve had? The complexity is staggering.

Still, this level of transparency is something we should strive for.

3. The Apply-Licenses-Everywhere Approach

This camp argues we don’t need new models or licenses—just apply existing open source licenses to every AI component: data, training software, models, weights, everything.

I think this approach is naive. Open source licenses were built on copyright law, which doesn’t translate easily to all components of AI systems.

Lessons from History

Looking at open source software’s original four freedoms—use, learn, modify, distribute—none explicitly mention collaboration. Yet collaboration became central to open source through maintainers, committers, pull requests, and community culture.

Similarly, AI is evolving into something we don’t fully understand yet. Open source AI will likely create new forms of collaboration we can’t predict. What if AI models themselves become contributors to other AI models?

The Software-as-a-Service Parallel

History offers another lesson through Software-as-a-Service (SaaS). When SaaS emerged, the open source community worried it would create a loophole. Companies could take open source software, modify it on their servers, and serve it to users without sharing their modifications back to the community.

The AGPL license was created to address this, requiring companies using software as a service to provide source code. But the AGPL never really succeeded. Different variations emerged, the problem persisted, yet SaaS didn’t kill open source as feared.

Today, 90% of the world’s software still contains open source components. We didn’t solve the SaaS challenge perfectly, but open source adapted and thrived anyway.

The Challenge Ahead

Open source AI faces similar adaptation challenges. We might not get the definition right immediately, and that’s okay—but we need to stay flexible and understand our goals.

The EU AI Act creates additional complexity by carving out exceptions for open source AI while simultaneously restricting what high-risk AI systems can be used for. This creates a catch-22: open source software traditionally doesn’t restrict use cases (that’s a core freedom), but AI regulations do impose restrictions.

We’re trying to define what AI is, how it can be used, and what responsibilities come with it—all while still figuring out what open source AI means.

Moving Forward Together

The Open Source Initiative’s process of defining open source AI generated significant controversy and disagreement. These arguments are valuable for sharing ideas and considering different perspectives.

But more importantly, we need to clarify our goals for open source AI. What are we really trying to accomplish? Is it:

Ensuring we can trust AI systems?
Protecting privacy in AI training data?
Knowing what data was used for training?
Understanding if our data was included?
Creating collaborative models like we have in open source software?
Something else entirely?

What’s Your Definition?

The conversation about open source AI is far from over. We need continued dialogue about what open source AI should be and why it matters.

What’s your definition of open source AI? What aspects are most important to you? How do you think we should balance transparency, accessibility, collaboration, and practical implementation?

These questions don’t have easy answers, but they’re worth wrestling with as we shape the future of AI development.

The post What is Open Source AI? Why It Matters and Where We’re Headed appeared first on STORMY PETERS.

In order to grow your volunteer community, you must work in the open

2025-05-14T20:38:05Z

Doing research for my Grow an Organization by Planting Volunteers at SCALE, I ran across Dirk Riehle’s article on the Five Stages of Open Source Volunteering. The whole article is worth a read but I thought I’d call out the open communication piece. He says to support a distributed community and to engage new volunteers, open communication is key.

Public communication ensures that all members of the community have the opportunity to participate, which creates buy-in and trust.

Dirk Riehle outlines 4 principles of open communication:

Public. All communication should be public and not take place behind closed doors; any private side-communication is discouraged.

Written. All communication should be in written form; if this is not possible, any relevant communication should be transcribed or summarized in writing.

Complete. Communication should be comprehensive and to the extent possible, complete. Assumptions are made explicit and key conclusions are summarized.

Archived. All communication should get archived for search and later public review. Thus, previous conversations are available for posterity.

The benefits he lists are some of the same reasons I gave in my Asynchronous vs Synchronous post. It enables distributed work, people whose first language is not English have more time to read and understand, it gives a common understanding and increases transparency around decision making.

Reading it, I was struck that this is not how I am starting projects at Mozilla these days. We have many ideas for things we can do in 2015 and usually we discuss them as a small group, decide whether or not they are viable, figure out if it needs a budget, whether it moves our 2015 goals ahead and then we bring the topic to a wider, more public audience. There are several reasons for that. One is that it takes time to figure out how to accurately describe an idea, what you mean and why you want to do it. It helps to get feedback from a few people to help make your initial communication clearer. Another is that we don’t want to be seen as announcing things before we are committed to them. I’m not sure if that’s a valid concern or not. Third is that it feels distracting. All of us are suffering from too much email, too much information and too much communication. Adding random ideas seems to create more churn. I wonder if this could be solved by having people focus more on smaller projects. Right now it feels like we all have to follow most of what Mozilla is doing because we are part of Mozilla. Everyone wants to know about Firefox OS and tiles and privacy. I do!

The post In order to grow your volunteer community, you must work in the open appeared first on STORMY PETERS.

AI is Killing Open Source Software

2025-05-14T14:40:59Z

AI is killing open source software. If we act now, it won’t do away with collaborative software development, but I do think it is changing open source software as we know it.

This was originally posted on YouTube as my daily walk, think and share. Below is the transcription.

Two recent events highlight why change is coming to open source software and why we should pay attention.

The $3 Billion Signal

OpenAI offered to buy Windsurf, an AI-powered software development tool, for $3 billion. That’s a lot of money for a software development tool, especially when OpenAI already builds AI tools and could develop their own. This signals that there’s significant money in AI-powered software development right now.

The “Not Dead” Disclaimer

Articles keep appearing—including from GitHub’s CEO—insisting that software development isn’t dead as a career. The fact that people feel the need to make this argument suggests AI is changing the profession enough to worry people about their future.

When a company pays $3 billion for what’s reportedly their second choice (they wanted Cursor first), and industry leaders repeatedly assure us that developers aren’t going away, the career and industry are clearly changing.

Since open source software is part of this industry, it will change too. And I think the change will be significant.

A Lesson from Architecture

History offers a useful parallel. Architects once spent their days at drafting boards, creating detailed building plans by hand. Drawing was the core of their work.

Then CAD software arrived in the 1980s. AutoCAD and similar tools could generate these drawings automatically. The architect’s role transformed completely. Instead of drawing all day, they focused on design, planning, and problem-solving at the computer.

Some architects welcomed this change, especially if they found drafting tedious. Others missed the hands-on craftsmanship that drew them to the profession.

The Same Thing Is Happening to Software Development

Software development is undergoing a similar transformation. Developers use AI to write code and solve familiar problems.

A CTO at a small startup told me he loves AI tools because they let him build prototypes and reach market faster. But he no longer writes code or algorithms or figures out solutions himself. Instead, he directs the AI tool like a project manager or architect.

This resembles what happens to successful open source developers. They start by writing useful code, but as others join their project, they gradually shift from coding to reviewing code, setting direction, and planning architecture.

AI is doing to all software developers what success does to open source developers—it turns them into maintainers.

What This Means for Open Source

If developers are becoming maintainers, what happens to open source software?

AI typically chooses which software and dependencies to use in a project. It selects the open source libraries. When problems arise, AI generates the fixes.

Will AI submit pull requests when it fixes bugs? This might actually improve things—AI could write better documentation, clearer comments, and more complete bug reports.

If projects also use AI for reviews, we’ll have AI contributing to AI-managed projects.

The 10-Second Problem

But AI’s speed might discourage contribution altogether. If AI can create software in 10-15 seconds, will anyone bother sharing that code? Why create a project when the next developer can generate the same solution just as quickly?

When I use AI for projects now, it responds so fast it seems impossible it could have processed my input properly. I dismiss these quick solutions because they feel valueless—why share something when everyone has equal access to generate it?

What We Need to Figure Out

If we want open source software and collaborative development to survive, we need to understand what collaboration means when AI provides answers instantly.

What should we share? The problems we want to solve? Our approaches to solving them? More complete software upfront? Should we distribute software freely even if the code matters less than before?

These questions need answers as software development changes around us.

What do you think? Drop your thoughts in the comments below.

The post AI is Killing Open Source Software appeared first on STORMY PETERS.

Will AI coding assistants change open source software?

2025-04-23T20:39:53Z

I’m curious how AI coding assistants will change open source software development. If I write software with an AI coding assistant, am I more or less likely to use open source software solutions? Am I more or less inclined to make it into an open source software project than I would have before AI?

The first concern with AI coding assistants is that we’ll end up with many variations of the same code snippets, all being maintained separately. The anti-open source model.

Creating vs. Collaborating

When you use an AI tool to solve a problem, sometimes the AI recommends an existing open source library or framework, but often it just helps write code to solve the specific problem presented to it. This is a pattern I’ve already seen in open source adoption.

Developers initially just want code to solve the immediate problem

When developers first encounter open source software, they are often just looking for a quick solution to their immediate problem. They often copy and paste code directly into their software, whether they find the code on Stack Overflow or GitHub. They are looking to solve their problem, not collaborate.

For example, I was helping a very large software company more effectively manage their open source software usage. They had discovered that they had over 70 copies of the source code of a popular open source software project embedded in their source code. Over 70 times, a developer at their organization had gone looking for an existing solution to a software problem, found this open source software package, and copy and pasted the code as a starting point.

It wasn’t a licensing problem – the license permitted this use. It wasn’t necessarily a maintenance problem either – while inefficient, there was nothing technically wrong with each developer having their own copy tailored to their specific needs.

It was, however, a significant security problem. If a vulnerability was ever discovered in that code, they would have no easy way to (a) know about it or (b) deploy fixes across all instances.

Missing the Real Benefits of Open Source

What this approach meant was that they were only getting one benefit of open source: saving initial development costs. They missed out on:

Security
Ongoing maintenance
Community-driven enhancements

From an open source perspective, all of those teams should have been using the upstream version and tracking their dependency on it. Any needed changes should have been submitted as pull requests and coordinated with the original maintainers.

AI as an Amplifier

AI coding tools are making this even easier. They are helping you create a solution to your problem very quickly, building on decades of best practices. Your solution will likely look like many, many other solutions that have been written. This is good – it’ll likely work!

The AI Dilemma

I’m worried that AI is amplifying this pattern across all our software. For example, if you are trying to handle HTML events, will your AI tool recommend using jQuery, or will it just help you write code that does what jQuery already does? At the moment, I think we are getting some of both.

Who will contribute to open source?

As we increasingly rely on AI coding assistants, are we creating more isolated code islands rather than building collaborative bridges? Who will contribute changes back upstream when AI generates solutions? Me or the AI?

How has your interaction with open source software projects changed since you started using AI coding assistants?

The post Will AI coding assistants change open source software? appeared first on STORMY PETERS.

OSPOs for Good: The United Nations encourages open source software

2025-04-04T20:46:01Z

The United Nations is encouraging the use of open source. They see the value of open source software in helping with digital transformation, providing equitable access to technology, and accomplishing the world’s Sustainable Development Goals (SDGs).

Last year they had an OSPOs for Good event, and the event went so well that this year it will be a week long UN Open Source Week 2025. In addition to the OSPO for Good day, they have added several other events including a 2 day hackathon for real world social good, “UN TECHover”. This builds on the success they’ve seen with hackathons.

At last year’s OSPO for Good, numerous hackathons spoke about their positive experience:

Reboot the Earth, partnership between the Office of Information and Communications Technology, United Nations, the Digital Public Good Alliance and Salesforce. It’s been held since 2019. Last year, they held 5 hackathons, 4 in geographical locations plus one virtual. Young people are working on solutions to solve some of our biggest climate change challenges.
The TED AI conference in San Francisco included an open source hackathon focused on SDGs. They had 30 teams that submitted over 90 proposals.
The Cloud Native Hack at KubeCon in Paris had 13,000 developers focused on UN Sustainable Development Goals (SDGs).

You can watch last year’s OSPO for Good talks. One of the talks I found very inspiring was Philip Thigo, MBS‘s talk about how open source software brought financial inclusion (mobile money) and mapping (OpenStreetMap) and the software industry to Kenya. It enables kids without university degrees in the Global South to learn to code and to participate in building collaborative software with the world.

One of the requests from last year’s event was a UN manifesto that would allow individuals and other organizations to rally behind and express support. They recently posted the United Nations Open Source Principles. The OSI was the first organization to endorse them.

You can read a report of last year’s event or sign up for this year’s.

The post OSPOs for Good: The United Nations encourages open source software appeared first on STORMY PETERS.