Hacker News Reader

Comment by bflesch | Hacker News Reader

Yeah and then your contribution gets shot down because the maintainers have a totally different vision about their product than you do.

I've contributed some security findings and UX improvements to KDE in the past year and it was quite a bad experience for me as a contributor. KDE feels like a slow organization and stakeholders have their own incentives apart from software quality.

View on HN

Any time you're planning to make a change that seems even remotely contentious or controversial, you should talk to the maintainers about it first.

You should do this even if you are a regular contributor and have a good working relationship with the maintainers.

I don't know anything about KDE's processes or culture, but I think this is (or at least should be) universal when dealing with any project. I really do not understand how anyone could just go from zero to PR without talking to a maintainer first about what they want to do, and how they want to do it.

> I really do not understand how anyone could just go from zero to PR without talking to a maintainer first about what they want to do, and how they want to do it.

I usually open a PR with at least a proof of concept implementation without prior discussion. I find that trying to discus a new feature without a concrete thing to look at often goes nowhere or even goes completely unanswered. On the other hand, with a concrete implementation to point at it's much easier to discuss direction and details and have everyone on the same page instead of talking past each other. But I realize the maintainer's vision may not align with my ideas, so I'm okay with them saying "no, we don't want this" and closing the PR outright.

> I usually open a PR with at least a proof of concept implementation without prior discussion. I find that trying to discus a new feature without a concrete thing to look at often goes nowhere or even goes completely unanswered.

You should do both: get a soft ok that they'll consider the change ("If I put up a PR/POC will you be able to take a look? Will you be able to approve? If not you then who would I reach out to?") and then put up the PR so there are concrete things to discuss. This saves you time because why put together even a POC if they're never gonna approve it.

I feel like you, and in another environment entirely, I found it's useful to make the working implementation in secret, and open the ticket as if it's a new idea and steer the conversation towards your implementation. People like to feel like things are their ideas, so if you can guide them suggest the idea to you, it'll definitely get accepted.

Personally I don't bother contributing unless I'm getting paid - otherwise I have no incentive to deal with the people bs.

People tend to think bazaar == open source, and cathedral == proprietary, and for many projects the design process is more bazaar than cathedral. But almost any large open source project is cathedral, or more like, Democratic Centralism. I guess in people's defence, these cathedral projects in the open source world tend to follow totally bespoke procedures that don't necessarily align with those of another project, so it can be a pain or intimidating to try and learn the bespoke incantations for every project you want to submit a patch to.

It's true, they do tend to think that. Which is too bad, because The Cathedral and the Bazaar has very little to say about proprietary software. esr's type-case for Cathedral development is GNU software, and the Bazaar is Linux.

FOSS is 100% determined by the license under which software is released. Several notable open source projects, Lua and SQLite leap to mind, are entirely closed-development. Others are pure anarchy, most are somewhere in the middle. The polemic which coined these terms was mainly making a case that the bazaar model is surprisingly effective and worth considering, a controversial claim in its day, but no longer so.

Honestly, the most welcoming open-source project I found was Blender. They are quite open to criticism, and follow ups are timely.

Only contributed a couple of fixes, but the experience was great overall.

Reply on news.ycombinator.com