It's not about meticulously reviewing every commit for every project that I use, obviously nobody has time for that. For me the most important part is being able to fork the project if you want to add features or are unhappy with the way the original project is going, you don't merely have to beg the maintainers to add a certain feature, you can do it yourself. And perhaps more importantly I'm not screwed if, for one reason or an other, the original maintainers decide to drop the project.
It's very important to me that emacs is open source not because I review every single commit (I don't) but because it means that I can commit a lot of time tweaking and learning the ins and outs of the editor without worrying about having to switch to a different one a few years from now when the original devs get acqui-hired by Facebook and they stop working on their project.
Y'know, there are some projects that haven't had commits for a while because they do exactly what they're supposed to do, and don't need a bunch of commits. I consider it a good thing when a project gets to the point where nobody can find any bugs and they stop adding features because it has enough of them already. I sure as hell don't want my quick, clean, elegant, productivity enhancing window manager to turn into a featuritis infected monstrosity like OpenOffice.org, after all.
---
edit: Actually, my window manager of choice has basically been abandoned by its developer several years ago, and it's still bug-free, stable, and lacking basically nothing. I finally came up with a feature enhancement I'd like it to have today, after using it for five years with no complaints or wants -- and that enhancement is really just an improvement of an existing feature.
More to the point, it's an enhancement that no window manager has, so I'm likely to need to write the code for this feature enhancement myself if I want it badly enough. I may pick up maintainership for the project to do just that.
Think about that a moment: one feature enhancement requested in have a decade, merely an extension of an already existing feature, and it's something entirely new to window managers as far as I'm aware. This thing has had no need for additional code in all that time, and it has been better as a result of all that.
I agree that as a developer of an open source project, it helps your project to be ... helpful. But at some point, after it's clear that your project is essential, you can defer some of that work to the user community.
Want that feature? Send a patch (because, yeah, that's a good feature... but I don't need it and I don't feel like writing it.)
Well, sure, but you can say, "I'm sorry, I just don't have the time to do that right now." They can then either fork the project and implement the changes themselves or better yet, step forward and ask if they can help with the maintenance of the project.
EDIT: I glossed over this part when I was reading the article, but indeed there are many open source developers who do hold this attitude:
Halliday—better known by his handle substack—takes an uncommonly hands-off approach to his work. “I have all my GitHub notification emails turned off,” he says. If someone finds a problem with his code or wants a feature added to a module he’s no longer working on, they’re free to fork his code. That is, after all, the open source way. But he doesn’t put effort into issues or pull requests for packages he considers finished. “It’s not my job to keep tabs on every little thing I wrote years or decades ago very often,” he says. “I am always busy with new projects and if I was always looking back at old projects I wouldn’t have enough time to move forward.”
I fully agree with this viewpoint and I think it's good for the overall software ecosystem if engineers did more due diligence on the packages that they use.
My experience with open source is that I find an issue, I fix it, and submit a fix, but the fix isn't good enough and the maintainers ask me to write it better, but at that point I am no longer interested since I already fixed my issue.
It is not like I'm going to start maintaining a fork over it. I am just not going to update the software or I'm just going to keep my patch in.
For me it has been a revolution. No language, framework or concept has changed my development process more in the past decade.
I have been able to contribute patches (both code and documentation) to many projects where I otherwise would have not had the time or energy to bother contributing.
Sure, my previous attitude may have been selfish, but if it took an hour to fix a bug in a library that I am using for a throwaway script, I am not going to spend another hour subscribing to mailing lists, emailing developers and then persuading them that my patch is worth merging.
In GitHub I just fork, push my patch, and notify the owner of the original repo. If he chooses to pull in the patch, that is his problem. If anyone else who is having the same problem wants to use my repo, they can do so.
I agree, it's not the only reason (being able to fork anyone's code, fix the bug, re-release and ask them to pull is a godsend), but I always dreaded visiting SourceForge.
Reviewing, testing and maintaining code takes up development time that could be used more productively. If there's something wrong with the PR (say, code style issues or mistakes) then you need to run through the cycle all over again.
The project is open source in that you're free to use it, sell it and go through its code. Open source does not, however, imply that someone must put in the work for you if you want to apply changes to the code yourself.
If you'd like a version of the project that takes pull requests, then you can always create a fork that accepts pull requests and comments. This puts the burden go testing, merging and quality control on you, but most of the work you'll be doing is what you're expecting the developers of a product to do for you anyway. If your energy pays off and your fork has less bugs, more features and becomes more popular, the original developers may turn around and cooperate with you instead.
Yes; it’s definitely less convenient to write and maintain your own software compared to having someone else do it for you.
As a project maintainer I’ve made the mistake several times of being too permissive with pull requests. Someone comes along with a feature they’re excited to add to my project. I don’t need the feature myself. They exuberantly make a PR, and I eventually merge it. Before long it turns out there’s a bunch of bugs with that feature, and the original author is gone. Do I waste my time fixing their code, for a feature I never wanted and don’t use? Or do I ignore the bugs and let the smell of low quality work waft over my code base?
These days I default to refusing most feature requests, even if they have decent PRs. I write most software for fun, or to scratch an itch. I don’t do it because I want to manage a community. If you want to add features and build a community around a project I’ve written, great. I’m happy to link to your fork in my readme.
Forking is not a symptom of failure. Maintaining a fork is sometimes just the ticket price to control your destiny.
As a user of other people's popular open-source projects, I generally lack awareness of the effort and investment of time that the maintainers put into the projects. It's always eye-opening and helpful for me to see posts like this, because I gradually take their work less for granted.
Every single feature someone accepts into a code-base comes at a cost. That feature needs to be reviewed, tested and above all maintained and deal with any possible bugs that might arise from it. Especially open source developers only have limited amounts of time to spend on something. Investing time in this feature means not being able to invest time in something else.
Accepting a feature that a few people might use, hidden away somewhere in the advanced configurations, might very well not be worth the trade-off to them, even though you personally find the feature valuable. It has nothing to do with a walled garden.
Ultimately, if this is so important to you, you have the choice to fork and maintain it yourself and carry that cost. That'll most likely be a lot of work, especially if you want to keep in sync with upstream. But it might give you a better understanding of and appreciation for the tremendous amount of work and effort that goes into projects like these. Work that goes largely unpaid.
This is pretty discouraging honestly, from the perspective of what the article calls a “fan”. I like to make small contributions to projects I use when I can, but I don’t become a core dev on any of them.
Is it really not worth the maintainers time to merge a bug fix or look at an issue I opened? Are they just doing it as “fan service”?
Genuinely, does this type of “participation” really waste more time than it saves on the whole?
That seems to be the implication of the article. I wonder if any open source maintainers can chime in.
I think this long predates github. Sure, it might be less of an issue if it's just a one off code drop - but there've been maintained open source projects LONG before github.
To me this is much more about reaching a (sub-) project size where there's no realistic way to keep up with everything you feel you ought to. The guilt of not getting around to review somebody's patch (even though that's how you got started), the guilt of not fixing a bug in code you last touched / wrote, not keeping up with subsystems you created, is profound.
I think this more likely an issue for people with personally traits that make them more likely to become maintainers.
I've seen this in companies too - the difference is that in open source it's often the "relaxation" time that's taken over by the guilt/work.
Updating docs or dependencies is part of maintaining a project. If no new features are needed the author doesn't need to do more. As a user it still shows me the maintainer is alive, uses a computer and does open source work. I have 5+ such projects. For some I wouldn't even update the dependencies but I get automated messages about security issues with dependencies so of course I'm interested it fixing that.
> many great projects have their last commit a year ago for example but everyone knows it's maintained
Vetting a maintainer is non-zero work. But it's also not all that much. Especially if said maintainer has already contributed meaningful PRs against your repository.
While you're technically correct that people don't owe anyone anything, I've often had the experience of using an open source library that was otherwise excellent, except that it had critical bugs that hadn't been patched, or that it hadn't been updated to work with the latest versions of it's dependencies. Popular repositories like this often have tens of high-quality pull-requests fixing these issues, but using them is non-trivial because you'd have to merge everything. These PRs pile up for a few months until someone realises that the repo is unmaintained and forks. At which point you have two versions of the project (often with the same name), and everyone is left to figure out which one they should use.
It would save everyone a lot of bother if maintainers of these repositories took half an hour to update everyone that they didn't have time to maintain the repository and pass the baton on to someone / some people who do.
> Reviewing, testing and maintaining code takes up development time that could be used more productively. If there's something wrong with the PR (say, code style issues or mistakes) then you need to run through the cycle all over again.
OK, so your argument here is that maintainer doesn't want to create CI checks because it takes time and he knows the code style and doesn't need those.
> The project is open source in that you're free to use it, sell it and go through its code. Open source does not, however, imply that someone must put in the work for you if you want to apply changes to the code yourself.
But why close yourself to others? It is like throwing mic, or as if you would mark this thread as closed and no one would be allowed to comment - antisocial behavior.
You don't need to merge PRs, but come one, if you are a sole maintainer of a project, this project is not that big, and you for sure aren't getting that many PRs.
And also, one could consider PRs because you could find another person that understands your project goals and would be your co-maintainer.
Why such strange attitude here on HN? I found this place as very open and what I see in this thread praising of close-minded people.
Most projects seek contributors not alienate them.
The overhead of working out where the people who maintain the code are is usually higher than just fixing the bug I found. This is doubly true if the bug is bad enough that I need to temporarily fork the repo to deal with it.
In the same way that the maintainers don't have an obligation to review my PR, I don't have an obligation to go find them and learn how to use IRC/bugzilla/mattermost/mailing lists/smoke signals/yodelling to communicate with them with the exact secret handshake to get a review. I can just throw a PR out there, point our code at my fork, rebase it whenever they make changes, and otherwise ignore their requirements until they either fix the bug themselves or merge my code.
Yeah, I semi-recently had to fork a library, make some big changes to get it working for us, then made an issue with the main repo basically saying "Hey I needed this and don't have time to do it properly, Here is what I did, and I ham-fistedly ripped out everything i'm not using. Look at these few files for an example of the core change that's needed. I'm willing to help work on a real solution later, but I can't right now"
The maintainer saw what I did, and was able to easily make the change so it conformed to their style, their architecture, and they worked with me later so I could make the doc changes.
I felt like that worked magnitudes better than when someone makes a big PR with a potentially controversial change and lets the maintainer decide what to do with it.
It's very important to me that emacs is open source not because I review every single commit (I don't) but because it means that I can commit a lot of time tweaking and learning the ins and outs of the editor without worrying about having to switch to a different one a few years from now when the original devs get acqui-hired by Facebook and they stop working on their project.
reply