If anyone demands I implement some feature into one of my open source projects that I either don’t have time for or don’t want to do, my response is one of the following:
I’ll get to it when I can (if I actually care to do it)
You are welcome to implement it yourself and submit a PR
You are welcome to fork the project and do it yourself or convince someone else to do it
But thankfully, my projects don’t have a very wide audience, so requests/demands are rare.
But you have to implement [Insert Niche Feature That Adds No Benefit For The Average User] because I need it and can’t be bothered to implement it myself! /s
As I understood it, one of the foundations of open source development is scratching your own itches, then putting what you made up for grabs in case it scratches someone else’s. There shouldn’t be any expectation of support on your part beyond an email or two. The code’s out there if they want to scratch the itch a different way. It’s kind of a homesteader ethic.
That’s basically right. But it’s quite a difference what you have to do to scratch your itch, and what you need to do for it to be useful for others.
If you do it for yourself, there are no tests or documentation or even a GUI. It’s quick and dirty, all configuration is hardcoded. If you need a different config, you’ll just change the code.
All that doesn’t really fly if you expect someone else to use the project.
On the other side, especially if it’s too polished, idiots will perceive the project as being a commercial one and demand that you do what they want.
If you don’t know the stories, maybe read up on the maintainer of core-js or Marcel Bokhorst. These two people complained about how tough it is to make good open source software. Both talked specifically about their toxic audience. So in turn the audience ridiculed them and they even received death threats.
I suppose the thing is, I personally wouldn’t care much if anyone else used it or not, my itch has been scratched. If someone else finds it of use, great! If they need changes, they’ve got the code and can get crackin’ on it themselves. Or, they can pay me to do it if we can agree on a price. Outside of that I have no expectations.
That’s definitely a healthy way of dealing with that.
But with this way, something like Linux, Distros, Firefox, Blender or LibreOffice would have never happened. There are those who want to build retail-level open source software, mostly out of idealism, and then you are stuck between a non-monetizable rock and a toxic hard place.
But I totally agree with you, unless you are super idealistic, your way of handling it is probably the most healthy one and the one that will cause you the least amount of trouble. And it’s also what I do, except when I sometimes do get idealistic.
I did maintain an opensource project for a while and that taught me how to do it correctly:
Or to put it differently: Never see your project or contribution as anything more than a hobby. You will never see an return on investment.
If anyone demands I implement some feature into one of my open source projects that I either don’t have time for or don’t want to do, my response is one of the following:
But thankfully, my projects don’t have a very wide audience, so requests/demands are rare.
But you have to implement [Insert Niche Feature That Adds No Benefit For The Average User] because I need it and can’t be bothered to implement it myself! /s
You can leverage your projects to help land jobs. Other than that yeah, you don’t owe anybody anything.
As I understood it, one of the foundations of open source development is scratching your own itches, then putting what you made up for grabs in case it scratches someone else’s. There shouldn’t be any expectation of support on your part beyond an email or two. The code’s out there if they want to scratch the itch a different way. It’s kind of a homesteader ethic.
That’s basically right. But it’s quite a difference what you have to do to scratch your itch, and what you need to do for it to be useful for others.
If you do it for yourself, there are no tests or documentation or even a GUI. It’s quick and dirty, all configuration is hardcoded. If you need a different config, you’ll just change the code.
All that doesn’t really fly if you expect someone else to use the project.
On the other side, especially if it’s too polished, idiots will perceive the project as being a commercial one and demand that you do what they want.
If you don’t know the stories, maybe read up on the maintainer of core-js or Marcel Bokhorst. These two people complained about how tough it is to make good open source software. Both talked specifically about their toxic audience. So in turn the audience ridiculed them and they even received death threats.
I suppose the thing is, I personally wouldn’t care much if anyone else used it or not, my itch has been scratched. If someone else finds it of use, great! If they need changes, they’ve got the code and can get crackin’ on it themselves. Or, they can pay me to do it if we can agree on a price. Outside of that I have no expectations.
That’s definitely a healthy way of dealing with that.
But with this way, something like Linux, Distros, Firefox, Blender or LibreOffice would have never happened. There are those who want to build retail-level open source software, mostly out of idealism, and then you are stuck between a non-monetizable rock and a toxic hard place.
But I totally agree with you, unless you are super idealistic, your way of handling it is probably the most healthy one and the one that will cause you the least amount of trouble. And it’s also what I do, except when I sometimes do get idealistic.
I put it to you that ideals may constitute a scratchable itch.
That is true, but then you probably are in trouble ;)
Depends on how hard you scratch! lol