Open Source Maintenance Is Community Organizing

About six months ago, I wrote a piece about the state of open-source commercialization that garnered some notice. Almost immediately after that, Hacker News featured a problematic piece of prose on the front page. The title is “Fix it, Fork it, F*ck off” (censorship is mine). I think this is a great sample of where OSS is failing commercially and as a movement. A lot of the attention in OSS goes into the code of conduct policies (which are important), but not enough goes into what it takes to build a successful open-source project. It isn’t just the coding. I’d argue that coding is often less important than this.

The Clash of Entitlement

I understand where the author is coming from. He’s writing from frustration. We put a lot of work into our OSS project, and an entitled end user can be difficult. I agree some people go over the line, but in my experience, this is less than 0.1% of complaints. It’s rare to have a truly toxic user.

That’s the fundamental problem I have with that post; it throws the task to the users. “Fix it yourself.” That’s the maintainer being entitled. Don’t get me wrong; it’s OK to do a code dump. But then declare it as such and let it go. Being a maintainer is something completely different.

I will support and help users who want to fix it themselves, but I get the people who don’t want to do so. I still think it’s OK for them to complain as if they paid for the software. Yes, it’s frustrating to hear complaints. But I didn’t start an open-source project just to be told how great I am. I want users to feel comfortable enough to vent; this helps me understand the pain points. It helps the authenticity of the community, and its ability to criticize me helps everyone—especially me. It draws the attention of other community members who might have a similar issue and might be more motivated to fix it. It makes me more aware of the problems and points that require improvement.

A Community Organizer

An OSS maintainer is a community organizer of sorts. A bit of a politician mixed with a project manager and benevolent dictator all rolled into one. Good managers and leaders are usually pretty nice empathetic people, most of the time. People sometimes mention a manager or OSS leader and mention what a terrible personality he has. This is nonsense. They often derived these stories from a few incidents out of thousands. A successful project starts with a patient leader. Yes, that leader might have a bad day occasionally. Or they might use language that isn’t politically correct. But the exception doesn’t make the rule, and such language doesn’t always translate as hostile.

The “myth” of an a*hole genius leader is often just that. A myth. When people like that succeed, it’s usually despite that, not because of that. Yet some people choose to push that narrative, hiding behind false “meritocracy” instead of taking accountability. Don’t take this the wrong way; I don’t think we need to walk on eggshells around everyone. I don’t think that helps, and I don’t think it solves anything either.

It’s OK to forgive a maintainer who had a bad day or did something wrong. But it probably shouldn’t be “celebrated.” Why is that? Why should I maintain an open-source project for which I might not get paid and support users?

Why do we write open-source code in the first place? We love to code. But I think we love it even more when people use our software. I enjoy cooking too, but if people don’t eat my food, it’s worse than burning it on the stove. One of my failures as a maintainer is that I overly lean on my technocratic background. I provide too much support. This often stifled the community. Why answer a question in the forum if Shai will answer right away?

The solution was to not overwhelm. I answer once a day and not faster. As a result, the community can develop its strengths. This was a version of micromanagement that applies to maintainers. It’s common for coding tasks where we tend to take up too much of the work and delegate too little.

Why This Is Important

The last time I wrote about the corporate takeover of open source. This has good elements to it but also poses many dangers. We need the community to drive this. We need maintainers who understand the work and are not bound to corporate overlords.

The big problem in any project, open source or other, is that people don’t care. Garnering community traction is something we all need. That’s how you build up a project. You might be lucky if you’re in the right place at the right time. But if you support your community, you might succeed even if you missed the boat.

This all brings me to why I “suddenly” remembered I had this post lying around in my backlog for six months garnering dust.

Should I Start a New OSS Project?

I’ve been contemplating a new type of AoT JVM that takes a radically different approach from what we have right now. This is something I want to build, but should I build it as an OSS project or start in private?

I’d like to raise funding for that, and traction from the community will help. But if I don't have an OSS project yet, the uncertainty of upcoming traction might be a better selling point to investors than the reality of currently limited traction. By its nature, a JVM project will take time to bear fruits and provide value to customers; it won’t bring a community or traction early on. So this might not be an ideal project to build in the open. I’m also not a fan of coding with people staring over my shoulder. I feel self-conscious since there are expectations about my coding skills.

I 100% want to build in the open, but I can only do that when I have something running that shows the value of the work I’m doing. This will take some time. This is very subjective. Some projects make more sense as open-source from the start.

Do We Need This New Project?

I was talking to a friend a while back and discussing my idea when he challenged me on the need for yet another JVM. Did you conduct a market study? What’s the viability of building something like that?

I don’t want to reach the point where I invest so much of my time and soul into a product that ends up in a small niche. There’s the adage: “If I had asked people what they wanted, they would have said faster horses.” It’s attributed to Henry Ford, who, as far as I know, never said that. I don’t think it would have been true, either. We need to be product-oriented even when building an open-source project.

We need to think about customer value, willingness to adapt, and market penetration even as we build something free and open-source. Before we launched LWUIT at Sun Microsystems, we spent a tremendous amount of time with potential target users. We conducted interviews and meetings and helped in the integration. The feedback we got was tremendous.

Since Codename One came from the same roots, it benefited from those roots. Still, we worked with accelerator companies to see how they worked closely. We also had an extensive early beta. It’s something pretty important for the initial traction of the project. When LWUIT was announced, we could delight the initial users with a product that was more adapted to customer needs. This helped a lot with the initial users and first customers we got for Codename One.

Finally

When we build an open-source project, we often end up doing everything. Product, DevOps, user/developer experience, etc. This is a unique experience that most companies won’t give you. I know that my experience in those other disciplines has made me a better manager and entrepreneur in the long run.

It’s a job. It doesn’t pay (at least at first), and the hours are always overtime, but it’s still a job. Because; otherwise, you’re asking other developers to trust your hobby. That’s unfair to them. Even when it’s free, we need to take the project seriously and respect our users.

Maintainers get a lot in return. We improve our skills. People are more likely to use and advocate our work, and it’s more likely to end up as a profitable endeavor. Ending up with an open-source job from our hobby project is a pretty great outcome for many side projects. It starts with being reasonably patient with people.