About six months ago, I commercialization that garnered some notice. Almost immediately after that, Hacker News featured this rather on the front page. wrote a piece about the state of open-source problematic piece of prose The title is “Fix it, Fork it, F*ck off” (censorship is my own). I think this is a great sample of where OSS is failing both 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 a point of frustration. We put a lot of work into our OSS project, and an entitled end user can be very difficult. I agree some people go over the line, but in my experience, this is less than 0.1% of complaints. It’s very 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, but 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 also 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 just 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 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 have 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.

All You Need to Know About Continuous Integration, GitHub Actions, & Sonar Cloud

How Developers Can Use DevOps - Introduction and Version Control

Debug Agent

Buy My Book

Learn on my YouTube Channel

Read My Stories

Newsletter

Follow me on Twitter

Too Long; Didn't Read

Make resilience your competitive advantage

Community Organization and Open Source Maintenance: Why Their Important

Community Organization and Open Source Maintenance: Why Their Important

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Front End Debugging Part 3: Debugging Networking Communication Issues

A Beginner's Guide Into Open-Source Research

A Beginner's Guide to Open Source Software

An Open-Source Book About the Open Source World

Are You Ready for Hacktoberfest 2022?

Front End Debugging Part 3: Debugging Networking Communication Issues

A Beginner's Guide Into Open-Source Research

A Beginner's Guide to Open Source Software

An Open-Source Book About the Open Source World

Are You Ready for Hacktoberfest 2022?

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps