6 ms·

I'm in the early stages of building some tools to automatically lock new issues in my own Open Source repos, and to give Patreon supporters automatic access to

I'm in the early stages of building some tools to automatically lock new issues in my own Open Source repos, and to give Patreon supporters automatic access to comment on locked issues. Anyone will be able to read existing Github/Gitlab issues, but only supporters will be able to join the conversation or file new issues. It's loosely based on some ideas that William Gross[0] and a few other sources have proposed. You're on Patreon, but most of the experiments you've run so far are around traditional sponsorship, ads, and donations. Is there an ethical/logistical reason you've mostly stuck to that path, or is that just the stuff you've happened to try so far? This is still in the experimental stages for me, but if I built this in a way that other people could use, I'm curious about whether anyone else would be interested in trying it out -- or if the potential to suppress community involvement is part of the reason why developers have steered away from strategies like this. [0]: http://wgross.net/essays/give-away-your-code-but-never-your-time http://wgross.net/essays/give-away-your-code-but-never-your-...

justsubmit 7y ago
That attitude is very strange to me. I care about the quality and usefulness of my software. I give it away to give back, because I have been given much. There are bugs in my software which I will never discover on my own. When a user offers me a bug report or a patch, that user is also giving back. The bug report is a form of contribution. It gives me information I wouldn't otherwise have, which I can use to improve my software, which can make it more reliable and useful to others. Most users who encounter a bug don't take the time to report it. Those who do report bugs contribute their time and effort, and the fruits of their contributions help not only myself, but other users of the software. This applies not only to bug reports, but to suggestions and feature requests as well, because all of them can help make the software more useful to others. The only interaction that has negative value is to be asked a question that's already answered in the documentation. But even those can be valuable when they indicate a weakness in the documentation that makes the information hard to find or understand, which can be improved, which helps other users. And even the questions which are trivially answered by the documentation can lead to valuable interactions later. So to charge a user for the privilege of interacting with me would be like asking the user to pay me for the privilege of helping me, for the privilege of giving back. It would be rude, and it would deny many the privilege of contributing through the means at their disposal. It would almost be like keeping a fellow human being in a kind of moral debt, rejecting their contributions out-of-hand, leaving them obliged, with no means to repay (or to "pay it forward").
- juliusmusseau 7y ago
  Monetizing our work is not strange. It might require some contortions compared to the most direct approach (step 1. write software. step 2. git push), but that doesn't make it a bad thing. Here is Charles Dickens writing about his own contortions to monetize his work: There must be a special design to overcome that specially trying mode of publication, and I cannot better express the difficulty and labour of it than by asking you to turn over any two weekly numbers of "A Tale of Two Cities," or "Great Expectations," [...] Notice how patiently and expressly the [serialized novel] has to be planned for presentation in fragments, and yet for afterwards fusing together as an uninterrupted whole. I think holding onto bugfixes and feature enhancements and letting Patreon subscribers have first dibs on these makes sense.
  - rtownsend2 7y ago
    Ok, but if I’m using your thing and I’ve found a bug, asking me to jump through some hoops and/or pay to report it means I just won’t bother.
  - pessimizer 7y ago
    > Monetizing our work is not strange. It might require some contortions compared to the most direct approach (step 1. write software. step 2. git push), but that doesn't make it a bad thing. You're answering the question you want to answer, not the one that was asked. It's important that you get paid for your work so you can eat, and it's good to figure out ways to monetize your work. Charging people for reporting bugs is strange because knowing about bugs helps you and the rest of your users more than it helps the reporter. > I think holding onto bugfixes and feature enhancements and letting Patreon subscribers have first dibs on these makes sense. I think that could make sense, too, but neither of those things are reporting bugs or suggesting features. I don't have a quote.
- michaelt 7y ago
  There are bugs in my software which I will never discover on my own. [...] The bug report is a form of contribution. Well, there are at least two ways of viewing a bug report: 1. A bug report is a helpful contribution towards more perfect software, giving the developer new information but no obligation. For example, pointing out a security bug. 2. A bug report is a request for support, asking the developer to work on a code path they themselves don't use (as if they did, they'd have triggered the bug themselves). For example, asking them to fix graphics support on 3dfx on Windows NT 4.0 :)
