In any event, he's not fixing your issue yet because he has limited free time and, apparently, has issues of his own to fix.
I thought the "thanks for the hug, HN" comment was unrelated.
EDIT: It now says "(link)" in front of it. Not sure whether that's new or I just overlooked it.
Clever thought. That didn't occur to me.
Even at a very cheap rate that quickly adds up to way more than most people are willing to give...
Even a relatively minor issue that could be fixed in a few hours would cost hundreds of dollars.
- If I don't have the time or interest to support the project any longer I agree to reach out to trusted contributors and give them commit rights, or put a clear notice on the readme: "This project is not actively maintained" so users can make an informed choice
The only sensible solution here is to bring on regular contributors as repository owners and spread the responsibility.
If I fork a project, resolve all the issues, and make it better, faster, etc, there's not a mechanism for those users to pick up my fork unless they actively go looking for it.
I think many of those package managers would be well-served to have a 301-like redirect saying "deprecated, but continued over in this new package"
Beside there are things doing just that for you. Like varnish.
This link seems to work for now.
working cached copy: https://archive.is/t9oKw
Sorry about my poor devops skills, everyone.
http://www.michaelbromley.co.uk/api/wp-json/posts/529 Error establishing a database connection
Anyway, thanks to Bing's cache: https://archive.is/t9oKw
In some cases, however, it can also attract poor quality patches from contractors working on gigs, and make life hell for the maintainers. I personally prefer if people contract me directly (as the project/component maintainer).
Tangential anecdote: a while back I helped maintain a caching module for a CMS. I was once asked by a user to look into the performance problems of their website. They were a big media company from the Middle East. I had no idea they used my module, which was usually for small websites on cheap hosting. Their contractors had enabled every possible caching module in the world. I basically disabled a few modules, including mine, tweaked their Varnish config, and things ran smoothly afterwards.
Since mostly an issue is nothing but. Even if it won't get fixed (directly).
Also some people in Open Source are akward. They tell me that they have limited resources in their project and they can't fix it or won't fix it or whatever. They don't even think that I could try to fix my own issue. They better start a conversation that they have too less people and that this particular issue will be closed. They don't even care if you've done some open source contributions already (even minor one's) on another project / language.
It's like some people just don't want your help, even if they told you.
If you don't like that you'll then have to include the original author's future changes in yours, then, well, you're doing just what he was - not wanting to spend time managing other people's things.
Even then though, if they don't have time to test it themselves in another project then they could end up breaking a lot of people's projects down the line. So they might not have the time to test and so can't even merge a PR.
FOSS developers shouldn't feel guilty or responsible in the slightest for their users unless their users' success is part of the developers' lifelong goals. For instance, protecting liberty by making sure Tor and GPG work properly. Otherwise, screw them if they want something done but won't contribute anything back.
I fail to see why this is on hacker news in the first place? Is this a demonstration of some web developers failing in new creative ways? (I saw some other interactive CV stuff that was also not only buggy but also just creative in a _bad_ way few days before...)
And oh yeah, if this is supposed to be some kind of "recruiting" tool to advocate the creator of the website in question.. If I was the recruiter, I would consider this website against him. Just my 2 € cents.
This is however the money shot:
>> how many parts of your company’s product are coupled to the lifestyle and priorities of some lone, unpaid package maintainer? It’s something I have to think about too – in my day-job I build software on top of many FOSS libraries, many of which are probably maintained by people in similar circumstances to my own.
Given that my day job builds on (last count) 953 npm packages, most of which are probably different authors, not to mention servers, backend etc etc, I do really worry we are finding OSS backwards.
Good luck to the OP and his young family. And perhaps GitHub can set up a "pay me a days freelance rates work for issues fixed" feature
As a maintainer of a major library myself, I completely concur with the article - while I don't have a baby, I am a long distance runner, as well as someone who directs albums of music. I also like to socialize as well, and every now and then I give talks (oftentimes traveling to give them), interview (even having excessive time lost to take home projects), and experiment with new technology or contribute to other open source projects.
I think one thing people need to do is help us help you. It saves us a lot of mental energy, as well as speeds things up. If you can, filing a pull request would be great too if you understand the parameters of the problem
"Because you are not offering me any money to fix it"
"Do you know what I like to do in that time? Unfortunately for you, the answer is not "fire up my IDE, get the build pipeline going, start a local dev server, ..
I pick my tools carefully, so that my hobby projects don't feel like work. If I have to suffer through slow tools, then they feel like work, and then what's the point in doing them? It's supposed to be fun.
So I basically use vim and bash as the IDE and shell scripts for the build pipeline. Everything works quickly and reliably, on any machine.
I realize that not every project has that luxury. But for personal projects, if it requires shitty tools, I'm just not even going to bother in the first place, and then there are no bugs to fix.
He's not lying about the role of weird build pipelines in making it harder to dive into a project (though it may not be the point he intended to make). Simplicity & repeatability yields surprising dividends.
