What would be an example of a well-designed, useful feature that doesn’t mesh with the philosophy of the project?
Anything that falls outside the intended scope of the project.
An open-source maintainer's guide to saying “no”
61–70 of 95 posts
Re: An open-source maintainer's guide to saying “no”
#62Hm, my first though is > A user proposes a new feature. It’s well-designed, useful, and has no obvious technical flaws. And yet, the answer is “no.” Why? If it is well-designed, useful, and has no obvious technical flaws, why shouldn't it be included in open source software. > This work has gotten exponentially harder in the age of LLMs. Maybe that is more of the problem. But that's probably not really "well-designed…
> Why? If it is well-designed, useful, and has no obvious technical flaws, why shouldn't it be included in open source software In my experience, there is a subset of open source projects where contributions are theoretically accepted, but in practice the maintainer doesn’t actually want to accept anything from anyone else unless it’s something they’ve asked for. They view contributors as assistants who are willing t…
> Where it starts to get frustrating is if they throw a fit when someone forks their open source project, or when they start rejecting PRs from other people but then lightly rewriting the code and resubmitting it as their own work.
Agreed, that's horrible. I would absolutely give credit at least for the idea behind even heavily rewritten code. And the freedom to fork is one of the essential freedoms of FOSS. Many people in certain organizations (cough GNOME cough RedHat cough) don't seem to get this. Typically the same ones who overlook key parts of the OSI definition:
> The license must not discriminate against any person or group of persons.
> The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.
Re: An open-source maintainer's guide to saying “no”
#63I’ve had some experience developing an infrastructure-level system for use around the world. I had to maintain it, almost completely alone, for ten years, before it was taken over by a competent team, and I could finally walk away. One of the most important things I did, in that decade, was say “no” a lot. Some folks were not happy about it, and Godwin’s Law was invoked on my ass, multiple times. A lot of requests we…
> I had to maintain it, almost completely alone, for ten years, before it was taken over by a competent team, and I could finally walk away. No you didn't. Younger folks reading this, you don't owe anyone free labor. If you want to donate your time to open source that's ok but just know there are thousands of people in this industry that don't care about your mental health and will continue to take advantage of you b…
I get the impression the OP isn’t saying they “had to” in the sense of “being forced to by outside forces” but rather “wanted to for personal satisfaction and pride”. I understand the feeling: you create something you’re proud of and which means a lot to you, and before you let it go you want to ensure it’s in good competent hands which will care for it and make it flourish the same way you would.
That is very different from being exploited or taken advantage of.
Re: An open-source maintainer's guide to saying “no”
#64Earlier quoted context omitted.
sometimes people have a strong vision for the code they maintain. in those cases they'll usually more happily accept issues, rather than code. but GitHub doesn't let you turn off prs...
It's hard to know without looking at the datails, but in this case it would have been nice to add in the commit > Thanks to @whoever for reporting the bug and providing a fix prototype. (Probably prototype is not the correct word, but something like that.)
> (Probably prototype is not the correct word, but something like that.)
"... and suggesting a fix that inspired the actual change."
Re: An open-source maintainer's guide to saying “no”
#65I strongly disagree with the premise of the article and content being reiterated here by a number of commenters. An incredibly common pattern is a maintainer thinking they know better in an area they are inexperienced in, and rejecting change because they don't like the sound of something or are unable to see past their cultural biases. We know this by another name - not invented here . Common, practical areas this o…
I used to think the same way. Why does xyz developer refuse to do this? Don't they know that feature will be of great use to people like me?
Then I made something for myself. It took a lot of time and iterations because my needs were evolving. After it was perfectly tuned for me, I put it out there so someone else can find it useful directly or indirectly.
I started receiving feature requests and changes. I accepted a few, but rejected a a lot. This is mine. I made it for myself. I didn't step out there to build something for the world, I made it for myself and it was perfect for myself. If someone wants my stuff to do things their way and not mine, they're completely free to do so, that's why I shared it.
If I put my paintings out there and the steps I took to draw it, people are free to follow those steps and recreate mine or do it in their own way. You don't demand changes on my original painting.
Re: An open-source maintainer's guide to saying “no”
#66My pet peeve is people who use LLMs to generate code, never check whether it works, and then submit a PR. As if open-source maintainers don't have enough chores.
It's not rare for me to ask if they tested it. They can lie, but if they say they did and it crashes on me right when I start it, then I may never trust this contributor ever again. Also I don't hesitate to be frank in my review, it's okay to say "I won't merge your feature because I don't think I can maintain that, but you're free to keep your fork". Or "I can merge it if you change this and this", but in that case…
> They can lie, but if they say they did and it crashes on me right when I start it, then I may never trust this contributor ever again.
If it’s obvious without a shadow of a doubt that someone has lied, either on an issue or a PR, I’m very much inclined to block them. I have a lot of patience for people who are still learning or make silly mistakes but are genuinely making an effort; but if someone doesn’t even help me help them, that’s disrespectful and such behaviour shouldn’t be rewarded.
Re: An open-source maintainer's guide to saying “no”
#67Earlier quoted context omitted.
> I had to maintain it, almost completely alone, for ten years, before it was taken over by a competent team, and I could finally walk away. No you didn't. Younger folks reading this, you don't owe anyone free labor. If you want to donate your time to open source that's ok but just know there are thousands of people in this industry that don't care about your mental health and will continue to take advantage of you b…
Sometimes, we do stuff for reasons that folks, these days, can't relate to. I'm truly sorry that you've never had a Cause to which you could dedicate that kind of effort. No one ever "took advantage" of me. I'm actually kind of hard to hoodwink. Yes, I did "have to." If I have to explain, you wouldn't understand.
I think folks these days can relate just fine. That particular guy a bit less so.
Re: An open-source maintainer's guide to saying “no”
#68Earlier quoted context omitted.
I agree with the quoted commenter's point that sometimes shit matters enough to put up with the suck, but I also agree with your point that people need to understand that walking away might be the right thing to do. Finding that balance can be very hard.
This is true. I knew what I was getting into. I didn't expect it to be ten years, but I did expect at least five, before I could get folks to pitch in. I knew the character of the folks that would be trying to force the system into shapes that would not last, and how they would react to me. In this case, it was for an organization that I've been involved in, for decades. I'm incredibly Grateful for what it's done for…
can you share what system is it ? is it public ?
Re: An open-source maintainer's guide to saying “no”
#69Earlier quoted context omitted.
This is true. I knew what I was getting into. I didn't expect it to be ten years, but I did expect at least five, before I could get folks to pitch in. I knew the character of the folks that would be trying to force the system into shapes that would not last, and how they would react to me. In this case, it was for an organization that I've been involved in, for decades. I'm incredibly Grateful for what it's done for…
can you share what system is it ? is it public ?
I don’t really mention it in public, but it’s no secret. It’s managed by a team, these days, and it’s not really appropriate for me to draw much attention to my role. They are doing a great job.
It is public.
Happy to share it one-on-one.
Re: An open-source maintainer's guide to saying “no”
#70Given how many improvements are ignored or rejected in so many of the open source projects, it doesn't seem like "one of the hardest parts" is hard at all.
Especially when "burden of proof is on the contributor, never the repo" and the repo is hiding behind immeasurable principles such as "ultimate success of a project isn’t measured by the number of features it has, but by the coherence of its vision and whether it finds resonance with its users." with the perfect example
> This threat can take many forms. The most obvious is a feature that’s wildly out of scope, like a request to add a GUI to a CLI tool
Indeed, a threat to the project that can transform a niche tool into a widely used one of at least reduce the usability barriers for a wider user base. Shoo the "incoherent vision" of a drive by Trojan horse bearing gui contribution gifts!
> there is a significant transfer of responsibility when a PR is merged. ... maintainer who is suddenly on the hook for it.
> we’ve introduced and documented the contrib
Oh, so all you had to do to get off the hook was add a comment that you're not responsible?