So true. I'd expand on that with a more specific example: game modders. When i look at all the energy spent on game mods which bring significant (gratis) value to commercial games, i can't help but wonder what the FOSS gamedev ecosystem would look like if all those dedicated people put their energy on free-software ecosystem.
Minecraft for example made a fortune on promises of later open-sourcing the game and deriving value from all the volunteers building mods.
In an ideal world, I'd agree it would be better that that energy would go into free software. But in our current world, if there's a proprietary game someone is hooked on to the point they get excited about modding when they otherwise wouldn't and that modding leads to a career or even just skill development and perhaps connections with other modders, then overall it seems like it's still a productive use of time, if not entirely an equitable one from a monetary perspective.
There definitely social benefits that can outweigh the more concrete software == value and time trade-off benefits, but I find communities that are "worth" it _much_ harder to find these days.
The premise sounds good but some of the best things in gaming were conceived as mods. Team fortress was a Quake mod. Now, I personally don't blike moba games but Dota also started as a mod. Not to mention Quake OSP/CPMA/Defrag, UTComp, HLDM, Black Mesa and countless others.
Mods = love
Also, each software has its guidelines to build mods. I feel like if a game had modding guidelines suggesting to open source, modders would be more than happy to do so; if not, open-sourcing a single-person project can be considered more work (eg. setup git).
Anyways, while there are some similarities shared between Open Source and video game modding scenes, they are substantially different. Instead of evidence to back up this claim, I implore you to imagine what it would be like if some wrote an article titled "Is It Even Worth Working on Videogame Mods Anymore?".
The “calm and respectful” part is important. I can be right ornery, and learned, the hard way, that OS projects are more fragile than commercial ones, so enemies can do a lot of damage.
I have written software for a fairly … pithy … demographic, and have dealt with feedback that would make many FOSS authors hide under their standing desks, whimpering.
The hardest part for me is actually saying no, because it's never that black/white. I might work on it later because I want to help. I might stumble into a use case where I now need this feature and then do it. Someone might make a PR. But each "open ended issue" is still bandwidth, brain capacity, effort.
However, you are correct about that "using bandwidth" thing.
If we publish something, then I think it behooves us to make it clear what users/adopters of our work can expect from us.
I tend to use the MIT license ("You can do what you want, but don't come crying to me."). I also make every effort to make the project as understandable and well-documented as possible. I appreciate feedback, and apply it, if I deem it fitting.
I have only had one project "go viral," so to speak. It's a fairly big deal, nowadays. It was taken over by a new team, and they had very little trouble getting up to speed on it, because of the quality of the code and documentation. Thousands of folks around the world, use it every day. It's become a fairly vital infrastructure component, for a certain demographic.
The best thing I ever did, with that project, was get the hell away from it, as soon as I was confident the new team was good.
More-or-less agreed.
> This heuristic isn't fully fleshed yet
I'd perhaps extend it as:
“Don't work on FOSS you or people you sufficiently care about aren't using anymore.”
Who qualifies as those you care about and why is an entirely personal thing and I'll not judge anyone's choice there. They could be friends, they could represent a cause you support, they could be randoms and you just get off on feeling helpful, they could be important and you like to be associated, you could be being paid to care, etc.
Also it goes without saying, but I'll say it anyway as I'm in a wordy mood, if you are enjoying working on something even if you don't use the output I'd still consider that to be finding some use in what-ever it is.
Enjoyment is a good signal for whether youre using your time in a way your brain tolerates. I personally strike a balance between maximizing happiness and also maximizing value, so when enjoyment dips, it takes a bit for me to get off a project still.
I agree with your second point though. The main reason I see for contributing to FOSS is to fix issues that affect me or creating issues that may lead to the maintainers improving the software in a way that would benefit me.
I think it makes sense for companies to open source tools they depend on. They help others by providing the free software and in return they get help identifying and fixing bugs.
I understand the logic behind this assertion, but i don't believe it holds true at all. Businesses will favor fixing bugs related to main features that drive revenue in. Whatever's not hurting their business is invisible to them.
It also means you’re very restricted in license choices since you otherwise never know if your project might get picked up in the future and used in a proprietary service. This likely means you have to use something like AGPL.
There is no black/white category of what is direct support though. It's a spectrum. And these are my own personal heuristics, rooted in my experiences and found benefits/drawbacks of my own projects and working with people.
Maybe you’re okay with being treated the way the log4j maintainers are being treated right now. The whole point is that you shouldn’t be! People producing valuable software in their free time and giving it away for free should be treated with respect and that’s not happening right now. We need to find a solution!
Someone using something I have written doesn’t cost me anything, but it also doesn’t create any obligations for me. I don’t need to make my contact info public, or have any interactions with users whatsoever.
log4j accepted donations which is really it’s own thing. Running a charity, which is what it means to get paid full time to maintain OSS, has a host of issues that have little to do with OSS and a lot to do with public relations.
If the biggest or only user is one company and its customers, it’s not really capital O Open.
One of those things, other people actually use! I don't so much, but I enjoy keeping it going every so often because it gives me purpose.
Another of those things, literally nobody seems to know about, even though it's a very useful thing which there is no oss alternative for. I'm a little sad nobody uses it, but it's fine because I still use it.
When I stop using these completely, I'll shutter them. Somebody can fork them if they want.
I think there is still some middleground possible. It can still be enjoyable doing small support stuff for it and to keep it running and fixing small bugs, without any big rewrites or big features. I once cared about those things and I might still do. Just keeping it running might feel better than discarding it.
It all depends on personal preferences, the type of users and their communication, if you still use the language, etc.
If they want the patch or improvement, they should pay for it.
Log4J CVE might have been the perfect use case for asking for 50K-1M EURO for the maintainers to patch the bug, to any corporate clients this is a drop in the bucket.
Lol!
* Don't work on FOSS that supports a SaaS or proprietary product. You're enriching someone else's ecosystem for no money. You take on the communication bandwidth and issue load of dealing with not only your issues but their issues too. Your software is useless if theirs fails. It's thankless.
* Don't work on FOSS you aren't using yourself anymore. This heuristic isn't fully fleshed yet, but I've found if I stop using software I wrote, it just becomes a support burden for me. Especially frustrating are entitled users or entitled users who make money entirely using my software who want niche issues fixed. Not PRs, they want me to debug it all or put in the thought to get the features working. (Probably doesn't apply if you're immersed socially with a friend group working on a FOSS project though)