Look how far we’ve come. Aggressive changes to contribution policies in open source projects, PRs no longer allowed, issues written so messily that nobody can understand them, and maintainers who read paragraph after paragraph without understanding anything, angry and burned out… It leaves the impression that open source projects have lost their importance. That’s partly true, if you judge open source contribution only by diffs and commit counts. Code is very cheap now. We need to talk more, discuss more, understand what’s going on, and know what we’re taking responsibility for.

Contribution, Once Upon a Time

I was never a very active contributor, but I got into all this by packaging applications for a Linux distribution called Pardus. I was a university student looking for something to work on, and the Pardus team was holding an event at my university. That was my first contact with the community. Someone prepares a presentation for you, a venue is arranged, distribution CDs are printed, money is spent on boards, name badges, gifts and bags, and I walked in for free and had my first conversation with these people. Then they would invite you to contribute to their open source projects or to use their products. Telling it now, I feel both emotional and a little amused. These were hard processes that took a lot of effort. But when you wanted to become a contributor for the first time, there were a few simple, unwritten principles:

flowchart TB
OS((Open Source
Contribution))

OS --> R[Taking Responsibility]
OS --> D[Holding a Domain]
OS --> M[Maintaining]

The ownership of every issue in the project you contribute to is shared within a certain hierarchy. By hierarchy I mean volunteer/employee or contributor/developer, a hierarchy based partly on money and agreements or licenses. So if there was an open issue, it was one of the best chances for a contributor to send code they had written. But the chance of that code getting into the repo depended on how familiar you were with the culture of the developers or the community developing the project. Sometimes you opened a PR right away, sometimes you announced it first and waited for the issue to be assigned to you, and sometimes you only described the solution.

Over time, the community or the project’s maintainers would notice that you were interested in certain topics. After a while you earned their trust, and they started consulting you on those topics. Sometimes they expected your input on designing and developing a new feature, sometimes on understanding problems. These topics are like domains; each could be a project, a group of projects, a part of a project, and so on.

To me, the most enjoyable part of open source contribution was being the person who maintained a certain domain. You applied the design the core developers decided on to the project you maintained. For example, depending on which audio libraries or video codecs were chosen to be supported, the XFCE desktop environment had to be compiled with the matching parameters and tested, and you were responsible for that.

Hundreds of developers were sending code changes to an umbrella project at the same time, following certain principles, a hierarchy, and certain processes. Because it made so many changes possible in a short time, it was a very valuable contribution. Code was expensive, and we were making it cheaper with a hundred contributors.

Looking at the picture from here, we can clearly see how cheap writing code has become thanks to AI tools. Code is cheap now; but the design is expensive!

Now, Explaining Matters More

Let me state where I stand. I don’t think open source software or contribution has lost its importance. But the methods and roles have definitely changed. Yes, maybe we don’t need this much manpower anymore, but we still need a captain, a puppet master, a decision maker. I don’t know how it will be in the future, but right now we do.

When I look at open source projects today, what I see is that there’s no settled infrastructure for sharing context yet. I mean a memory that holds the wiki, coding conventions, plans, discussion and operation notes, the decisions made, and future plans. Tools like Jira and Confluence aren’t useful enough for agents; like editors, they’re software built for humans. We need another solution. This is at least as important as formatters, linters, and CI/CD configurations. For example, when I discuss developing a feature with an agent, it needs to remind me why the container’s file system can’t be read-only: I store audio and video files temporarily on the file system. Or when I try to design a system assuming a file always exists on that file system, it needs to warn me that the file is tied to the session state, has a lifetime, and can’t be guaranteed to exist in certain cases. If the project supports Kubernetes and we want to support HPA, it needs to remind me what we might run into while keeping SessionState in memory. Code is cheap now; we need to explain the design to the agent and understand what the agent tells us. And that requires a shared memory. The project owners will naturally want to keep control over building such a shared memory system, but I think they may be open to these kinds of contributions if you can explain the design well before implementing a feature.

Second, I want to talk about asking questions. Asking good questions means acting like a real customer of the project, or understanding the trouble users run into while integrating the open source project. The best place for that is the project’s Discord/Slack channels. For example, I need a speech-to-text application. Since I can only hear partially, I can live with 80% word accuracy, but a 300ms delay is not acceptable for me! I don’t have good internet everywhere; could we make this application work offline? How far does the hardware allow it, what are the options, is it worth doing? Opening questions like these as tickets, together with technical solutions, is still a very valuable contribution, and as far as I can see, open source project maintainers still allow opening tickets.

Besides that, I think the old-style community meetups and face-to-face meetings I described in the first part still serve a purpose. They take time and effort, and there are geographic limits, but seeing the developer of a project you work on in front of you is a real motivation. Especially if that person doesn’t live there and came all that way to make a presentation for you.