luckylion 7y ago
At some point, this becomes a complicated way to say "here's the code, and I'm available for commercial support", doesn't it? Another thing you might try is "paying" for features, i.e. somebody has a feature request that you think is an improvement you'd accept but don't give a high priority to (basically "PR welcome, but there's more important stuff to work on right now"). There's a potential risk of including features that you wouldn't otherwise because they make you money, but that aside, it could help both with funding and responsiveness towards users.

justsubmit 7y ago

That attitude is very strange to me. I care about the quality and usefulness of my software. I give it away to give back, because I have been given much. There are bugs in my software which I will never discover on my own. When a user offers me a bug report or a patch, that user is also giving back. The bug report is a form of contribution. It gives me information I wouldn't otherwise have, which I can use to improve my software, which can make it more reliable and useful to others. Most users who encounter a bug don't take the time to report it. Those who do report bugs contribute their time and effort, and the fruits of their contributions help not only myself, but other users of the software. This applies not only to bug reports, but to suggestions and feature requests as well, because all of them can help make the software more useful to others. The only interaction that has negative value is to be asked a question that's already answered in the documentation. But even those can be valuable when they indicate a weakness in the documentation that makes the information hard to find or understand, which can be improved, which helps other users. And even the questions which are trivially answered by the documentation can lead to valuable interactions later. So to charge a user for the privilege of interacting with me would be like asking the user to pay me for the privilege of helping me, for the privilege of giving back. It would be rude, and it would deny many the privilege of contributing through the means at their disposal. It would almost be like keeping a fellow human being in a kind of moral debt, rejecting their contributions out-of-hand, leaving them obliged, with no means to repay (or to "pay it forward").

juliusmusseau 7y ago
Monetizing our work is not strange. It might require some contortions compared to the most direct approach (step 1. write software. step 2. git push), but that doesn't make it a bad thing. Here is Charles Dickens writing about his own contortions to monetize his work: There must be a special design to overcome that specially trying mode of publication, and I cannot better express the difficulty and labour of it than by asking you to turn over any two weekly numbers of "A Tale of Two Cities," or "Great Expectations," [...] Notice how patiently and expressly the [serialized novel] has to be planned for presentation in fragments, and yet for afterwards fusing together as an uninterrupted whole. I think holding onto bugfixes and feature enhancements and letting Patreon subscribers have first dibs on these makes sense.
- rtownsend2 7y ago
  Ok, but if I’m using your thing and I’ve found a bug, asking me to jump through some hoops and/or pay to report it means I just won’t bother.
- pessimizer 7y ago
  > Monetizing our work is not strange. It might require some contortions compared to the most direct approach (step 1. write software. step 2. git push), but that doesn't make it a bad thing. You're answering the question you want to answer, not the one that was asked. It's important that you get paid for your work so you can eat, and it's good to figure out ways to monetize your work. Charging people for reporting bugs is strange because knowing about bugs helps you and the rest of your users more than it helps the reporter. > I think holding onto bugfixes and feature enhancements and letting Patreon subscribers have first dibs on these makes sense. I think that could make sense, too, but neither of those things are reporting bugs or suggesting features. I don't have a quote.
michaelt 7y ago
There are bugs in my software which I will never discover on my own. [...] The bug report is a form of contribution. Well, there are at least two ways of viewing a bug report: 1. A bug report is a helpful contribution towards more perfect software, giving the developer new information but no obligation. For example, pointing out a security bug. 2. A bug report is a request for support, asking the developer to work on a code path they themselves don't use (as if they did, they'd have triggered the bug themselves). For example, asking them to fix graphics support on 3dfx on Windows NT 4.0 :)

luckylion 7y ago

At some point, this becomes a complicated way to say "here's the code, and I'm available for commercial support", doesn't it? Another thing you might try is "paying" for features, i.e. somebody has a feature request that you think is an improvement you'd accept but don't give a high priority to (basically "PR welcome, but there's more important stuff to work on right now"). There's a potential risk of including features that you wouldn't otherwise because they make you money, but that aside, it could help both with funding and responsiveness towards users.