3 ms·

“Even if you have funding, there’s always more work than you can possibly do,” Van Slyck says. “And the bar is always being raised. It used to be enough to just

“Even if you have funding, there’s always more work than you can possibly do,” Van Slyck says. “And the bar is always being raised. It used to be enough to just put some code online. Now you’re expected to foster a community. You have a lot more hats to wear.” I found this statement perplexing. Why is it no longer "just enough" to put some code online, in a take-it-or-leave-it fashion? If anything, given how easy git has made it to fork projects, it's more acceptable to do that today than it is is the old days of centralized version control. If you have the time and effort to maintain it, then great. If not, that's fine too; having some code out there to serve as the basis for future work is better than no code at all.

dkdbejwi383 5y ago
This is a perfectly reasonable position to take, however a lot of people are very needy, wanting to be handheld through support beyond a reasonable limit, or demanding that you implement x or y because they need it, and want you to do it for them for free.
- quanticle 5y ago
  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.
  - calvinmorrison 5y ago
    Which is why I always say "show me the code" or "we accept patches".
    - quanticle 5y ago
      I thought about writing "patches are welcome" as an example response, and I deliberately chose, "I'm sorry, but I just don't have time for that," instead. Reviewing a patch, in many cases, takes somewhere between 50% and 75% of the time it takes to write the code in the first place. It's not a given that someone who open sourced a random project will have time to review patches.
      - kop316 5y ago
        Personally, I much prefer "patches are welcome". It puts the ownership back on that person who asked for XYZ feature to do it. If that person is actually motivated enough to write a patch (which I have had!), I welcome reviewing it, because it empowers that person to feel like they can contribute to my project (and hopefully other projects too!), and makes others feel like they can contribute to my project as well.
        lupire 5y ago
        Patches are always welcome on your fork. Upstream can merge whenever they want.
      - meetups323 5y ago
        Hah. I regularly see patches whose review takes well over 100% the time it would have taken me to create the patch myself. But then I'm employed by $MEGA_CORP and part of the job description is "helping to build and maintain the OSS community", so helping novices create their first patches is a big part of that.
- pvorb 5y ago
  But are those bad actors really that common? Typically, what I see is that developers really know what to expect from an open source project. If you can't offer them support they could walk away looking for alternative options instead of funding your project. That's because devs usually don't have a budget to spend. They even could fork and solve their own problems without caring to support the problems of others. But I guess all of this is okay and perfectly acceptable use of open source software.
pvorb 5y ago
I agree with you. At least I've never been offended by anyone for not replying to issues raised in my repositories. And a few of my libraries are downloaded millions of times per week from NPM (which is not that uncommon on NPM, but still). That really bad support didn't lead to any actively maintained fork, though. So I guess it's all stable enough for people to still depend on it in their new projects.

dkdbejwi383 5y ago

This is a perfectly reasonable position to take, however a lot of people are very needy, wanting to be handheld through support beyond a reasonable limit, or demanding that you implement x or y because they need it, and want you to do it for them for free.

quanticle 5y ago
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.
- calvinmorrison 5y ago
  Which is why I always say "show me the code" or "we accept patches".
  - quanticle 5y ago
    I thought about writing "patches are welcome" as an example response, and I deliberately chose, "I'm sorry, but I just don't have time for that," instead. Reviewing a patch, in many cases, takes somewhere between 50% and 75% of the time it takes to write the code in the first place. It's not a given that someone who open sourced a random project will have time to review patches.
    - kop316 5y ago
      Personally, I much prefer "patches are welcome". It puts the ownership back on that person who asked for XYZ feature to do it. If that person is actually motivated enough to write a patch (which I have had!), I welcome reviewing it, because it empowers that person to feel like they can contribute to my project (and hopefully other projects too!), and makes others feel like they can contribute to my project as well.
      - lupire 5y ago
        Patches are always welcome on your fork. Upstream can merge whenever they want.
    - meetups323 5y ago
      Hah. I regularly see patches whose review takes well over 100% the time it would have taken me to create the patch myself. But then I'm employed by $MEGA_CORP and part of the job description is "helping to build and maintain the OSS community", so helping novices create their first patches is a big part of that.
pvorb 5y ago
But are those bad actors really that common? Typically, what I see is that developers really know what to expect from an open source project. If you can't offer them support they could walk away looking for alternative options instead of funding your project. That's because devs usually don't have a budget to spend. They even could fork and solve their own problems without caring to support the problems of others. But I guess all of this is okay and perfectly acceptable use of open source software.

pvorb 5y ago

I agree with you. At least I've never been offended by anyone for not replying to issues raised in my repositories. And a few of my libraries are downloaded millions of times per week from NPM (which is not that uncommon on NPM, but still). That really bad support didn't lead to any actively maintained fork, though. So I guess it's all stable enough for people to still depend on it in their new projects.