My boundaries as an open source developer(joeldenning.com)
joeldenning.com
My boundaries as an open source developer
https://joeldenning.com/?p=29
239 comments
> People repeatedly demanding help in the github issues without even providing repro steps.
This is the biggest annoyance for me. There's a very clear issue template on my repos. It provides concrete, reasonable requirements (for example, post the actual config that broke!) yet people frequently expect support without filling it out. Even worse, they will make drive-by comments/demands on random PRs instead of opening an issue.
It's kind of amazing how entitled people are.
This is the biggest annoyance for me. There's a very clear issue template on my repos. It provides concrete, reasonable requirements (for example, post the actual config that broke!) yet people frequently expect support without filling it out. Even worse, they will make drive-by comments/demands on random PRs instead of opening an issue.
It's kind of amazing how entitled people are.
I literally print out a mostly pre-filled github link with most repro context, all they have to do is fill the rest of it in. They still don't do it.
Nowadays a non-templated bug issue is autoclosed.
Nowadays a non-templated bug issue is autoclosed.
I am 90% of the way to adding "You have been banned from this issue tracker for wasting maintainer time. In future, make some attempt to do your share of the work." to the autoclose.
Autoclosing is a good take.
Depending on the userbase (e.g. end users from non-OSS ecosystems) and what you want to achieve you might just have to accept they are more used to talking to corporate support agents than filing bugs and learn to work with them. Autoclosing immediately puts the user into an adversarial position - better would be to have an automated reply for incomplete bug reports stating what is missing and that the information is needed for you to help the user to make it clear that filling it in properly is in their best interest as well.
Do you think if more people provided positive feedback would have helped?
I remember when working on customer relations roles in startups (devs wear many hats there), we had lots of bad responses, but some were just outright praise.
Like "thank you, you've changed our live for the better" kinda stuff, and it always made the work of wading through the muck more bearable.
Like "thank you, you've changed our live for the better" kinda stuff, and it always made the work of wading through the muck more bearable.
Positive feedback is nice, but it doesn't negate the amount of assholes and entitlement I needed to deal with on a regular basis.
This is a problem of socialized open source on platforms like github. At some point you have to just say 'no'. But yes, some "consultants" just shamelessly abuse your work for themselves.
Of course if you make it your job, it will come with all the negatives a job can entail.
Of course if you make it your job, it will come with all the negatives a job can entail.
Sounds like OS developers would benefit from Product Managers who could shield them from the users (among other PM tasks). Do many OS projects have PMs? Are there any "standards" around non dev roles in OS projects?
Unfortunately my experience is that most PMs are not sufficiently technical. They will often add more work by injecting useless processes and try to "demonstrate value" by coming up with new ideas without actually understanding the problem domain.
The best approach I have found is simply to add more automated gates/bots. If people have not done what the bot asks, there's no need to waste time/energy on them.
The best approach I have found is simply to add more automated gates/bots. If people have not done what the bot asks, there's no need to waste time/energy on them.
> Unfortunately my experience is that most PMs are not sufficiently technical.
Yeah. And I eventually came to realize: lazy.
Yeah. And I eventually came to realize: lazy.
> > Unfortunately my experience is that most PMs are not sufficiently technical.
> Yeah. And I eventually came to realize: lazy.
Lazy is just one side of the coin. If someone's career is focused on unsexy hard work instead of halfheartedly "demonstrating value", the core problem is not that they cannot slack off. The core problem is that others can hold them hostage.
> Yeah. And I eventually came to realize: lazy.
Lazy is just one side of the coin. If someone's career is focused on unsexy hard work instead of halfheartedly "demonstrating value", the core problem is not that they cannot slack off. The core problem is that others can hold them hostage.
Bigger project here, but over at LibreOffice, our shield is a strong quality assurance team. 20-30 active triagers. The number has stayed constant over the years and we actively recruit. How I do recruiting: https://discourse.sustainoss.org/t/how-i-recruit-and-mentor-...
I don't understand, if it's open source why don't they just add whatever features they want.
Laziness/lack of understanding
Most of the comments here remind me of the famous Neil Gaiman quote, "George R.R. Martin is not your bitch." [1] But I don't think that's the right framing. People buy the first book because they hope there will be a second, even though they haven't paid for that second book and hence are not entitled to it. People use your open-source project because you said, hey, here's this exciting new thing, try it out, so they assume you'd also want to listen when it doesn't quite work as it should. That's not about a false sense of entitlement or callousness on the part of your users at all. It's also not about freeloading, because a lot of those pull requests and issues on Github will be coming from people who publish their own open-source software. Instead, it's about managing expectations, like the post does. Put a big "this project is not maintained" warning on top, and nobody will bother you. Although I do understand that for larger active projects, it can be hard to explain to users exactly where on the spectrum between "don't bother me" and "I'll fix your problem yesterday" you are, and the bigger a project gets, the more likely you'll be to encounter people who enjoy exploiting your free labor.
[1] https://journal.neilgaiman.com/2009/05/entitlement-issues.ht...
[1] https://journal.neilgaiman.com/2009/05/entitlement-issues.ht...
> People use your open-source project because you said, hey, here's this exciting new thing, try it out, so they assume you'd also want to listen when it doesn't quite work as it should.
> Put a big "this project is not maintained" warning on top, and nobody will bother you.
I think this is exactly the problem. The author never promises they would maintain the software, nor expect their definition of “this works” to match the users’. Why do they need to put up a sign in the first place for people to not assume? “Expecting things that were never promised” is pretty much the definition of self-entitlement. IMO this should be entirely the other way around. People should not expect anything unless the authors say they are willing to maintain.
> Put a big "this project is not maintained" warning on top, and nobody will bother you.
I think this is exactly the problem. The author never promises they would maintain the software, nor expect their definition of “this works” to match the users’. Why do they need to put up a sign in the first place for people to not assume? “Expecting things that were never promised” is pretty much the definition of self-entitlement. IMO this should be entirely the other way around. People should not expect anything unless the authors say they are willing to maintain.
This makes a ton of sense. In some communities.
It's a bit similar to what is the expected relationship between Alice and Bob after Alice saves Bob from drowning.
In some communities, Bob needs to be thankful for Alice for the rest of his life, with no more expectations of her.
In others, Alice is now responsible for Bob for the rest of her life.
It's a bit similar to what is the expected relationship between Alice and Bob after Alice saves Bob from drowning.
In some communities, Bob needs to be thankful for Alice for the rest of his life, with no more expectations of her.
In others, Alice is now responsible for Bob for the rest of her life.
Do you only ever expect things that were explicitly promised? If you go to a job interview, are you self-entitled because you expect a phone call afterwards even if that wasn't spelled out?
It's funny, because I think I have pretty much the opposite expectation.
When I encounter a new open source project it means that I can make it better by providing pull requests with new features, or fixing bugs. And then everyone benefits. If they choose to listen to me that's fine, but that's the icing on the cake, not the main course.
When I encounter a new open source project it means that I can make it better by providing pull requests with new features, or fixing bugs. And then everyone benefits. If they choose to listen to me that's fine, but that's the icing on the cake, not the main course.
There are people like that, and they're usually great to have on an OSS project, but they're a minority.
I think there should be term like suffering from open-source fatigue.
Being an active open source dev myself I can relate to this but at the same time I also have been on the other side of the fence when my oss projects didn't get a lot of traction and any mention from anyone, even if it was an issue, got me really excited and it also kinda validated my efforts.
It's like being a mini celebrity feeling happy when somebody asks for your first autograph but as you become more successful more people want your time and attention and then you don't want it anymore. Also unlike being a celebrity you may get some fame but rarely any fortune, so that makes it all the more easy to get annoyed when people try to eat your attention for their own benefit.
Being an active open source dev myself I can relate to this but at the same time I also have been on the other side of the fence when my oss projects didn't get a lot of traction and any mention from anyone, even if it was an issue, got me really excited and it also kinda validated my efforts.
It's like being a mini celebrity feeling happy when somebody asks for your first autograph but as you become more successful more people want your time and attention and then you don't want it anymore. Also unlike being a celebrity you may get some fame but rarely any fortune, so that makes it all the more easy to get annoyed when people try to eat your attention for their own benefit.
> Also unlike being a celebrity you may get some fame but rarely any fortune
I know this isn't your main point, but afaik most low-level celebrities barely make money from it either. So it's actually even more similar than you thought.
I know this isn't your main point, but afaik most low-level celebrities barely make money from it either. So it's actually even more similar than you thought.
This! Open source can make your career, just as much as the Op says; it can break your back.
From the outset i would say that most people releasing OSS stuff wants it to be used in production. thats until you get the hungry corps looking for free support. IMO at that stage an OSS maintainer needs to start a consulting company and funnel everything into it to avoid the burn. if this guy was making 6 figures consulting for those same companies, i think the conversation was different.
Unfortunately knowing how to write software is not always compatible with self-marketing and has a keen business acumen.
From the outset i would say that most people releasing OSS stuff wants it to be used in production. thats until you get the hungry corps looking for free support. IMO at that stage an OSS maintainer needs to start a consulting company and funnel everything into it to avoid the burn. if this guy was making 6 figures consulting for those same companies, i think the conversation was different.
Unfortunately knowing how to write software is not always compatible with self-marketing and has a keen business acumen.
So much this. I'm glad he put this out there. I'll start linking to it too.
There seems to be a common misconception about open source. When I release software as open source, it does not mean I work for you for free, need to provide you with anything, even need to be nice to you. I may. Or I may not.
When I release software under an open source license, then we have a very specific deal. You are entitled to do certain things with the software, for example use it free of charge, or change it, or redistribute it, and I'm entitled to certain things in return, for example you keep attribution, you publish changes that you made under the same license, etc. Nothing more, nothing less. I could be an individual that hacked something in their free time, or I'm a multi-national mega-corp. Does not matter. It just means we have a deal.
It's nice if a community emerges, and if I feel like it, I may participate in it. And accept pull requests or help with troubleshooting or implement new features. But I don't have to and I don't have to feel any obligation whatsoever. Anybody who thinks otherwise has misunderstood the concept or is maliciously misusing it.
That's it.
This is misunderstood not just by users, but even by creators themselves. They feel pressure, they feel bad if they don't respond in time, or implement new requested features, or accept pull requests. They shouldn't. Open source just means I published it once with a very specific deal. I may continue to do so if it makes sense to me, but I can also just stop doing so. I implement features when I have a reason for it, for example I like to have them in the software so I can use them myself, or maybe because I'm a corp that sees a business need. But implementing them for free just because somebody asked for it, that's just asking for trouble. If you do that regularly, and not mostly because you think it's fun, but because you want to "support the community" or whatnot, you are taking steps towards burnout, and ultimately are not just hurting yourself but even the larger community, because you are fostering the expectation that that's what open source devs should do. No, they shouldn't. That's not what open source is about.
It's about a specific deal. Nothing more, nothing less.
There seems to be a common misconception about open source. When I release software as open source, it does not mean I work for you for free, need to provide you with anything, even need to be nice to you. I may. Or I may not.
When I release software under an open source license, then we have a very specific deal. You are entitled to do certain things with the software, for example use it free of charge, or change it, or redistribute it, and I'm entitled to certain things in return, for example you keep attribution, you publish changes that you made under the same license, etc. Nothing more, nothing less. I could be an individual that hacked something in their free time, or I'm a multi-national mega-corp. Does not matter. It just means we have a deal.
It's nice if a community emerges, and if I feel like it, I may participate in it. And accept pull requests or help with troubleshooting or implement new features. But I don't have to and I don't have to feel any obligation whatsoever. Anybody who thinks otherwise has misunderstood the concept or is maliciously misusing it.
That's it.
This is misunderstood not just by users, but even by creators themselves. They feel pressure, they feel bad if they don't respond in time, or implement new requested features, or accept pull requests. They shouldn't. Open source just means I published it once with a very specific deal. I may continue to do so if it makes sense to me, but I can also just stop doing so. I implement features when I have a reason for it, for example I like to have them in the software so I can use them myself, or maybe because I'm a corp that sees a business need. But implementing them for free just because somebody asked for it, that's just asking for trouble. If you do that regularly, and not mostly because you think it's fun, but because you want to "support the community" or whatnot, you are taking steps towards burnout, and ultimately are not just hurting yourself but even the larger community, because you are fostering the expectation that that's what open source devs should do. No, they shouldn't. That's not what open source is about.
It's about a specific deal. Nothing more, nothing less.
I will preface this by saying I have immense respect for anyone who open-sources their work. I think the web as we know it today would not exist without such kind and hard-working individuals.
In my opinion, I think most of these issues outlined in the article are caused by lack of communication combined with unclear expectations, to be honest.
The only thing I ask of open-source library authors/maintainers is this: be upfront and clear about the nature of your library, and your level of commitment.
Is it just a hobby app? Totally fine, just put in bold text "this is a hobby app, not recommended for production use". That way, everyone knows what to expect, and if they do decide to use it in production, they do it at their own risk.
Do you feel that it is feature-complete? Then just say so, and indicate you will not be doing any more work on it.
Do you want to work on bugs whenever you feel like it? Nothing wrong with that, it's your work, but again, please just put it somewhere in writing so that any developer or PM who comes across your library knows exactly what to expect.
You painstakingly supported a library for years, got burned out and want to quit? At least try to pass it to another maintainer.
IMO these are just some very, very basic things that open-source authors can do that would alleviate a LOT of the friction that occurs in this space between them and those who decide to rely on their work.
Be kind, be clear, be upfront. That's it!
In my opinion, I think most of these issues outlined in the article are caused by lack of communication combined with unclear expectations, to be honest.
The only thing I ask of open-source library authors/maintainers is this: be upfront and clear about the nature of your library, and your level of commitment.
Is it just a hobby app? Totally fine, just put in bold text "this is a hobby app, not recommended for production use". That way, everyone knows what to expect, and if they do decide to use it in production, they do it at their own risk.
Do you feel that it is feature-complete? Then just say so, and indicate you will not be doing any more work on it.
Do you want to work on bugs whenever you feel like it? Nothing wrong with that, it's your work, but again, please just put it somewhere in writing so that any developer or PM who comes across your library knows exactly what to expect.
You painstakingly supported a library for years, got burned out and want to quit? At least try to pass it to another maintainer.
IMO these are just some very, very basic things that open-source authors can do that would alleviate a LOT of the friction that occurs in this space between them and those who decide to rely on their work.
Be kind, be clear, be upfront. That's it!
So your solution to open source authors getting too many demands for doing things is to demand they should do more?
Seriously, this feels almost a bit like victim blaming. Why would an OSS maintainer need to write that something is a hobby project. It really doesn't matter, if as a company you want to rely on it, pay for it. Why should your expectations change because of what the maintainer says?
Seriously, this feels almost a bit like victim blaming. Why would an OSS maintainer need to write that something is a hobby project. It really doesn't matter, if as a company you want to rely on it, pay for it. Why should your expectations change because of what the maintainer says?
> I will preface this by saying I have immense respect for anyone who open-sources their work. I think the web as we know it today would not exist without such kind and hard-working individuals.
That itself is part of the problem.
I do also appreciate all the great FOSS ecosystems that I'm using. Who knows where we would be without them.
But open source software is not about some kind, selfless altruist who hacks away for free for the benefit of others. It's about publishing the source code with some attached rights and obligations for programs or libraries that have been developed to scratch an itch. Be it personal need, personal interest, learning opportunity or straight up business necessity. You publish to get a community involved to make your software better, be it through bug reports, recommendations for improvement, pull requests, etc. That ultimately benefits the author, and that's the whole point.
It's a misconception that open source software is (or should be) developed for the greater good, to be kind to one another. And by keeping to thank "kind hard working individuals" (which they often times are!), one perpetuates this misconception. It's great if kindness is a component in all of this. But it's not the central point and should not be expected to be. That's what causes threads like this one in the first place, where somebody has to complain about being exploited or getting annoyed with peoples expectations, or their own expectations with themselves, and then others opining about that.
> You painstakingly supported a library for years, got burned out and want to quit? At least try to pass it to another maintainer.
Are you serious? Above you just said that you have immense respect for open source authors. And now you say that somebody can't take it anymore and is burned out and THEN you STILL expect them to put MORE work in, despite being burned out, to pass things on? The source code is available, the license is clear, if there is anybody else who wants to maintain, they can just go and to it. Why do you keep demanding anything from the already-burned-out author that you respect immensely? Honestly, I find that deeply disrespectful.
That itself is part of the problem.
I do also appreciate all the great FOSS ecosystems that I'm using. Who knows where we would be without them.
But open source software is not about some kind, selfless altruist who hacks away for free for the benefit of others. It's about publishing the source code with some attached rights and obligations for programs or libraries that have been developed to scratch an itch. Be it personal need, personal interest, learning opportunity or straight up business necessity. You publish to get a community involved to make your software better, be it through bug reports, recommendations for improvement, pull requests, etc. That ultimately benefits the author, and that's the whole point.
It's a misconception that open source software is (or should be) developed for the greater good, to be kind to one another. And by keeping to thank "kind hard working individuals" (which they often times are!), one perpetuates this misconception. It's great if kindness is a component in all of this. But it's not the central point and should not be expected to be. That's what causes threads like this one in the first place, where somebody has to complain about being exploited or getting annoyed with peoples expectations, or their own expectations with themselves, and then others opining about that.
> You painstakingly supported a library for years, got burned out and want to quit? At least try to pass it to another maintainer.
Are you serious? Above you just said that you have immense respect for open source authors. And now you say that somebody can't take it anymore and is burned out and THEN you STILL expect them to put MORE work in, despite being burned out, to pass things on? The source code is available, the license is clear, if there is anybody else who wants to maintain, they can just go and to it. Why do you keep demanding anything from the already-burned-out author that you respect immensely? Honestly, I find that deeply disrespectful.
> Are you serious? Above you just said that you have immense respect for open source authors. And now you say that somebody can't take it anymore and is burned out and THEN you STILL expect them to put MORE work in, despite being burned out, to pass things on? The source code is available, the license is clear, if there is anybody else who wants to maintain, they can just go and to it. Why do you keep demanding anything from the already-burned-out author that you respect immensely? Honestly, I find that deeply disrespectful.
I just want to add to this: Finding and training a new good maintainer is a lot of work. If you just pass the project along with its reputation to whoever comes up then you might be doing more harm and it might be better to not do anything and have the new maintainer earn their own trust with their fork. So yeah, having open source developers to pass on the project when they want to quit is not a fair expectation.
I just want to add to this: Finding and training a new good maintainer is a lot of work. If you just pass the project along with its reputation to whoever comes up then you might be doing more harm and it might be better to not do anything and have the new maintainer earn their own trust with their fork. So yeah, having open source developers to pass on the project when they want to quit is not a fair expectation.
The OP is an article doing literally exactly what you want. And he's going above and beyond what's required–he didn't even need to communicate all this redundantly. It's already all in the open source license–willingness to work, level of commitment, etc. Just read the license. It's included in every open source project.
Exactly, here is the first sentence of the zlib license:
> This software is provided 'as-is', without any express or implied warranty.
Almost all open-source licenses will have conditions like this, MOST EVEN MAKE IT ALL CAPS. The default expectation of support from the author should be 0.0
> This software is provided 'as-is', without any express or implied warranty.
Almost all open-source licenses will have conditions like this, MOST EVEN MAKE IT ALL CAPS. The default expectation of support from the author should be 0.0
You could figure out all of this by looking at the project's releases, mailing lists and the bug tracker. That's something you should do even if a author puts up a statement because it might no longer be accurate.
I agree with you. There was a comment on here at some point that if you have a solution that starts “If everybody would just...”, then you don’t have a solution at all. Everybody will not just respect open source maintainers (well deserved) right to not be harassed, poked, and prodded.
I 1000% agree that open source contributors and maintainers don’t owe anyone anything, but if people still demand things, I’d recommend putting disclaimers like you’re recommending front and center, if at the very least so that maintainers can respond to the pushy people with a link to it.
I 1000% agree that open source contributors and maintainers don’t owe anyone anything, but if people still demand things, I’d recommend putting disclaimers like you’re recommending front and center, if at the very least so that maintainers can respond to the pushy people with a link to it.
> be upfront and clear about the nature of your library, and your level of commitment
The clear statement on this is in the license of the project. You need to read the license, which grants you certain rights to the software to see what you're being granted and what you're not getting.
In nearly every license, very specifically says that it's not supported and you're entirely on your own if you decide to use it.
If you need a higher level of assurance, you need to pay for support. Either from the author(s) if they are interested, or from third party companies who provide support for that library, if any exist.
The clear statement on this is in the license of the project. You need to read the license, which grants you certain rights to the software to see what you're being granted and what you're not getting.
In nearly every license, very specifically says that it's not supported and you're entirely on your own if you decide to use it.
If you need a higher level of assurance, you need to pay for support. Either from the author(s) if they are interested, or from third party companies who provide support for that library, if any exist.
I was about to reply something similar but your comment totally covered me.
NPM had some thoughts about providing package.json metadata in order for the customers to know the author intentions but I am not sure what happened to it.
I remember reading about it in this article: https://www.theregister.com/2020/10/28/nodejs_15_michael_daw...
> The [module] maintainers are struggling," he said. "They may have written a module, it was a hobby they did on a weekend, now they've got 20,000,000 downloads and the people who are using it > have expectations which are more than what > is appropriate for something that they're getting for free. We've worked on something that we call package support which is adding extra metadata to > the package JSON, which allows the maintainer to provide information about their intention in terms of support. So what kind of support is there? Is it best effort? Is there no support at all? Is there > a company? Is it part of a foundation?
- Michael Dawson
NPM had some thoughts about providing package.json metadata in order for the customers to know the author intentions but I am not sure what happened to it.
I remember reading about it in this article: https://www.theregister.com/2020/10/28/nodejs_15_michael_daw...
> The [module] maintainers are struggling," he said. "They may have written a module, it was a hobby they did on a weekend, now they've got 20,000,000 downloads and the people who are using it > have expectations which are more than what > is appropriate for something that they're getting for free. We've worked on something that we call package support which is adding extra metadata to > the package JSON, which allows the maintainer to provide information about their intention in terms of support. So what kind of support is there? Is it best effort? Is there no support at all? Is there > a company? Is it part of a foundation?
- Michael Dawson
> We've worked on something that we call package support which is adding extra metadata to > the package JSON, which allows the maintainer to provide information about their intention in terms of support. So what kind of support is there? Is it best effort? Is there no support at all? Is there a company? Is it part of a foundation?
The default answer is: No. There is no support. And that's written in the license already.
Announcing anything beyond that is called an ad. It may be a useful ad, but it's still an ad.
(Assuming it's paid support. If it's support "for free" then that's part of the problem if it's social-pressures somebody to do this in their free time. You are externalizing your business support costs. And you really want to build your business empire on a teenager's hobby project? So, whoever is interested in this "intention" metadata should only really care about paid support, and then that's an ad.)
The default answer is: No. There is no support. And that's written in the license already.
Announcing anything beyond that is called an ad. It may be a useful ad, but it's still an ad.
(Assuming it's paid support. If it's support "for free" then that's part of the problem if it's social-pressures somebody to do this in their free time. You are externalizing your business support costs. And you really want to build your business empire on a teenager's hobby project? So, whoever is interested in this "intention" metadata should only really care about paid support, and then that's an ad.)
> That way, everyone knows what to expect, and if they do decide to use it in production, they do it at their own risk.
This is the default position for most open source licences, hobby projects or not.
I agree it is useful for hobby projects to be labelled as such, however.
This is the default position for most open source licences, hobby projects or not.
I agree it is useful for hobby projects to be labelled as such, however.
[deleted]
Totally agreed. One of the easiest ways to deal with misaligned expectations is to clearly state your expectations.
While that's true, it's sad that the default expectation seems to be "you provide support for me and keep maintaining this thing, and once you can't anymore, you'll find somebody else who does, so that I can keep benefiting for free from all your work".
The default expectation should be that there is nothing promised beyond what's in the license. Anything beyond it needs to be clearly stated, but in the absence of any such statement, don't assume or expect anything.
Note that this expectation is clearly stated in most FOSS licenses. Usually right at the top, IN CAPITAL LETTERS. Having to write an extra blog article that basically says "I really mean what is in the license" is redundant, and it's sad the this has do be done and is even being argued about.
The default expectation should be that there is nothing promised beyond what's in the license. Anything beyond it needs to be clearly stated, but in the absence of any such statement, don't assume or expect anything.
Note that this expectation is clearly stated in most FOSS licenses. Usually right at the top, IN CAPITAL LETTERS. Having to write an extra blog article that basically says "I really mean what is in the license" is redundant, and it's sad the this has do be done and is even being argued about.
I used to maintain several popular open-source projects and contribute to even more popular ones. It was always fun at the beginning, especially because I built them for my own needs. But I kept getting asked to fix bugs or improve things even long after my needs had expired. I tried the donation route for a little while but it didn't go anywhere - I received maybe a few hours worth of money (versus hundreds if not thousands of hours I had spent working on those projects). I also tried releasing a paid version for one of the projects and got buried with hate mails and, unfortunately, online abuse. That was when I stopped working on open-source and I'm happier than ever.
I'm very happy for people who make it from doing serious open-source work. I think they deserve it. But at the same time I feel bad for those who build or maintain no less serious or popular work and yet couldn't make enough to worth even a portion of the time they'd spend.
I'm very happy for people who make it from doing serious open-source work. I think they deserve it. But at the same time I feel bad for those who build or maintain no less serious or popular work and yet couldn't make enough to worth even a portion of the time they'd spend.
The reality is: most companies are taking economic advantage of the generous spirit of open source developers. That needs to stop.
SPONSORING OPEN SOURCE DEVELOPERS Rich Hickey - December 15, 2020 https://cognitect.com/blog/2020/12/15/sponsoring-open-source...
HN Thread here: https://news.ycombinator.com/item?id=25436335
SPONSORING OPEN SOURCE DEVELOPERS Rich Hickey - December 15, 2020 https://cognitect.com/blog/2020/12/15/sponsoring-open-source...
HN Thread here: https://news.ycombinator.com/item?id=25436335
Sponsorship is not a panacea unfortunately as corporate use of a project is not proportional to the maintainership burden. Hopefully the industry can fix this one day.
If you could even get it! Think about all the millions of dollars dealing with the Log4J issues last December. How much has that prompted sponsorship of any logging libraries by the affected companies? Not much, from what I've seen.
I related pretty strongly to this. I've never tried to monetize, and the community I'm mostly working in (ROS) is populated almost exclusively with exactly the sort of kind, considerate people who will happily roll up their sleeves to take a crack at it themselves, given a little guidance.
Nonetheless, there are dozens of effectively abandonware ROS projects out there attached to my name— drivers for some sensor I shipped years ago and haven't touched since, interface libraries that aren't really relevant but don't have a clear alternative, stuff that was never out of the prototype phase and doesn't have anywhere close to the level of test coverage that would let me just merge much less release changes without extensive manual running of it.
I suppose I should go in and just mark them all as archived so that well-meaning people don't file issues (and even PRs) that will never be addressed or perhaps even acknowledged. And in some cases I've just granted PR authors write access and been like "there it's yours now." But none of these end states feel quite right; in all cases I end up feeling guilty and unsatisfied with how it turns out.
Nonetheless, there are dozens of effectively abandonware ROS projects out there attached to my name— drivers for some sensor I shipped years ago and haven't touched since, interface libraries that aren't really relevant but don't have a clear alternative, stuff that was never out of the prototype phase and doesn't have anywhere close to the level of test coverage that would let me just merge much less release changes without extensive manual running of it.
I suppose I should go in and just mark them all as archived so that well-meaning people don't file issues (and even PRs) that will never be addressed or perhaps even acknowledged. And in some cases I've just granted PR authors write access and been like "there it's yours now." But none of these end states feel quite right; in all cases I end up feeling guilty and unsatisfied with how it turns out.
> And in some cases I've just granted PR authors write access and been like "there it's yours now." But none of these end states feel quite right; in all cases I end up feeling guilty and unsatisfied with how it turns out.
What feels wrong with this? Personally I'd much rather hand a project over to someone else than leave it completely archived.
What feels wrong with this? Personally I'd much rather hand a project over to someone else than leave it completely archived.
This has resulted in projects turning to malware multiple times.
It's the ideal outcome, I guess. But a number of projects end up just re-abandoned six months later after the person merged their own thing and pushed a release with it. I guess that's good for having moved it forward at all, but it certainly doesn't feel like a complete solution.
I wonder if such projects should be collaboratively maintained rather than attached to your name? Then anyone who is part of the ROS community and ends up needing them can take on fixing any issues they encounter. As long as the org holding them has a liberal enough membership policy, this should work well.
"It's hard to maintain a project as a single-maintainer. Nobody puts in more than a cursory effort to contribute."
"Yeah, but what if other people contributed?"
It's a huge chicken-or-egg problem.
At this point, unless you have a big name behind you (being a major corporation like Google or Facebook, or OSS celebrity like Torvalds), the chances of any particular project growing beyond single-maintainer are really slim.
I've seen several people, on my own projects and others, talk about not trusting single-maintainer projects to last as a reason to not get involved. It's infuriating, because it's a self-fulfilling prophecy.
And there are no guarantees the major OSS names will perpetuate their projects any better than an independent, no-name, single-maintainer. If anything, I've seen companies like Google drop projects much faster than I've ever done in any of mine.
People see the name and assume there is already support behind the project. Yet often the projects start as a single-maintainer thing that the company then puts a marketing machine behind.
I had a project years ago that was my first promising open source project. It was growing, it had a small handful of minor-but-meaningful contributors. People saw my name on 95% of the commits (I was working on it full-time) and called it single-maintainer. A year after I released, a major corp announced they were releasing a competitor. They hadn't released it yet, just announced. Overnight, I saw interest in my project dry up. It took another year for that other corp to actually releases, during which time they had fewer actual contributors than I had. When they did release, it took another year before they reached feature parity with me, but by that point it didn't matter. They had started telling people they were the first such project ever. Randos online started accusing me of copying the other project. I couldn't keep up with development and marketing on my own, especially after the digital agency I was working on it at went belly up.
I knew most of the people on the team at the major corp. We were in a very niche industry and we all knew each other. I think it was that "ours is the first" bit that really got my goat. They not only knew me and knew about my project, they even admitted they had been using my project for testing compatibility of another project they develop.
Thus I now hate Mozilla with a passion.
"Yeah, but what if other people contributed?"
It's a huge chicken-or-egg problem.
At this point, unless you have a big name behind you (being a major corporation like Google or Facebook, or OSS celebrity like Torvalds), the chances of any particular project growing beyond single-maintainer are really slim.
I've seen several people, on my own projects and others, talk about not trusting single-maintainer projects to last as a reason to not get involved. It's infuriating, because it's a self-fulfilling prophecy.
And there are no guarantees the major OSS names will perpetuate their projects any better than an independent, no-name, single-maintainer. If anything, I've seen companies like Google drop projects much faster than I've ever done in any of mine.
People see the name and assume there is already support behind the project. Yet often the projects start as a single-maintainer thing that the company then puts a marketing machine behind.
I had a project years ago that was my first promising open source project. It was growing, it had a small handful of minor-but-meaningful contributors. People saw my name on 95% of the commits (I was working on it full-time) and called it single-maintainer. A year after I released, a major corp announced they were releasing a competitor. They hadn't released it yet, just announced. Overnight, I saw interest in my project dry up. It took another year for that other corp to actually releases, during which time they had fewer actual contributors than I had. When they did release, it took another year before they reached feature parity with me, but by that point it didn't matter. They had started telling people they were the first such project ever. Randos online started accusing me of copying the other project. I couldn't keep up with development and marketing on my own, especially after the digital agency I was working on it at went belly up.
I knew most of the people on the team at the major corp. We were in a very niche industry and we all knew each other. I think it was that "ours is the first" bit that really got my goat. They not only knew me and knew about my project, they even admitted they had been using my project for testing compatibility of another project they develop.
Thus I now hate Mozilla with a passion.
I'm sorry that happened to you, that is a horrible way to treat people, Mozilla and all open source users and contributors need to do better than that.
Would you allow someone to buy out your repos?
I'm a full-time maintainer that has luckily made it work. Donations don't work. Carving out business specific features and paywalling has worked for me.
But it's not a tenable solution for most projects. I've been thinking about how people in your position can basically "cash out". It is sitting dormant, PR authors are too intimidated by maintenance to take the lead. Maybe some sort of robotics vertical-focussed Private Equity type organization could buy out your project (where you get paid to essentially transfer the repo to their GH org, they would then take up maintenance and monetisation)? Would you accept a deal from them? How much would you ask for one of your popular repos?
I'm a full-time maintainer that has luckily made it work. Donations don't work. Carving out business specific features and paywalling has worked for me.
But it's not a tenable solution for most projects. I've been thinking about how people in your position can basically "cash out". It is sitting dormant, PR authors are too intimidated by maintenance to take the lead. Maybe some sort of robotics vertical-focussed Private Equity type organization could buy out your project (where you get paid to essentially transfer the repo to their GH org, they would then take up maintenance and monetisation)? Would you accept a deal from them? How much would you ask for one of your popular repos?
Once again I wish github would allow the ability to limit who could open issues and PRs in order to do development in the open with a trusted/vetted set of collaborators without being subject to every zero-effort bug report from users.
It would be nice to make the "open source, but closed to contributions/collaborators" model like SQLite and others (lightstream, etc) follow more of a first class citizen on github.
Small sidenote: Litestream loosened their contribution policy, and they now accept bugfixes but not new features:
https://github.com/benbjohnson/litestream#contribution-polic...
https://github.com/benbjohnson/litestream#contribution-polic...
You can already turn on repository interaction limits limiting issues/PRs to collaborators. It needs to be re-enabled every 6 months https://docs.github.com/en/communities/moderating-comments-a...
That isn't the same thing. It is temporary. You can also only limit to existing users (blocking only new GH users which is useless), or limit to contributors (people who have merged commits in the main branch), or limit to users with write access. I want to retain sole write access but allow issues to be cut by trusted users who have never submitted PRs or code. I also want it permanent and not temporary.
It's not the same thing, because of the flow:
- developer finds a cool project - developer consumes the cool project - developer finds opportunity for bug fix or enhancement - developer forks and starts working on the enhancements - developer spends hours/days writing code - developer submits a PR - developer gets a notification (upon filling the PR, or after, from a bot) - developer is now extremely frustrated - developer complains - maintainers and the developer start debating - the Pull Request storm goes viral - developer threatens to stop using cool project - maintainers handle the situation poorly (they are coders, not Public Relations people) - the community makes things worse
And so on...
- developer finds a cool project - developer consumes the cool project - developer finds opportunity for bug fix or enhancement - developer forks and starts working on the enhancements - developer spends hours/days writing code - developer submits a PR - developer gets a notification (upon filling the PR, or after, from a bot) - developer is now extremely frustrated - developer complains - maintainers and the developer start debating - the Pull Request storm goes viral - developer threatens to stop using cool project - maintainers handle the situation poorly (they are coders, not Public Relations people) - the community makes things worse
And so on...
If issues/PRs were limited to collaborators, wouldn't they not be able to submit a PR at all?
Here's how I propose a better PR flow in GitHub:
https://news.ycombinator.com/item?id=30705581
https://news.ycombinator.com/item?id=30705581
Perhaps the developer should have discussed their ideas before investing their time, if they're going to be upset about their unsolicited code being rejected.
The maintainer still has to deal with the negative interaction even if in some cosmic sense the contributor could have known better. A workflow design which ensures that such negative interactions take place is structurally flawed.
what's so negative about pressing the reject button of the PR? The maintainer doesn't have to even spend more than a second rejecting any contributions they get. They don't have to read any of the comments, nor reply to any concerns from the contributors.
The contributors aren't entitled to the time of the maintainers.
The contributors aren't entitled to the time of the maintainers.
I don't understand. You have "developer forks". Everything after that is irrelevant. That's the whole point of open source.
On GitHub a fork is a lightweight thing. People fork the repo in order to contribute because they can't push to the original repo. It's not like you are philosophically against Emacs and decide to fork it to produce XEmacs.
Just as I don't understand the original comment, I also don't understand yours. You don't need to push to the original repo because open source allows you to make your fork available to others. The developer of the original has a right to decide to accept your changes or not, so I fail to see why it matters that your PR isn't accepted.
Just as I don't understand the original comment, I also don't understand yours
The way Github e.a. use forks dilutes the larger meaning of the word, that's what this thread is about. When people used to talk about forks, they always mean a community fracture over differences of opinion: gcc vs egcs, xfree86 vs xorg, ffmpeg vs libav, openwrt vs lede, glibc vs eglibc, kde4 vs trinity, gnome3 vs cinnamon vs mate.
The common-use term of "fork" on github has nothing to do with divergence of development, it's just a band-aid for lack of contributor access control. I can understand why people don't like github's use of forks, and that has nothing to do with what the license "allows" or not: if it's not a divergent development line, it's not a fork, it's a clone at best. In most cases, I'd say it's just a feature branch hosted in a different repository.
Calling something a fork implies long-term viability (or at least the intention) as an alternative to the original repo. That doesn't sound like a realistic description of most cloned repo's on Github to me.
The way Github e.a. use forks dilutes the larger meaning of the word, that's what this thread is about. When people used to talk about forks, they always mean a community fracture over differences of opinion: gcc vs egcs, xfree86 vs xorg, ffmpeg vs libav, openwrt vs lede, glibc vs eglibc, kde4 vs trinity, gnome3 vs cinnamon vs mate.
The common-use term of "fork" on github has nothing to do with divergence of development, it's just a band-aid for lack of contributor access control. I can understand why people don't like github's use of forks, and that has nothing to do with what the license "allows" or not: if it's not a divergent development line, it's not a fork, it's a clone at best. In most cases, I'd say it's just a feature branch hosted in a different repository.
Calling something a fork implies long-term viability (or at least the intention) as an alternative to the original repo. That doesn't sound like a realistic description of most cloned repo's on Github to me.
> The common-use term of "fork" on github [i]s just a band-aid for lack of contributor access control
More accurately: it's a consequence of GitHub's early decision to reject the traditional currency of open source (patches) in favor of imposing dark pattern-infested workflows on hosted projects and their contributors.
When you accept patches, anyone can easily create an account, submit their patch, and then be on their way. GitHub's opting for an unnecessarily heavyweight pull request workflow instead, though, meant that contributors were required to set up a personal on-GitHub copy of the desired repo, point their copy on their local machine at that as a remote, and push to it. At that point, they're already paying the cost of project hosting overheads just for contributing to a project that isn't theirs. When it comes time to start their own project, or evaluate whether it's worth it to continue hosting their existing projects elsewhere, pressure to choose GitHub cones into play that wouldn't otherwise if there were a level playing field. Fast forward nearly 15 years of network effects, and you have it as a nearly unavoidable multi-billion dollar behemoth.
It's such a transparent growth hack inspired by the underhanded tactics used by social networks that folks' unwillingness to even acknowledge its negative impact on productivity and privacy is really infuriating—not to mention the negative impact itself.
More accurately: it's a consequence of GitHub's early decision to reject the traditional currency of open source (patches) in favor of imposing dark pattern-infested workflows on hosted projects and their contributors.
When you accept patches, anyone can easily create an account, submit their patch, and then be on their way. GitHub's opting for an unnecessarily heavyweight pull request workflow instead, though, meant that contributors were required to set up a personal on-GitHub copy of the desired repo, point their copy on their local machine at that as a remote, and push to it. At that point, they're already paying the cost of project hosting overheads just for contributing to a project that isn't theirs. When it comes time to start their own project, or evaluate whether it's worth it to continue hosting their existing projects elsewhere, pressure to choose GitHub cones into play that wouldn't otherwise if there were a level playing field. Fast forward nearly 15 years of network effects, and you have it as a nearly unavoidable multi-billion dollar behemoth.
It's such a transparent growth hack inspired by the underhanded tactics used by social networks that folks' unwillingness to even acknowledge its negative impact on productivity and privacy is really infuriating—not to mention the negative impact itself.
“Feature branch hosted in a separate repository” is a very good way of putting it.
> I fail to see why it matters that your PR isn't accepted.
Making their code useful to other people is a strong motivator for many altruistic open source developers.
The purpose of getting PRs accepted upstream is so that your changes are useful in concert with other people's changes, especially their later changes.
Your private change is of little use to others when it's only in your private fork, which hardly anyone knows about, and if they do know, your change is incompatible with later work and maintenance by other people anyway.
If you don't care whether anyone else uses your work, especially in future, that's fine. But if you want it to be more useful to others, getting it merged upstream makes a huge difference to that.
(Merging upstream or just submitting PRs that don't get merged also helps personal visibility and reputation, which is undoubtedly a motivator for many. That's a burden on upstream maintainers when someone is pushing low quality work and doesn't care to ensure it's useful to the project.)
Making their code useful to other people is a strong motivator for many altruistic open source developers.
The purpose of getting PRs accepted upstream is so that your changes are useful in concert with other people's changes, especially their later changes.
Your private change is of little use to others when it's only in your private fork, which hardly anyone knows about, and if they do know, your change is incompatible with later work and maintenance by other people anyway.
If you don't care whether anyone else uses your work, especially in future, that's fine. But if you want it to be more useful to others, getting it merged upstream makes a huge difference to that.
(Merging upstream or just submitting PRs that don't get merged also helps personal visibility and reputation, which is undoubtedly a motivator for many. That's a burden on upstream maintainers when someone is pushing low quality work and doesn't care to ensure it's useful to the project.)
Maintaining a fork and maintaining a single feature of a project are two different levels of commitment and you can want to do one without doing the other although all too often people want to contribute a feature and then not provide support for it and expect the project maintainer to now maintain the contributed code. But that's a different issue (and why many maintainers sometimes don't accept random PR's even if the code itself is fine).
> You don't need to push to the original repo because open source allows you to make your fork available to others.
This is simply not true - not all open source software is copyleft. You can have restrictive licensing regarding use and/or distribution and still be open source.
> You don't need to push to the original repo because open source allows you to make your fork available to others.
This is simply not true - not all open source software is copyleft. You can have restrictive licensing regarding use and/or distribution and still be open source.
> This is simply not true - not all open source software is copyleft. You can have restrictive licensing regarding use and/or distribution and still be open source.
Well, of course you can adopt any definition of "open source" you want, but I'm using the OSI definition, which states:
"The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software."
You are referring to "source available", for which they offer the clarification:
"Open source doesn't just mean access to the source code."
Well, of course you can adopt any definition of "open source" you want, but I'm using the OSI definition, which states:
"The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software."
You are referring to "source available", for which they offer the clarification:
"Open source doesn't just mean access to the source code."
There is a reason FLOSS exists as a term to differentiate itself from OSS and I think the ideological differences between the two are important. So does Bruce Perens, the co-founder of OSI and the author of the Debian Social Contract of which the OSI definition was based off: https://web.archive.org/web/20140716055445/https://lists.deb...
This was back in 1999 - it's been over 20 years and "OSS" has only been muddied further and further to mean "source available" since.
Pedantry aside tremon's response sums it up well: "Feature branch hosted in a separate repository."
This was back in 1999 - it's been over 20 years and "OSS" has only been muddied further and further to mean "source available" since.
Pedantry aside tremon's response sums it up well: "Feature branch hosted in a separate repository."
Where is this muddying happening? The only place I've noticed it is on HN, where others always correct the poster by pointing at the Open Source Definition.
Maybe it is time to ditch both "open source" and "free software" and go with something that has a clear meaning that isn't possible to muddy, like "libre software", prefixed with "always" for copyleft licenses and "currently" for permissive ones.
Maybe it is time to ditch both "open source" and "free software" and go with something that has a clear meaning that isn't possible to muddy, like "libre software", prefixed with "always" for copyleft licenses and "currently" for permissive ones.
Those who sit on the Open Source side of things constantly muddy the waters and claim they are one in the same. Those who sit on the Free Software side of things are adamant that they are related but different.
https://www.gnu.org/philosophy/open-source-misses-the-point....
The important bit is here:
> “Free” and “open” are rivals for mindshare. Free software and open source are different ideas but, in most people's way of looking at software, they compete for the same conceptual slot. When people become habituated to saying and thinking “open source,” that is an obstacle to their grasping the free software movement's philosophy and thinking about it.
https://www.gnu.org/philosophy/open-source-misses-the-point....
The important bit is here:
> “Free” and “open” are rivals for mindshare. Free software and open source are different ideas but, in most people's way of looking at software, they compete for the same conceptual slot. When people become habituated to saying and thinking “open source,” that is an obstacle to their grasping the free software movement's philosophy and thinking about it.
I meant to ask who is muddying the waters by claiming that "open source" == "source available" rather than the Open Source Definition published by OSI?
The post you cite by Perens doesn't seem to mention the term "FLOSS" (or spelled out), right?
I have seen "FLOSS" used as an umbrella term for ALL of it, that is anything that is open source is also "FLOSS". But you are saying it exists to differentiate from "open source"? Huh. Just to muddy the waters yet further.
I have seen "FLOSS" used as an umbrella term for ALL of it, that is anything that is open source is also "FLOSS". But you are saying it exists to differentiate from "open source"? Huh. Just to muddy the waters yet further.
It doesn't use the term directly, no. Because to hackers, especially back in 1999, Free and Open Source were one in the same. It was just a difference of branding. However Bruce differentiates between "Open Source" and "Free Software" in writing and he only does so because public perception of what "Open Source" actually means had already been muddied in the year since OSI's founding and the freedoms afforded by FLOSS were already being de-emphasized and put on the back burner.
To quote Bruce:
> Most hackers know that Free Software and Open Source are just two words for the same thing. Unfortunately, though, Open Source has de-emphasized the importance of the freedoms involved in Free Software.....
> ......Sadly, as I've tended toward promotion of Free Software rather than Open Source, Eric Raymond seems to be losing his free software focus. The Open Source certification mark has already been abused in ways I find unconscionable and that I will not abide. I fear that the Open Source Initiative is drifting away from the Free Sofware values with which we originally created it.
There would be no need to make any kind of distinction between Free Software and Open Source if Open Source was being perceived as Free Software.
OSI was and always will be a marketing gimmick [0] created to sell the idea of open source to commercially interested parties.
> We realized that the Netscape announcement had created a precious window of time within which we might finally be able to get the corporate world to listen to what we have to teach about the superiority of an open development process. We realized it was time to dump the confrontational attitude that has been associated with `free software' in the past and sell the idea strictly on the same pragmatic, business-case grounds that motivated Netscape. We brainstormed about tactics and a new label. Open source, contributed by Chris Peterson, was the best thing we came up with.
Not to downplay OSI at all. It was extremely important and widely influential in Netscape's journey to becoming Firefox and I'd even argue is still important today. But the issue centered around what "Free" means ("Free" as in freedom - not beer - which is why the term "libre" is often used as well) and that "Free Software" already had a poor reputation in the business world and so it needed to be rebranded. Eric Raymond made it very clear that he places importance on phrasing and branding and attributes the tactics used by OSI to its success and why the Free Software movement failed. [1]
Honestly a comment by Havoc Pennington on that very post, dated Jun 28, 1999, sums up the issue perfectly.
>I think Eric's analysis of the facts is basically right. i.e. the "open source as business" stuff has gotten us a lot of popularity. The danger is that we fall for our own marketing program. That is, new community members join, and we have to say "we didn't really mean that. Really we meant freedom. The business stuff is for the suits." An increasing number of new members just don't understand freedom, or copyright, or anything like that; they joined "Linux," not "GNU."
[0] http://web.archive.org/web/19981206185148/http://www.opensou...
[1] https://web.archive.org/web/20170630183629/http://www.linuxt...
To quote Bruce:
> Most hackers know that Free Software and Open Source are just two words for the same thing. Unfortunately, though, Open Source has de-emphasized the importance of the freedoms involved in Free Software.....
> ......Sadly, as I've tended toward promotion of Free Software rather than Open Source, Eric Raymond seems to be losing his free software focus. The Open Source certification mark has already been abused in ways I find unconscionable and that I will not abide. I fear that the Open Source Initiative is drifting away from the Free Sofware values with which we originally created it.
There would be no need to make any kind of distinction between Free Software and Open Source if Open Source was being perceived as Free Software.
OSI was and always will be a marketing gimmick [0] created to sell the idea of open source to commercially interested parties.
> We realized that the Netscape announcement had created a precious window of time within which we might finally be able to get the corporate world to listen to what we have to teach about the superiority of an open development process. We realized it was time to dump the confrontational attitude that has been associated with `free software' in the past and sell the idea strictly on the same pragmatic, business-case grounds that motivated Netscape. We brainstormed about tactics and a new label. Open source, contributed by Chris Peterson, was the best thing we came up with.
Not to downplay OSI at all. It was extremely important and widely influential in Netscape's journey to becoming Firefox and I'd even argue is still important today. But the issue centered around what "Free" means ("Free" as in freedom - not beer - which is why the term "libre" is often used as well) and that "Free Software" already had a poor reputation in the business world and so it needed to be rebranded. Eric Raymond made it very clear that he places importance on phrasing and branding and attributes the tactics used by OSI to its success and why the Free Software movement failed. [1]
Honestly a comment by Havoc Pennington on that very post, dated Jun 28, 1999, sums up the issue perfectly.
>I think Eric's analysis of the facts is basically right. i.e. the "open source as business" stuff has gotten us a lot of popularity. The danger is that we fall for our own marketing program. That is, new community members join, and we have to say "we didn't really mean that. Really we meant freedom. The business stuff is for the suits." An increasing number of new members just don't understand freedom, or copyright, or anything like that; they joined "Linux," not "GNU."
[0] http://web.archive.org/web/19981206185148/http://www.opensou...
[1] https://web.archive.org/web/20170630183629/http://www.linuxt...
Y'all are talking about possibly three different things.
"Source available" does not mean anything about a license at all. It literally just means the source is available... to someone.
Open source generally means it must have a license that allows modifications and derived works. It is more than "source available" it means that a public license to use and redistribute the software is available. "source available" does not necessarily mean you have a free license to use or distribute the software, or modify it and distribute the modifications. "open source" does. The Open Source Institute has tried to standardize a definition. https://opensource.org/osd
"copyleft" is sometimes used to mean something more than some "open source". Richard Stallman has promoted these sense of "copyleft". Like GNU license as opposed to apache. Both are open source -- nobody says apache license isn't open source right? Open source licenses that aren't "copyleft" are sometimes called "permissive". Here's one description of it that will suffice:
> 3. Is the Apache considered copyleft?
> Copyleft licenses require the derivative works or modified versions of existing software to be released under the same license. The Apache License doesn’t have any such requirements. It’s a permissive license. It permits you to release the modified parts of the code under any license of your choice. However, you are required to release all the unmodified parts of the software under the same license (the Apache License).
--https://www.whitesourcesoftware.com/resources/blog/top-10-ap...
So, no, "source available" is definitely not the same thing as "open source" -- all open source may be "source available", but things described as just "source available" usually are not open source. The source might be available to you, but you might not be allowed to use it (at all, or in certain ways) without paying, and you might not be allowed to redistribute derived works.
And "copyleft" is usually used as a subset of "open source", for restrictive/"viral" licenses.
I have no idea what any of this has to do with where this discussion began -- but yes, anything that's open source, copyleft or not, gives you the right to make a variaton of the software, use that variation, and distribute it. I think that is part of the accepted definition of open source. "Source available" software may not give you this right.
"Source available" does not mean anything about a license at all. It literally just means the source is available... to someone.
Open source generally means it must have a license that allows modifications and derived works. It is more than "source available" it means that a public license to use and redistribute the software is available. "source available" does not necessarily mean you have a free license to use or distribute the software, or modify it and distribute the modifications. "open source" does. The Open Source Institute has tried to standardize a definition. https://opensource.org/osd
"copyleft" is sometimes used to mean something more than some "open source". Richard Stallman has promoted these sense of "copyleft". Like GNU license as opposed to apache. Both are open source -- nobody says apache license isn't open source right? Open source licenses that aren't "copyleft" are sometimes called "permissive". Here's one description of it that will suffice:
> 3. Is the Apache considered copyleft?
> Copyleft licenses require the derivative works or modified versions of existing software to be released under the same license. The Apache License doesn’t have any such requirements. It’s a permissive license. It permits you to release the modified parts of the code under any license of your choice. However, you are required to release all the unmodified parts of the software under the same license (the Apache License).
--https://www.whitesourcesoftware.com/resources/blog/top-10-ap...
So, no, "source available" is definitely not the same thing as "open source" -- all open source may be "source available", but things described as just "source available" usually are not open source. The source might be available to you, but you might not be allowed to use it (at all, or in certain ways) without paying, and you might not be allowed to redistribute derived works.
And "copyleft" is usually used as a subset of "open source", for restrictive/"viral" licenses.
I have no idea what any of this has to do with where this discussion began -- but yes, anything that's open source, copyleft or not, gives you the right to make a variaton of the software, use that variation, and distribute it. I think that is part of the accepted definition of open source. "Source available" software may not give you this right.
You don't need to use github, especially when you don't want the public making issues.
800# gorilla. don't think gitlab supports this either. that probably leaves self-hosting and all the brittleness and pain around that.
An aside, but is it a standard thing to write # to mean "pound" when you're talking about pounds as a unit of weight? Like as opposed to "800lb"? I knew what you meant, it's just I've never seen that notation before so I'm wondering if you just made it up or if I'm out of the loop somehow.
Using hash-mark to mean “pounds” goes back to 1850 at least.
https://en.m.wikipedia.org/wiki/Number_sign
A few decades ago, it was very common to see at the deli counter, in the handwritten prices on signs jabbed into lunch meats and such. And on the price signs above the vegetable bins at the supermarket. In the US, anyway.
https://en.m.wikipedia.org/wiki/Number_sign
A few decades ago, it was very common to see at the deli counter, in the handwritten prices on signs jabbed into lunch meats and such. And on the price signs above the vegetable bins at the supermarket. In the US, anyway.
Correct, there's no way to restrict GitLab merge requests to trusted users, while still allowing others to view merge requests. It's either visible/accessible to all, or only to project members.
GitLab can have this “feature” if the accounts are locked behind an entity like a school which doesn’t allow arbitrary users to make a new account
I'm also not enamored of the fact that you can log into Github/Gitlab/etc. with accounts from everywhere (Gmail/Facebook/Twitter/etc.).
I suspect that making someone go through the signup dance stopped a LOT of the worst level of morons.
Is there a code hosting service that allows public viewing but still forces people to sign up for an account before being able to do actions?
I suspect that making someone go through the signup dance stopped a LOT of the worst level of morons.
Is there a code hosting service that allows public viewing but still forces people to sign up for an account before being able to do actions?
Where do you see the ability to open issues and pull requests by signing in with Google without creating a GitHub account?
Maybe sourcehut?
Bots that close or even delete issues where the issue template hasn't been filled in help a lot.
I'm shocked that it doesn't. What would you do if you were being harassed?
You can block specific users and you can temporarily limit all interactions if getting spammed.
I had a very similar experience with running open source projects. I was getting frustrated with people not contributing in any significant way. Functionally useless bug reports. Coding bootcamp students submitting PRs that did nothing but change some grammar in the README (and never actually changing it correctly). Feature requests for things I had explained in several other issues that I would never do. Requests for support in setting up other people's software.
But if people are contacting me about my project, they must be using it, right? Isn't that the point? Can't I just ignore the noise? What's the problem?
I eventually realized my motivations for developing open source software were rooted in vanity. Just making programs is something I do all the time, I find it very rewarding. But the part about open sourcing it, that was the vanity.
Before opening the project, nobody else was contributing anything to it, either. After opening it, all that changed was that my expectations for how people would react to it were not met. Expecting people to want to use my software in exactly the way I wanted was a hell of a lot of arrogance. Those people who were requesting features, they weren't "wrong", they just wanted different software. More like a service that did the things my software could enable, rather than building things with my software.
I don't write the software to get rich or escape a dead-end job. I used to have that fantasy, but nowadays life is pretty happy, and I also have realized the fantasy was always a myth, anyway. So in the end, the difference between writing software and writing open source software is nothing more than me wanting recognition for the thing I created; aka a vain search for glory.
I didn't like that view of myself, so I stopped opening my software.
But if people are contacting me about my project, they must be using it, right? Isn't that the point? Can't I just ignore the noise? What's the problem?
I eventually realized my motivations for developing open source software were rooted in vanity. Just making programs is something I do all the time, I find it very rewarding. But the part about open sourcing it, that was the vanity.
Before opening the project, nobody else was contributing anything to it, either. After opening it, all that changed was that my expectations for how people would react to it were not met. Expecting people to want to use my software in exactly the way I wanted was a hell of a lot of arrogance. Those people who were requesting features, they weren't "wrong", they just wanted different software. More like a service that did the things my software could enable, rather than building things with my software.
I don't write the software to get rich or escape a dead-end job. I used to have that fantasy, but nowadays life is pretty happy, and I also have realized the fantasy was always a myth, anyway. So in the end, the difference between writing software and writing open source software is nothing more than me wanting recognition for the thing I created; aka a vain search for glory.
I didn't like that view of myself, so I stopped opening my software.
> I eventually realized my motivations for developing open source software were rooted in vanity.
Very insightful, but is it in fact a slightly different emotion to that?
In the Mythical Man Month, Fred Brooks says:
> Why is programming fun? What delights may its practitioner expect as his reward? First [..]
> Second is the pleasure of making things that are useful to other people. Deep within, we want others to use our work and to find it helpful. In this respect the programming system is not essentially different from the child’s first clay pencil holder “for Daddy’s office.”
I don't know if this is quite vanity. That sounds a bit too negative. Is this the kind of complex emotion that Germans would have a word for but not English?
Very insightful, but is it in fact a slightly different emotion to that?
In the Mythical Man Month, Fred Brooks says:
> Why is programming fun? What delights may its practitioner expect as his reward? First [..]
> Second is the pleasure of making things that are useful to other people. Deep within, we want others to use our work and to find it helpful. In this respect the programming system is not essentially different from the child’s first clay pencil holder “for Daddy’s office.”
I don't know if this is quite vanity. That sounds a bit too negative. Is this the kind of complex emotion that Germans would have a word for but not English?
For the vast majority of people, a program being open source does not make it more useful to them. The program just existing is the useful bit.
Also, Germans don't have words for things. They just remove all the whitespace from their sentences and then run around, "look at this neues word Ich hab!" :D
Also, Germans don't have words for things. They just remove all the whitespace from their sentences and then run around, "look at this neues word Ich hab!" :D
> I don't know if this is quite vanity. That sounds a bit too negative. Is this the kind of complex emotion that Germans would have a word for but not English?
I'd say the need for validation describes that closely enough.
I'd say the need for validation describes that closely enough.
> I eventually realized my motivations for developing open source software were rooted in vanity.
Bingo. The hard-earned wisdom of this insight right here almost completely explains all the internal issues the OP was feeling when he wrote his rather over-the-top post.
Yeah, it sucks to realize that your just as human as the next guy and that your motives aren't always as pure as you wish they were, but there is nothing at all wrong with being proud and wanting to be noticed for abilities.
Figuring out what path works for you AFTER realizing your motives aren't pure is how one solves the open-source user issue.
Bingo. The hard-earned wisdom of this insight right here almost completely explains all the internal issues the OP was feeling when he wrote his rather over-the-top post.
Yeah, it sucks to realize that your just as human as the next guy and that your motives aren't always as pure as you wish they were, but there is nothing at all wrong with being proud and wanting to be noticed for abilities.
Figuring out what path works for you AFTER realizing your motives aren't pure is how one solves the open-source user issue.
You’re saying no one uses your software whether it’s open or closed, you just got annoying “contributions”. How did you know no one was using it? How would you know if someone was?
No, I didn't say people weren't using the software. I could see that in a lot of different ways: how many people were active on the project site, how many people had forked the project on github, etc.
My point was that my reaction to things like feature requests I didn't want to build was a signal that I wasn't interested in building just a user base for the project. If what I were interested in were building a project that people wanted to use, could sell to them, etc., then I would discard my notions about what I wanted to build and I'd build what people wanted. That was the epiphany I had. I realized I had been lying to myself about my motivations. I realized that my actions proved I didn't really care about getting people to just use the software.
Because I was so annoyed by the lack of contribution, despite the obvious signals that people were using the software, I (eventually) realized that my true goal was for people to interact with my code, not my program. There's a difference there. Any feature in a program can be implemented in any number of ways. But there's necessarily only one way that it's implemented in my program. Thus to be more focused on contributions than usage implies that I care more about how people see my implementation of the features than the features themselves.
I didn't start these projects thinking, "let me make a thing that will prove my prowess as a developer". I made the things to scratch some personal itch. The software on its own fulfills that particular need.
The act of open sourcing it was a different thing entirely. It's not trivial to open source a project; there's a lot of work in trying to prepare it for use by other people. Why go through all of that? What need did I expect opening the code to fulfill for me? Opening code doesn't attract users. So few users care if a project is open or not that they can safely be ignored as a rounding error. So why focus time on opening the code, verus any other action I could take with my time?
Thus the realization that I had been deluding myself.
My point was that my reaction to things like feature requests I didn't want to build was a signal that I wasn't interested in building just a user base for the project. If what I were interested in were building a project that people wanted to use, could sell to them, etc., then I would discard my notions about what I wanted to build and I'd build what people wanted. That was the epiphany I had. I realized I had been lying to myself about my motivations. I realized that my actions proved I didn't really care about getting people to just use the software.
Because I was so annoyed by the lack of contribution, despite the obvious signals that people were using the software, I (eventually) realized that my true goal was for people to interact with my code, not my program. There's a difference there. Any feature in a program can be implemented in any number of ways. But there's necessarily only one way that it's implemented in my program. Thus to be more focused on contributions than usage implies that I care more about how people see my implementation of the features than the features themselves.
I didn't start these projects thinking, "let me make a thing that will prove my prowess as a developer". I made the things to scratch some personal itch. The software on its own fulfills that particular need.
The act of open sourcing it was a different thing entirely. It's not trivial to open source a project; there's a lot of work in trying to prepare it for use by other people. Why go through all of that? What need did I expect opening the code to fulfill for me? Opening code doesn't attract users. So few users care if a project is open or not that they can safely be ignored as a rounding error. So why focus time on opening the code, verus any other action I could take with my time?
Thus the realization that I had been deluding myself.
> Because I was so annoyed by the lack of contribution, despite the obvious signals that people were using the software, I (eventually) realized that my true goal was for people to interact with my code, not my program.
That's a neat observation. My theory -- hard to prove -- would be that if you leave the code open for long enough (regardless or not of whether you pay attention to contributions, and how many of them there are), you'll find some keen soul further down the road who finds and repairs some kind of compatibility issue, security/privacy problem, or similar.
> So few users care if a project is open or not that they can safely be ignored as a rounding error.
I can near-guarantee that for users who understand that software can do whatever it wants on their system, within the capabilities of the runtime environment and as instructed, then when those users are provided with the option to be able to see the corresponding code or not, they'll choose to have it available to them. In an enterprise context: it can sway vendor selection.
That's an increasing percentage of users today, I think. Perhaps it was the case a decade or two ago that people thought of software as windowed applications on their desktop; nowadays I reckon that more people have software developers within their extended social networks, and from that exposure they have a little bit more of a sense for how computers and code work.
And in response to one of your parent comments:
> I didn't like that view of myself, so I stopped opening my software.
Totally understandable. Don't forget the fact that you have an opportunity (not a responsibility, by any means) to teach and share code with current and future generations of developers.
They might discover some relevant snippet of yours through code search and find exactly what they need to solve a problem. Perhaps they'll credit you; perhaps they won't (perhaps they won't realize or be in the mindset that it's worthwhile (and/or important) to credit people for their work) - either way you'll have helped someone with their day.
That's a neat observation. My theory -- hard to prove -- would be that if you leave the code open for long enough (regardless or not of whether you pay attention to contributions, and how many of them there are), you'll find some keen soul further down the road who finds and repairs some kind of compatibility issue, security/privacy problem, or similar.
> So few users care if a project is open or not that they can safely be ignored as a rounding error.
I can near-guarantee that for users who understand that software can do whatever it wants on their system, within the capabilities of the runtime environment and as instructed, then when those users are provided with the option to be able to see the corresponding code or not, they'll choose to have it available to them. In an enterprise context: it can sway vendor selection.
That's an increasing percentage of users today, I think. Perhaps it was the case a decade or two ago that people thought of software as windowed applications on their desktop; nowadays I reckon that more people have software developers within their extended social networks, and from that exposure they have a little bit more of a sense for how computers and code work.
And in response to one of your parent comments:
> I didn't like that view of myself, so I stopped opening my software.
Totally understandable. Don't forget the fact that you have an opportunity (not a responsibility, by any means) to teach and share code with current and future generations of developers.
They might discover some relevant snippet of yours through code search and find exactly what they need to solve a problem. Perhaps they'll credit you; perhaps they won't (perhaps they won't realize or be in the mindset that it's worthwhile (and/or important) to credit people for their work) - either way you'll have helped someone with their day.
Some licenses may require build instructions, but if all you want is to open your source code so that other people can read it, you can just do that. Remove secrets, publish the code, and you're done.
People can figure out how to build it if they want, it's not your problem or responsibility unless you want it to be.
See Keybase or Signal for instance.
People can figure out how to build it if they want, it's not your problem or responsibility unless you want it to be.
See Keybase or Signal for instance.
Open Source licenses are not about entitlement to contributions, engagement with the maintainers, or even community building. Open Source license is exclusively about the software. But the "Open Source Movement" is blending over, and that's what is burning out so many people on both sides: maintainers and contributors. GitHub's Pull Request feature creates an expectation that the maintainers will read a contributor's code, whether they had discussed about it or not.
Back in the days of SourceForge, open source software would be simply put for download. Anyone willing to collaborate, often times would first engage in the mailing lists or forums. That is not what GH Pull Requests do though, but quite the opposite. It builds on the idea that it is easier to discuss by showing code than by exchanging words. But that's just not how it works for anything beyond trivial/typo fixes. And that just frustrates everyone.
This is the flow I'd like to see GitHub allowing maintainers to choose, in addition to leaving today's flow as default:
- Allow maintainer to disable Pull Requests just like they can disable Issues/Discussions
- Allow maintainer to "Open Issue for Pull Requests"
This basically means that Pull Requests are on a per-issue basis, not per-repo. And only if the maintainers open said issue for accepting Pull Requests. This would push the contributors to first dialogue and discuss the enhancements/bugs before wasting any time writing code thay may never be accepted.
This flow would be much better for setting the right expectations, in my opinion.
Back in the days of SourceForge, open source software would be simply put for download. Anyone willing to collaborate, often times would first engage in the mailing lists or forums. That is not what GH Pull Requests do though, but quite the opposite. It builds on the idea that it is easier to discuss by showing code than by exchanging words. But that's just not how it works for anything beyond trivial/typo fixes. And that just frustrates everyone.
This is the flow I'd like to see GitHub allowing maintainers to choose, in addition to leaving today's flow as default:
- Allow maintainer to disable Pull Requests just like they can disable Issues/Discussions
- Allow maintainer to "Open Issue for Pull Requests"
This basically means that Pull Requests are on a per-issue basis, not per-repo. And only if the maintainers open said issue for accepting Pull Requests. This would push the contributors to first dialogue and discuss the enhancements/bugs before wasting any time writing code thay may never be accepted.
This flow would be much better for setting the right expectations, in my opinion.
> GitHub's Pull Request feature creates an expectation that the maintainers will read a contributor's code
> Back in the days of SourceForge...
Strongly agree. The github PR is a somewhat toxic misfeature. The last thing I want in my open source projects is some rando sending some huge diff that does who knows what. Now I'm supposed to read and understand this code and figure out all the unintended side effects? And even if the code is ok it's probably missing test coverage, doc updates, etc. So filling the gaps would generate more work for me.
However, I do like and accept tiny PRs that fix very targeted things.
I wish I could put a size limit on PR diffs in github. Something like if the PR changes more than 10 lines of code, block it. File a ticket instead of discuss the proposal, don't blast me with code I don't have time to read.
> Back in the days of SourceForge...
Strongly agree. The github PR is a somewhat toxic misfeature. The last thing I want in my open source projects is some rando sending some huge diff that does who knows what. Now I'm supposed to read and understand this code and figure out all the unintended side effects? And even if the code is ok it's probably missing test coverage, doc updates, etc. So filling the gaps would generate more work for me.
However, I do like and accept tiny PRs that fix very targeted things.
I wish I could put a size limit on PR diffs in github. Something like if the PR changes more than 10 lines of code, block it. File a ticket instead of discuss the proposal, don't blast me with code I don't have time to read.
There is one way to disable pull requests on GitHub: enabling "interaction limits" on the repository. The gotchas are that it disables all interactions, not just pull requests, and it can only be enabled for 6 months at a time.
GitHub should have an option to disable PRs for a repo, however:
- Owners are of no obligation to approve, close, merge, or interact with a PR in any way. If you don’t want to merge a PR, just don’t.
- you can include a readme which can include whatever discouragement you want.
- if you have a CONTRIBUTORS.md file, GitHub will show that to first time contributors when they submit a PR.
- I’m sure you could trivially have a GitHub action that will auto close all PRs as soon as they’re submitted.
- Owners are of no obligation to approve, close, merge, or interact with a PR in any way. If you don’t want to merge a PR, just don’t.
- you can include a readme which can include whatever discouragement you want.
- if you have a CONTRIBUTORS.md file, GitHub will show that to first time contributors when they submit a PR.
- I’m sure you could trivially have a GitHub action that will auto close all PRs as soon as they’re submitted.
All of that imply that contributors will read things before hitting the Fork button.
And everything (besides ignoring PRs) requires content to be explicitly added to the repository to configure GitHub's behavior. For some use cases -- like mirrors of repositories hosted elsewhere -- this isn't possible.
If someone's not going to bother themselves with checking the readme or contributors guide before submitting a PR, then they shouldn't be bothered by their PR being ignored or rejected.
What I described is what I believe GitHub should support. Not that they support it today.
Right, I mean that there is a (caveat-ridden) workaround as it stands. I agree that repository maintainers should have the option to restrict or disable pull requests, just like they can disable other features.
It would be super nice if new issues (and PRs) could be made hidden from non-repo-members by default until they're triaged by a repo member (or until some timeout passes without the issue being closed/deleted).
There is a lot of performative abuse on github, where someone opens an ill-tempered or outright misleading issue, and hurls insults and then takes to twitter or reddit to try to get people to pile on, or they complain that their wall of invective was just summarily closed. And when you do ban people on github it has all kinds of weird side effects like blocking them from commenting on other project's issues where you're active.
In general, GH makes it really hard to ghost people. There have always been people who through personality or situation were unable to participate productively. Under older models of communication it was easy to simply ignore these unproductive actions without initiating any visible response that would trigger retaliation or fixation.
There is a lot of performative abuse on github, where someone opens an ill-tempered or outright misleading issue, and hurls insults and then takes to twitter or reddit to try to get people to pile on, or they complain that their wall of invective was just summarily closed. And when you do ban people on github it has all kinds of weird side effects like blocking them from commenting on other project's issues where you're active.
In general, GH makes it really hard to ghost people. There have always been people who through personality or situation were unable to participate productively. Under older models of communication it was easy to simply ignore these unproductive actions without initiating any visible response that would trigger retaliation or fixation.
This is a great write up of just some of the challenges that open source project creators face.
I see a lot of people on this thread of calling for modifications to githubs systems. I really don't see them doing that.
maybe I misunderstand GitHub but as much as I like, enjoy and benefit from GitHub I just think their mission is to cater to the long tail as much as possible. and well maybe somewhat controversial I don't actually think their main play is enabling seamless collaboration I think that's just sort of a necessity for what they're really trying to do. I'm not sure what they're really trying to do but one can imagine there must be some sort of profitable businesses where you have all the world's developers on your system.
I think basically GitHub still wants to create a very sort of simple consumer focus product to maximize the quantity of interactions. they're not necessarily trying to lock down and restrict all those things you know and and and provide tools to upregulate the quality of that.
I'm sure that is a misrepresentation of only a small slice of github's strategy, but anyway I think it's an interesting thing to consider. I just basically don't see them landing a whole lot of features that provide really granular controls to all this stuff because I think they'd be worried that this is going to get in the way of the sort of simple understanding of the uniformity of their product and it's going to cause too much you know confusion and raise the barriers to long tail large quantity collaboration.
I could be totally misreading them but that's my feeling about it.
I see a lot of people on this thread of calling for modifications to githubs systems. I really don't see them doing that.
maybe I misunderstand GitHub but as much as I like, enjoy and benefit from GitHub I just think their mission is to cater to the long tail as much as possible. and well maybe somewhat controversial I don't actually think their main play is enabling seamless collaboration I think that's just sort of a necessity for what they're really trying to do. I'm not sure what they're really trying to do but one can imagine there must be some sort of profitable businesses where you have all the world's developers on your system.
I think basically GitHub still wants to create a very sort of simple consumer focus product to maximize the quantity of interactions. they're not necessarily trying to lock down and restrict all those things you know and and and provide tools to upregulate the quality of that.
I'm sure that is a misrepresentation of only a small slice of github's strategy, but anyway I think it's an interesting thing to consider. I just basically don't see them landing a whole lot of features that provide really granular controls to all this stuff because I think they'd be worried that this is going to get in the way of the sort of simple understanding of the uniformity of their product and it's going to cause too much you know confusion and raise the barriers to long tail large quantity collaboration.
I could be totally misreading them but that's my feeling about it.
Is this kind of burnout perhaps in part due to the level of mechanization provided by the defacto platform for open source projects now: GitHub?
It seems like it’s more frequent, but maybe that’s just me.
It’s great that GitHub exists and lowers the barrier for anyone to develop and share open source efforts. But you also become a slave to its various very well automated processes. As a creative altruistic agent, that can actually take a lot of the fun out of it. And make one feel trapped by the process machine.
It seems in old days, when things were less standardized, maintainers had more creative control over not only the code, but the process/community around it.
I’m not advocating for a demise of GitHub. Just kind of wondering if this is the price we pay.
It seems like it’s more frequent, but maybe that’s just me.
It’s great that GitHub exists and lowers the barrier for anyone to develop and share open source efforts. But you also become a slave to its various very well automated processes. As a creative altruistic agent, that can actually take a lot of the fun out of it. And make one feel trapped by the process machine.
It seems in old days, when things were less standardized, maintainers had more creative control over not only the code, but the process/community around it.
I’m not advocating for a demise of GitHub. Just kind of wondering if this is the price we pay.
Cultural norms around Slack / Discord (compared to the IRC of old) are also to blame. With email, people understand that there is a reply and that process takes time. Discord and Slack encourage people to keep the apps running, continually sapping time and energy.
The best thing a project can do to address burnout is to eliminate any sort of messaging option. Keep all discussions to the issue tracker and email.
The best thing a project can do to address burnout is to eliminate any sort of messaging option. Keep all discussions to the issue tracker and email.
Yes, many issues are simply users deciding that it is quicker to abuse maintainer time to get and answer than find out themselves, github does facilitate that.
What causes the most teeth grinding is when it is questions about their proprietary code. I don't care if their garbage never works! It's not going to help me or anyone else either way.
What causes the most teeth grinding is when it is questions about their proprietary code. I don't care if their garbage never works! It's not going to help me or anyone else either way.
There is a lot of idiots out there who expects you to work for them and help them fix their issues just because you made your code public for those who find it useful. Just look at some of the answers, even here on HN.
One should be happy for the work that people do make available for others. If you're not paying for it and it's run by people who just want to make something cool then you should be prepared to contribute if you want someone to go out of their way to help you.
You don't have to contribute financially or by writing/fixing code. If you need help with a bug, make sure you write good bug reports, and be patient.
Also, if you don't want spam, just turn off notifications for non important things and limit the communication channels to something you'll be able to control. That's the beauty of digital communication: you control exactly how and when people can get in touch with you.
One should be happy for the work that people do make available for others. If you're not paying for it and it's run by people who just want to make something cool then you should be prepared to contribute if you want someone to go out of their way to help you.
You don't have to contribute financially or by writing/fixing code. If you need help with a bug, make sure you write good bug reports, and be patient.
Also, if you don't want spam, just turn off notifications for non important things and limit the communication channels to something you'll be able to control. That's the beauty of digital communication: you control exactly how and when people can get in touch with you.
Always good to see an open source dev standing up for themselves, if only a little, against all the entitled freeloaders and techbros who are all too happy to exploit them and to encourage them to continue exploiting themselves
If you build a product that uses open source libraries and you make money off that product, you should pay the people who created the open source libraries, even if they don't expect it or ask for it. Period. It's not a legal question, it's a basic middle-school-civics question of not being a piece of shit. If you can't afford to do that for all the open source libraries you use while still making a profit, you simply don't actually have a viable business model, much like how if you can't afford to tip your server you can't actually afford to go out to eat
If you build a product that uses open source libraries and you make money off that product, you should pay the people who created the open source libraries, even if they don't expect it or ask for it. Period. It's not a legal question, it's a basic middle-school-civics question of not being a piece of shit. If you can't afford to do that for all the open source libraries you use while still making a profit, you simply don't actually have a viable business model, much like how if you can't afford to tip your server you can't actually afford to go out to eat
you should pay the people who created the open source libraries, even if they don't expect it or ask for it. Period.
As an author of open source projects with thousands of users: no. You should abide by the terms of the license, which I voluntarily chose and which does not have a secret passive-aggressive clause of "you're a piece of shit if you don't pay".
(Separately, the tipping model is awful and something we should be moving away from rather than expanding).
As an author of open source projects with thousands of users: no. You should abide by the terms of the license, which I voluntarily chose and which does not have a secret passive-aggressive clause of "you're a piece of shit if you don't pay".
(Separately, the tipping model is awful and something we should be moving away from rather than expanding).
If an author can publish code with a take-it-or-leave-it attitude, why can't people make requests with the same attitude? If the author is under no obligations at all, a request is no problem, right?
Well, the problem is that it's not so absolute. Publishing something normally invites feedback and it's awkward to completely ignore it. Just like it's awkward when you report a bug and get silence.
I'm not suggesting a real obligation, but there is... something? If there wasn't, then these requests would be treated like random mail to a famous person and just discarded.
Well, the problem is that it's not so absolute. Publishing something normally invites feedback and it's awkward to completely ignore it. Just like it's awkward when you report a bug and get silence.
I'm not suggesting a real obligation, but there is... something? If there wasn't, then these requests would be treated like random mail to a famous person and just discarded.
No there is not something. That's a misconception.
The author is under no obligation at all. Of course a request is no problem. But then if that request is ignored, then that's no problem either. Who knows why there is no response. Maybe the person has other things in life needing attention. Maybe they have a bad day/week/month. Maybe they are burnt out. Maybe they have already responded to you 100x or maybe they just don't like your name.
If they do respond -- great! It's likely in their interest to respond to bug reports since it's likely in their interest to have less buggy software for themselves (if they use their own software) or for their customers (if their customers use their software). But maybe it's not, maybe they have moved on, or maybe they are just on vacation. If they are nice, then they tell you. But even that's something they don't have to do.
You are free to dislike them for that, and you are free to not use your software anymore.
You are usually even free to fork the project if you want your pull requests in and they keep being ignored or rejected. If others think like you, you get a community right away. But many people don't fork. Because it's a lot of work suddenly being a maintainer. Then you suddenly get those requests and opinions and pressure. Don't like that? See! That's the issue here! If you don't like it, then don't criticize others for not liking it either.
The author is under no obligation at all. Of course a request is no problem. But then if that request is ignored, then that's no problem either. Who knows why there is no response. Maybe the person has other things in life needing attention. Maybe they have a bad day/week/month. Maybe they are burnt out. Maybe they have already responded to you 100x or maybe they just don't like your name.
If they do respond -- great! It's likely in their interest to respond to bug reports since it's likely in their interest to have less buggy software for themselves (if they use their own software) or for their customers (if their customers use their software). But maybe it's not, maybe they have moved on, or maybe they are just on vacation. If they are nice, then they tell you. But even that's something they don't have to do.
You are free to dislike them for that, and you are free to not use your software anymore.
You are usually even free to fork the project if you want your pull requests in and they keep being ignored or rejected. If others think like you, you get a community right away. But many people don't fork. Because it's a lot of work suddenly being a maintainer. Then you suddenly get those requests and opinions and pressure. Don't like that? See! That's the issue here! If you don't like it, then don't criticize others for not liking it either.
> Well, the problem is that it's not so absolute. Publishing something normally invites feedback and it's awkward to completely ignore it. Just like it's awkward when you report a bug and get silence.
I think in a perfect world every request would be polite and reasonable, making what you say here objectively correct. Since this is not the case, this sadly becomes a subjective opinion.
The fact of the matter is that when one deals with the general public in any form you get all forms of good and bad interactions.
There's also an inherent asymmetry between the effort it takes for a small number of project maintainers to respond to a large number of project consumers.
There's no clear-cut answer here, but I think it is reasonable to state that someone sending requests to a project should set their expectations to match whatever licensing or contractual agreements are present in the projects they interact with.
I think in a perfect world every request would be polite and reasonable, making what you say here objectively correct. Since this is not the case, this sadly becomes a subjective opinion.
The fact of the matter is that when one deals with the general public in any form you get all forms of good and bad interactions.
There's also an inherent asymmetry between the effort it takes for a small number of project maintainers to respond to a large number of project consumers.
There's no clear-cut answer here, but I think it is reasonable to state that someone sending requests to a project should set their expectations to match whatever licensing or contractual agreements are present in the projects they interact with.
For the most part, the people that the product is offered to don't insist that the creator do work on demand. A small portion of obnoxious users make a point of insisting that the creator who already gave away their work for free remains under some kind of obligation to do more work.
For the most part, creators giving away their work for free don't insist that the people it's offered to accept it. A small portion of obnoxious creators make a point of insisting that some portion of people who aren't using it are obligated to use their work.
Obnoxious users are effectively discouraging, because not only does the population of users outnumber the population of open source authors by many orders of magnitude, not only also because the population of those who don't have the skills to do it themselves or contribute in a functional way is entirely contained within the 'users' category, but most importantly because each obnoxious user has only the authors of the few open source projects that they're using to be obnoxious to. Open source creators who talk about obnoxious users (usually without naming them) are often effectively criticized within the vast hordes of users.
Obnoxious open source creators are easily ignored, since there are so few of them, and they have millions (give or take an order of magnitude or two) of potential users to harrass. Open source users talk about these open source creators (usually calling them out by name), and those creators become well known as obnoxious cranks to be avoided.
For the most part, creators giving away their work for free don't insist that the people it's offered to accept it. A small portion of obnoxious creators make a point of insisting that some portion of people who aren't using it are obligated to use their work.
Obnoxious users are effectively discouraging, because not only does the population of users outnumber the population of open source authors by many orders of magnitude, not only also because the population of those who don't have the skills to do it themselves or contribute in a functional way is entirely contained within the 'users' category, but most importantly because each obnoxious user has only the authors of the few open source projects that they're using to be obnoxious to. Open source creators who talk about obnoxious users (usually without naming them) are often effectively criticized within the vast hordes of users.
Obnoxious open source creators are easily ignored, since there are so few of them, and they have millions (give or take an order of magnitude or two) of potential users to harrass. Open source users talk about these open source creators (usually calling them out by name), and those creators become well known as obnoxious cranks to be avoided.
Maybe obnoxious people aren't the problem. Maybe reasonable people are.
After all, I wouldn't lose sleep over an obnoxious person making an obnoxious demand. They'd be summarily ignored.
But I would feel a tinge of guilt if someone made a good faith effort to offer an improvement, and the contribution was technically sound, but I just didn't get to it.
After all, I wouldn't lose sleep over an obnoxious person making an obnoxious demand. They'd be summarily ignored.
But I would feel a tinge of guilt if someone made a good faith effort to offer an improvement, and the contribution was technically sound, but I just didn't get to it.
> I'm not suggesting a real obligation, but there is... something?
The only something there is, is what the license specifies.
Licenses vary, but generally the gist of it is that you get to use that code for free (with various limitations depending on license) and that's all you get. There isn't any something beyond that.
You're always free to negotiate and pay for a support contract if you prefer more than what the open source license grants you.
The only something there is, is what the license specifies.
Licenses vary, but generally the gist of it is that you get to use that code for free (with various limitations depending on license) and that's all you get. There isn't any something beyond that.
You're always free to negotiate and pay for a support contract if you prefer more than what the open source license grants you.
Dealing with users/contributors in open source indeed has its issues due to the low barrier and global nature, meaning you can receive both high and low quality comments/patches/etc, and sometimes the language barrier makes a good quality interaction look bad. In order not to drain your energy dealing with them, you have learn how to deal with them efficiently. What works for me is:
- Always respond to the initial question/comment/PR. Not necessarily immediately. But it lets people know you have seen it and they are not being ignored. If they DM but you rather have them use another way of communicating, just point that out.
- Give people the benefit of the doubt. Some people just don't know how to ask a good question or how to report an issue in a constructive way, so just respond with a remark that nudges them in the right direction, possibly have some document ready describing how people should ask questions (for example, like https://stackoverflow.com/help/how-to-ask).
- Don't continue fruitless discussions. I don't repeat things I said earlier, unless there is something to clarify. If someone disagrees with me and I don't see the merit in their points, then so be it. At some point you just have to ignore messages, and don't feel bad about doing that. If someone DMs and you said to create a ticket instead, and they DM again saying things like "but it's just this small thing" or "but I just told you", I'll just ignore that, and if they really care about the issue they'll eventually figure it out.
- When it comes to low quality pull requests, tell the author how to improve them. Ideally, I should be able to merge PRs without any changes necessary on my part. This will both lower the amount of work I have to do, as well as educate the author so they will be more productive in the future.
- I try not to be too fussy about how people want to contribute. I'll just as happy to accept a patch sent via email as a PR. And sometimes it's just less work to copy&paste a DM into a ticket instead of educating the user.
- Always respond to the initial question/comment/PR. Not necessarily immediately. But it lets people know you have seen it and they are not being ignored. If they DM but you rather have them use another way of communicating, just point that out.
- Give people the benefit of the doubt. Some people just don't know how to ask a good question or how to report an issue in a constructive way, so just respond with a remark that nudges them in the right direction, possibly have some document ready describing how people should ask questions (for example, like https://stackoverflow.com/help/how-to-ask).
- Don't continue fruitless discussions. I don't repeat things I said earlier, unless there is something to clarify. If someone disagrees with me and I don't see the merit in their points, then so be it. At some point you just have to ignore messages, and don't feel bad about doing that. If someone DMs and you said to create a ticket instead, and they DM again saying things like "but it's just this small thing" or "but I just told you", I'll just ignore that, and if they really care about the issue they'll eventually figure it out.
- When it comes to low quality pull requests, tell the author how to improve them. Ideally, I should be able to merge PRs without any changes necessary on my part. This will both lower the amount of work I have to do, as well as educate the author so they will be more productive in the future.
- I try not to be too fussy about how people want to contribute. I'll just as happy to accept a patch sent via email as a PR. And sometimes it's just less work to copy&paste a DM into a ticket instead of educating the user.
> When it comes to low quality pull requests, tell the author how to improve them. Ideally, I should be able to merge PRs without any changes necessary on my part. This will both lower the amount of work I have to do, as well as educate the author so they will be more productive in the future.
I agree that this probably the ideal thing to do in the long run but, especially as a less social person, often it feels much easier to just do the minor fixes required myself. Training people to be good contributors is a good thing to do, but it is also something that can be very draining.
I agree that this probably the ideal thing to do in the long run but, especially as a less social person, often it feels much easier to just do the minor fixes required myself. Training people to be good contributors is a good thing to do, but it is also something that can be very draining.
I totally get where they are coming from but it does make it sound like unsupported software. After reading that, I would not use it without completely understanding the code as if I had written it myself (and maybe that's what you should do for every dependency anyway). I would probably look for another open source project to use instead.
There seems to be a constant supply of people starting open source projects who are willing to support them, and I'm guessing that an alternative to this project will supersede it, resulting in people not bugging the author any more.
There seems to be a constant supply of people starting open source projects who are willing to support them, and I'm guessing that an alternative to this project will supersede it, resulting in people not bugging the author any more.
> but it does make it sound like unsupported software
Pretty much every open source license contains a section along the lines of "there is absolutely no warranty". Older projects make this crystal clear in their readme. Newer, hipper projects don't, but that's only because they don't state it as explicitly.
Open source software is unsupported software unless you paid for a support contract. If you still get support despite not having paid for such a contract, then that support is an incidental gift that can go away at any time for any reason.
Pretty much every open source license contains a section along the lines of "there is absolutely no warranty". Older projects make this crystal clear in their readme. Newer, hipper projects don't, but that's only because they don't state it as explicitly.
Open source software is unsupported software unless you paid for a support contract. If you still get support despite not having paid for such a contract, then that support is an incidental gift that can go away at any time for any reason.
There’s a difference between “please don’t ask for support” and “I’m happy to support you even though legally you can’t force me to support this”.
i think those two actually collapse to the exact same thing: "no guaranteed support"
Collapsing them misses the nuance that I am specifically talking about. It’s kind of like when the ice cream parlor down the street gives our free samples and you decide to go “well, actually, they don’t have to give you any samples because they can refuse service to anyone so in fact there is no difference in them providing free samples and not providing free samples” and it turns out that people can offer things in good faith without having to promise them in a legal contract. You definitely shouldn’t prepare a lawsuit based on the free samples but it’s totally reasonable to visit every week to try their latest flavor.
That's a poor analogy. An ice cream parlor offers free icecream purely to market thier product and drive business. An OSS dev gets nothing.
Nothing? Not at all: an open source developer gets the marketing/publicity benefit just like an ice cream parlor does. Why do you think companies open source their things? And as a solo developer, I get tons of high-quality inbound leads for job opportunities, get to interact with lots of smart people (many whom I end up forming long-lasting friendships with), and get other people to help improve and support my project with me. Plus I get the warm fuzzy feeling inside or high moral ground, or whatever you want to call it. If you’re not getting that from your open source work, why are you doing it anyways?
Would you do your current job for free for, say, six months to earn 'exposure' and 'warm fuzzy feelings'?
That’s a false dichotomy, because an ice cream parlor doesn’t stop selling ice cream when they give out free samples, any more than most open source developers quit their jobs (or stop searching for one) to work on their personal projects. Plus, you’re kind of asking the wrong person anyways, because I think I actually do significantly more work for free than I do for what I get paid for, just for those warm fuzzy feelings (exposure being a nice bonus). Plus, I happen to be financially stable enough to probably do this for longer than six months if required even without a full-time job. I basically did this last year when switching jobs (actually around five months, while interviewing around at a leisurely pace) and it was incredibly enjoyable. Felt like I had retired early and could just pursue whatever I wanted to learn or make: if you can afford to do it, I’d strongly suggest giving it a try.
Great, and the if the project you make for a bit more than six months of lots of dedication succeeds people might realize you are an expert in something and try to hire you into a job that is more than full-time and/or doesn't allow other programming with a very nice offer. I would expect you to take that job, but Internet haters will disagree.
Now the project someone chose for its high amount of free unguaranteed support goes off a cliff of no maintainer..
In my experience, I value projects with minimal maintenance over years by a large number of more selfishly invested contributors over the "excited just to be here" projects.
Now the project someone chose for its high amount of free unguaranteed support goes off a cliff of no maintainer..
In my experience, I value projects with minimal maintenance over years by a large number of more selfishly invested contributors over the "excited just to be here" projects.
Indeed, there is a difference, but it is also quickly forgotten when your production system is down with the boss breathing down your neck.
[deleted]
> After reading that, I would not use it without completely understanding the code as if I had written it myself (and maybe that's what you should do for every dependency anyway).
Isnt that the point? As in, it allows for the use of some (context-appropriate) open source upstream software to quickly flesh out some idea into an implementation, rather than expending time and effort writing certain code oneself (the user of the open source software). This doesn't absolve the user from the responsibility of eventually writing their own implementation, or alternatively, maintaining, that open source code/library/framework as a part of their overall codebase.
And so I seriously miss the point of where the managing or maintaining of some open source code, to satisfy some other downstream project's requirements, is the responsibility of upstream... again, when downstream uses it they do so to benefit themselves by not having to write or maintain that piece of software, but that comes with risks along with the relevant benefits. As in, its a "dependency" (in the name) for a reason.
I almost see it as bordering on a concept of entitlement to think that someone else (eg the original creator of some software) should spend time and effort fixing issues or adding functionality that benefits some user. Basically, one should always be considering that dependencies at the time of pulling them in are static and provided as is with no contract of maintenance, and that it might provide benefit currently but that there is a very real potential cost to using it in the future.
Isnt that the point? As in, it allows for the use of some (context-appropriate) open source upstream software to quickly flesh out some idea into an implementation, rather than expending time and effort writing certain code oneself (the user of the open source software). This doesn't absolve the user from the responsibility of eventually writing their own implementation, or alternatively, maintaining, that open source code/library/framework as a part of their overall codebase.
And so I seriously miss the point of where the managing or maintaining of some open source code, to satisfy some other downstream project's requirements, is the responsibility of upstream... again, when downstream uses it they do so to benefit themselves by not having to write or maintain that piece of software, but that comes with risks along with the relevant benefits. As in, its a "dependency" (in the name) for a reason.
I almost see it as bordering on a concept of entitlement to think that someone else (eg the original creator of some software) should spend time and effort fixing issues or adding functionality that benefits some user. Basically, one should always be considering that dependencies at the time of pulling them in are static and provided as is with no contract of maintenance, and that it might provide benefit currently but that there is a very real potential cost to using it in the future.
> I totally get where they are coming from but it does make it sound like unsupported software
That's exactly what it is, exactly how it says in the license:
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
That's exactly what it is, exactly how it says in the license:
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
> I totally get where they are coming from but it does make it sound like unsupported software.
All software is "unsupported software" unless explicitly stated otherwise. Just because some software has its software published under an open source license does not make it magically "supported". Not more than any proprietary software.
If you want support, pay for it. You can already be glad that somebody published the source code under a somewhat permissive license (i.e. not just an illegal leak). They have their reasons. Don't just assume a "support for free model", since that assumption is most certainly incorrect.
The reason that people support their open source projects _anyway_, and _for free_ is a mix of (1) self-interest, since I want my software to not have bugs, so of course I fix reported bugs, otherwise I may run into them myself, (2) fun, since it's just fun to tinker with things, (3) business interest, since showing support makes me look good to potential customers and (4) misconceptions on the author's side, thinking they have an obligation, fueled by threads like these.
Reasons (1)-(3) are fine. Reason (4) is terrible and I wish it would stop.
All software is "unsupported software" unless explicitly stated otherwise. Just because some software has its software published under an open source license does not make it magically "supported". Not more than any proprietary software.
If you want support, pay for it. You can already be glad that somebody published the source code under a somewhat permissive license (i.e. not just an illegal leak). They have their reasons. Don't just assume a "support for free model", since that assumption is most certainly incorrect.
The reason that people support their open source projects _anyway_, and _for free_ is a mix of (1) self-interest, since I want my software to not have bugs, so of course I fix reported bugs, otherwise I may run into them myself, (2) fun, since it's just fun to tinker with things, (3) business interest, since showing support makes me look good to potential customers and (4) misconceptions on the author's side, thinking they have an obligation, fueled by threads like these.
Reasons (1)-(3) are fine. Reason (4) is terrible and I wish it would stop.
By “unsupported software” I don’t think he means any kind of support for his particular use of the software, but simply the pace of development - keeping up with system API evolution, dependencies, fixing bugs in the original code.
Software rots, and you generally don’t want to adopt a project that is not having basic maintenance being done.
Software rots, and you generally don’t want to adopt a project that is not having basic maintenance being done.
It's your right to as a user choose projects based on that criterion. It sounds reasonable to me.
But it's not your right to demand anything from a project, including demanding that they do basic maintenance or disclose whether they are going to do it. Maybe they don't even know, or maybe they change their mind lots of times ever year or every day. If you don't get a promise of this happening, neither assume anything nor start to demand it.
(Even if you get a promise, if it's some individual writing something on the net, it's not worth much. If they fail doing it despite the promise, they are being idiots, which they are free to be, and you are free to ignore them going forward or be angry.)
The attitude that published open source software is generally expected to be supported with basic maintenance is bad. It burns out creators who also believe in this myth and it creates an atmosphere that fosters this and in the end, less software is placed under open source licenses because people feel that that would include some obligation after. It does not. Just because you find some piece of code on the internet does not entitle you to anything.
But it's not your right to demand anything from a project, including demanding that they do basic maintenance or disclose whether they are going to do it. Maybe they don't even know, or maybe they change their mind lots of times ever year or every day. If you don't get a promise of this happening, neither assume anything nor start to demand it.
(Even if you get a promise, if it's some individual writing something on the net, it's not worth much. If they fail doing it despite the promise, they are being idiots, which they are free to be, and you are free to ignore them going forward or be angry.)
The attitude that published open source software is generally expected to be supported with basic maintenance is bad. It burns out creators who also believe in this myth and it creates an atmosphere that fosters this and in the end, less software is placed under open source licenses because people feel that that would include some obligation after. It does not. Just because you find some piece of code on the internet does not entitle you to anything.
I’ve been publishing and contributing to open source software for 15+ years and have never experienced that attitude. Granted, none of my stuff reached huge success, but they are out there; I’ve also been close to a few mainstream projects, and from my POV this seems exaggerated. If anything, scaremongering comments like yours are what might stop people from publishing more.
It’s also pretty straightforward to disable issues in GitHub and ignore all the noise.
It’s also pretty straightforward to disable issues in GitHub and ignore all the noise.
Then how do you explain the original article that we are discussing here? He's just imagining the problems that he is addressing in there?
Just look around this thread, you can find the described attitude even here.
Just look around this thread, you can find the described attitude even here.
It boils down to the same thing. Support can be specific for a business need or for just general maintenance and bitrot prevention.
> it does make it sound like unsupported software
Nearly all open source software is by definition unsupported (read the license).
If you need support you can pay for it (and in the blog the author specifically states they are open to communications regarding paid consulting work).
Nearly all open source software is by definition unsupported (read the license).
If you need support you can pay for it (and in the blog the author specifically states they are open to communications regarding paid consulting work).
> maybe that's what you should do for every dependency anyway
Exactly. When your colleague wants to write new code in your repo you do a code review. When a stranger writes a large amount of code shouldn't you also do a code review?
Exactly. When your colleague wants to write new code in your repo you do a code review. When a stranger writes a large amount of code shouldn't you also do a code review?
Sometimes. Depends on the boundaries between your code and theirs.
I write Go apps and deploy them in the cloud. I haven't done a code review of Linux, Docker, Kubernetes, or the Go standard library. When an independent person puts out a library that I'm going to depend on, yes I'll review its code first. When I'm building on something that's backed by a big company (Google) or solid foundation (the PSF) then rather than reviewing the code, I'm more likely just to review the interface and docs. There's a continuum of possibilities in between. Different people may rationally draw the line where they'll do code reviews at different places on that continuum.
I write Go apps and deploy them in the cloud. I haven't done a code review of Linux, Docker, Kubernetes, or the Go standard library. When an independent person puts out a library that I'm going to depend on, yes I'll review its code first. When I'm building on something that's backed by a big company (Google) or solid foundation (the PSF) then rather than reviewing the code, I'm more likely just to review the interface and docs. There's a continuum of possibilities in between. Different people may rationally draw the line where they'll do code reviews at different places on that continuum.
Sure, you can blindly trust your dependencies. And most people do. But don't expect them to help you for free if you have a problem. They might. But likely they won't.
Try sending an email to Linus Torvalds if something with the Linux kernel is not to your liking and you'd like him to change something. Brace for impact. Well, at least with the "old" Linus. He calmed down a little recently.
Try sending an email to Linus Torvalds if something with the Linux kernel is not to your liking and you'd like him to change something. Brace for impact. Well, at least with the "old" Linus. He calmed down a little recently.
> I totally get where they are coming from but it does make it sound like unsupported software.
It is very specifically unsupported software! Read the license, it's right there in a legal document clearly spelled out (for many licenses, anyway).
> After reading that, I would not use it without completely understanding the code as if I had written it myself (and maybe that's what you should do for every dependency anyway).
A good phrase is that importing an open source library is like adopting a puppy. Sure you get the initial code for free, but all the work and mess from there on it's all on you.
Yes, if you want to rely on an open source library for production you do need to understand it as if you'd written it yourself! I know this principle has been lost in more recent times, but it remains reality. If you don't, you're just gambling on the hope that it'll work out. It can, but it's a gamble.
If you need more certainty, pay for a support contract with SLAs.
It is very specifically unsupported software! Read the license, it's right there in a legal document clearly spelled out (for many licenses, anyway).
> After reading that, I would not use it without completely understanding the code as if I had written it myself (and maybe that's what you should do for every dependency anyway).
A good phrase is that importing an open source library is like adopting a puppy. Sure you get the initial code for free, but all the work and mess from there on it's all on you.
Yes, if you want to rely on an open source library for production you do need to understand it as if you'd written it yourself! I know this principle has been lost in more recent times, but it remains reality. If you don't, you're just gambling on the hope that it'll work out. It can, but it's a gamble.
If you need more certainty, pay for a support contract with SLAs.
[deleted]
> it does make it sound like unsupported software.
They specifically welcome requests for professional support.
They specifically welcome requests for professional support.
I think the missing aspect is that the platforms put this stuff in front of your face and human curiosity will have your attention directed at it anyway. You will actively be thinking about that troll who opened up an issue or someone in your Twitter DMs asking for help.
Although I respect the author's boundaries, that is sadly just part of the job of putting your work on the internet. This does not just stop at open source, if you put anything out for the world to consume, do know that this is what you're signing up for whether you like it or not. People will "find a way" to contact you and won't read your boundaries or even know about them before they do.
I keep an autoresponder in a notes file that I copy and paste regularly as it's a full time job to keep up with the requests.
Although I respect the author's boundaries, that is sadly just part of the job of putting your work on the internet. This does not just stop at open source, if you put anything out for the world to consume, do know that this is what you're signing up for whether you like it or not. People will "find a way" to contact you and won't read your boundaries or even know about them before they do.
I keep an autoresponder in a notes file that I copy and paste regularly as it's a full time job to keep up with the requests.
[deleted]
Are you expecting the author to delete it?
Stuff like this is why I've never bothered to promote any of the open source stuff I've released.
Worst case scenario - people tell me my ideas are dumb and xyz does it better (I'm probably aware of xyz and found it lacking).
Best case scenario - the situation in TFA happens, where people act like I owe them something.
Worst case scenario - people tell me my ideas are dumb and xyz does it better (I'm probably aware of xyz and found it lacking).
Best case scenario - the situation in TFA happens, where people act like I owe them something.
I suggest cultivating a sense of shared ownership. The author is trying to do that, which is great, but it seems like it's not there yet.
That's true of open source as well as proprietary development. Do you want other engineers to constantly contact you because you're "the $feature guy"? Or customers to do so?
No, you want a process and a team/community.
That's true of open source as well as proprietary development. Do you want other engineers to constantly contact you because you're "the $feature guy"? Or customers to do so?
No, you want a process and a team/community.
To be fair, this is really hard. Even finding other people willing to review PRs is difficult, much less people willing to spend the time understanding the entire codebase and being able to contribute to it in a meaningful way.
I only have one rule: I only contact an open source developer if I believe resolving the problem would make the product better unless I am willing to offer them reasonable money to do it.
The preference of the developer doesn't feed into your decision to contact them? What if the repo readme says "this is provided as-is, I don't offer support"?
A counterpoint:
You may view this feature as making the product better, but it might not fit the vision of the owner/developer and to them it will only generate a maintenance burden and bloat.
You may view this feature as making the product better, but it might not fit the vision of the owner/developer and to them it will only generate a maintenance burden and bloat.
You can't know that before you contact them, though.
Exactly. I talked about this in my 22120 interview[0] a couple years ago. You have to learn to say no. Self-management taking care of yourself and setting boundaries, protecting your space to ensure you can continue making contribution on something you care about. People can be so demanding you have to push back. Use the block feature on GitHub if they're real trouble. I don't have a ton of experience but in my experience of this somehow by pushing back and setting boundaries and saying no it seems you change the expectation or culture and it's a persistent thing. Then the "little community" you have seems to behave better.
[0]: https://console.substack.com/p/console-28?utm_source=url
[0]: https://console.substack.com/p/console-28?utm_source=url
I wonder if there could be a way to just turn off issues and only accept PRs. Contribution-driven feature requests. That would be a boundary that I think would protect the maintainer from the potential outcome that the article about boundaries does absolutely nothing. Open is open, people are relentless and unforgiving, that’s why I don’t have the stomach for it. But if I see something I’d like to do with a project, I will take a whack at implementing it and giving back.
I can imagine gaining a distaste for seeing companies benefit without being rewarded in return. With that, perhaps it’s time to seek out other maintainers? If we’re talking open source here, shouldn’t successful projects become co-owned (ie maintained) by the community?
While a single maintainer who creates a successful open sourced software certainly earns the discretion to choose to share their invention(s) or not, holding tightly onto the projects as opposed to donating them seems as unproductive as a random person demanding features.
But I am not the maintainer so I don’t mean to convey apathy, my completely naive, lizard brain would just want to troll the worst of them with “open a PR and we’ll talk”
I can imagine gaining a distaste for seeing companies benefit without being rewarded in return. With that, perhaps it’s time to seek out other maintainers? If we’re talking open source here, shouldn’t successful projects become co-owned (ie maintained) by the community?
While a single maintainer who creates a successful open sourced software certainly earns the discretion to choose to share their invention(s) or not, holding tightly onto the projects as opposed to donating them seems as unproductive as a random person demanding features.
But I am not the maintainer so I don’t mean to convey apathy, my completely naive, lizard brain would just want to troll the worst of them with “open a PR and we’ll talk”
> I wonder if there could be a way to just turn off issues and only accept PRs
That would create the problem, that people won't able to ask if a feature is desired by the maintainer. New contributors would spend time on a PR and then learn that the original developer considers that feature to be out of scope and therefore the development effort would be wasted.
I understand your wish for removing the issue tab. But there is a downside to it.
That would create the problem, that people won't able to ask if a feature is desired by the maintainer. New contributors would spend time on a PR and then learn that the original developer considers that feature to be out of scope and therefore the development effort would be wasted.
I understand your wish for removing the issue tab. But there is a downside to it.
FWIW, you can disable the Issues tab on GitHub, there's a setting for it.
Since Nov 2021, you can allow some people to bypass pull requests requirements.
https://github.blog/changelog/2021-11-19-allow-bypassing-req...
> I am contacted dozens of times every week with varying requests to answer people’s questions
Occasionally happens to me. I mean, not dozens of times a week, but I've had a few weeks with more than a dozen times.
> fix bugs
"Please file an issue at http://the.issue.tracker/wherever"
> or build new features
"Please file an issue at http://the.issue.tracker/wherever"
> set up consultations
So, this one is interesting. I mean, it almost never happens to me, and certainly not w.r.t. my FOSS specifically. If I were looking for work, this would be a boon, would it not? And if I'm fully booked, then:
"I am currently not available for consultancy. You may inquire again, if relevant, in ____ months."
> or discuss business opportunities.
"I'm sorry, not interested. Good luck with your business."
Although I guess if there were dozens of these emails per week, I would create a private email box and keep the existing one only for FOSS-support-related business, attending to it every couple of weeks or so. And perhaps create an auto-reply with the above replies :-)
Occasionally happens to me. I mean, not dozens of times a week, but I've had a few weeks with more than a dozen times.
> fix bugs
"Please file an issue at http://the.issue.tracker/wherever"
> or build new features
"Please file an issue at http://the.issue.tracker/wherever"
> set up consultations
So, this one is interesting. I mean, it almost never happens to me, and certainly not w.r.t. my FOSS specifically. If I were looking for work, this would be a boon, would it not? And if I'm fully booked, then:
"I am currently not available for consultancy. You may inquire again, if relevant, in ____ months."
> or discuss business opportunities.
"I'm sorry, not interested. Good luck with your business."
Although I guess if there were dozens of these emails per week, I would create a private email box and keep the existing one only for FOSS-support-related business, attending to it every couple of weeks or so. And perhaps create an auto-reply with the above replies :-)
> Part of the stress is in interacting with so many people a single time, never having a solid relationship with any of them.
I found that working in the Linux distro space doesn't have this problem, especially in the pre-COVID times when there were annual in-person conferences and lots of socialising.
I found that working in the Linux distro space doesn't have this problem, especially in the pre-COVID times when there were annual in-person conferences and lots of socialising.
I found working in the Linux space did have that problem in pre-COVID times. Especially the lack of solid relationships, due to never meeting people and getting to know anyone personally.
I spent too much time working on things for free (not just open source, but also voluntary work, and a couple of tech R&D ventures that ate my savings) and as a result I couldn't afford to attend any of the in-person conferences in far off countries, where the real action seemed to migrate to. That was a strategic error on my part!
LKML also become stressful for me after a decade of reading, just due to the energy to skim the mails each morning due to sheer volume. So I fell off, which was a shame because I had a very solid understanding of the entire kernel at one time.
I spent too much time working on things for free (not just open source, but also voluntary work, and a couple of tech R&D ventures that ate my savings) and as a result I couldn't afford to attend any of the in-person conferences in far off countries, where the real action seemed to migrate to. That was a strategic error on my part!
LKML also become stressful for me after a decade of reading, just due to the energy to skim the mails each morning due to sheer volume. So I fell off, which was a shame because I had a very solid understanding of the entire kernel at one time.
It sounds like we are talking about different spaces, I was talking about Linux distros (specifically Debian). Even before I started going to the conference there was some feel of community.
Perhaps the Linux community is larger than Debian or more subject to churn as people change employers and thus change which part of Linux they work on. Or maybe as you say attending the conferences is a bit part of community feeling.
I'm surprised you read LKML, the volume is enough to put anyone off. If you are still interested in reading some of it, these days there is lore+lei to filter down the volume just to your personal interests.
https://lwn.net/Articles/878205/
Perhaps the Linux community is larger than Debian or more subject to churn as people change employers and thus change which part of Linux they work on. Or maybe as you say attending the conferences is a bit part of community feeling.
I'm surprised you read LKML, the volume is enough to put anyone off. If you are still interested in reading some of it, these days there is lore+lei to filter down the volume just to your personal interests.
https://lwn.net/Articles/878205/
Open Source Software promulgated by GitHub is made commonly available in the form of actual source code.
If this code does not suit your needs, change it such that it does. We're all engineers/developers/coders/hackers with Top Notch Skills right?
Make a fix thats well thought out and well integrated, commit, pull request and hope the maintainer finds value in integrating your code into the next release.
Should you come across a maintainer that doesn't share your view of the issue and depending on licensing constraints simply maintain the code you were given for free on your own.
That or ... I dunno... Maybe pay someone? Venmo is a thing? Do you even Crypto bruh?
* I spent 5 years working for a company that successfully took this approach. Pre-GitHub of course.
* OP is totally on target.
If this code does not suit your needs, change it such that it does. We're all engineers/developers/coders/hackers with Top Notch Skills right?
Make a fix thats well thought out and well integrated, commit, pull request and hope the maintainer finds value in integrating your code into the next release.
Should you come across a maintainer that doesn't share your view of the issue and depending on licensing constraints simply maintain the code you were given for free on your own.
That or ... I dunno... Maybe pay someone? Venmo is a thing? Do you even Crypto bruh?
* I spent 5 years working for a company that successfully took this approach. Pre-GitHub of course.
* OP is totally on target.
If my OSS projects ever get traction, I'll probably forward support to a public listserv or web bbs thing. Extra credit for wiring that up to some kind of ticketing and bug tracking thing. Automate the FIFO queue.
Biggest benefit to me will be transparency. Everyone can see exactly where they are in my priority queue.
Huh. Could lead to some fun incentive structures. Want my attention? Then pay me. Like charge $1 per slot. So moving from 100th to 5th place would cost $95. Maybe increase the price-to-slot logarithmically.
Any way. It's nice to dream. A small inhibitor to me working on my OSS fulltime and exclusively is figuring out how to pay for food and rent and insurance while saving humanity (from itself).
Biggest benefit to me will be transparency. Everyone can see exactly where they are in my priority queue.
Huh. Could lead to some fun incentive structures. Want my attention? Then pay me. Like charge $1 per slot. So moving from 100th to 5th place would cost $95. Maybe increase the price-to-slot logarithmically.
Any way. It's nice to dream. A small inhibitor to me working on my OSS fulltime and exclusively is figuring out how to pay for food and rent and insurance while saving humanity (from itself).
I have only one problem with this:
> In Slack or Github, it’s usually not necessary to mention me.
That's kinda how it has always worked in these forms of communication though - if I want X to see something, I mention. It's not that I personally would be keen on to be mentioned all the time, but I've been on open source project IRC for 20 years and it is like it is. People need to configure their client to not spam them, or not use [medium] if they can't do that. It's unreasonable to have the general populace have rules of whom to mention and whom not to mention. We all should be sparingly using it, it's async after all.
> In Slack or Github, it’s usually not necessary to mention me.
That's kinda how it has always worked in these forms of communication though - if I want X to see something, I mention. It's not that I personally would be keen on to be mentioned all the time, but I've been on open source project IRC for 20 years and it is like it is. People need to configure their client to not spam them, or not use [medium] if they can't do that. It's unreasonable to have the general populace have rules of whom to mention and whom not to mention. We all should be sparingly using it, it's async after all.
I originally set out to fix a performance problem in lint-staged that was preventing my then-company from using it in their large git repo (related to long histories, git read/write tree, and clearing index caches).
Here I am, many years later, still maintaining it and overally enjoying the work. I just chose to never take on any implied responsibility like described in the article. This means it's ok to ignore or close tickets, or simply not be active for some months if there was better things to do. So far the interest has kept up, and I'm improving it on our own terms.
Here I am, many years later, still maintaining it and overally enjoying the work. I just chose to never take on any implied responsibility like described in the article. This means it's ok to ignore or close tickets, or simply not be active for some months if there was better things to do. So far the interest has kept up, and I'm improving it on our own terms.
Good on him. I wrote fairly comprehensively about boundaries in open source recently: https://matt.life/writing/the-asymmetry-of-open-source
A lot of principles are familiar here. Love to see it. Open source is no cakewalk, especially without boundaries.
A lot of principles are familiar here. Love to see it. Open source is no cakewalk, especially without boundaries.
Indeed, love this article. Especially after receiving this tweet, getting public attention for a bug: https://mobile.twitter.com/araffin2/status/15013142481144135...
[deleted]
> noticing people cozying up to me so that they can exploit our acquaintanceship later
Unfortunately this is common in many other parts of life as well; setting boundaries is important.
Unfortunately this is common in many other parts of life as well; setting boundaries is important.
[deleted]
Does it works? I also have issues with users and in my case they don't read this kind of instructions.
An XKCD that's right on target: https://xkcd.com/2347/
In refusing to accept that any contribution you make to society is in fact a business, you will be doomed to build a bad business. You will talk about the emotional turmoil a feature request puts you through instead of being proud of your streamlined business processes and your ever increasing MRR.
This is a good read. just to get a sense of some of the OSS maintainer experience. As far as a practical guide, it's my experience that the vast majority of users of OSS software libraries "get" these things already and therefore you don't hear from them. However, just 1% of users who don't "get" it at all, and do all the direct messaging / manipulative stuff are still there, and that's who ruins your day.
Which then leads to, those people are absolutely not going to read a blog post like this, they can't even read GIANT LETTERS IN BOLDFACE at the top of a github template telling them to please provide a test case / stack trace / etc.
After doing this for 16 years I have realized that while you need to put up guidelines, instructions for interacting, issue templates, etc., at some point you can't keep putting up signs to PLEASE DONT DO THIS - because the people for whom the ALL CAPS is intended for are the last people to read/ care about any of this, and the stern messaging otherwise brings the mood down for that vast majority of users who aren't going to be bothersome in any case.
You have to just have a pre-packaged response for the various things you get:
1. "hi" on IRC in private message from someone you don't know (obviously looking for help) - ignore. there's no response you can have for this person in this setting that will make the situation better (keep in mind, there are many forums / chats/ systems this person can use to get help, and they are well documented. these people ignored all that and are trying to go right to the main dev to get private help. they most certainly know how to find things because they found your nickname on an irc network. so this is overall a pretty rude move, but even then, some people just arent aware of what they're doing or how to act)
2. email asking for help - this is probably not too different from the "hi" in private message thing but I tend to give folks like this a short answer and point them to github discussions / irc, mentioning "there's some folks there who can help us further" (note the word "us", to soften the blow a bit). the emailers tend to be completely bewildered and generally lean heavily towards overall beginner types so I do try to gently guide them into the wider community for help.
3. recruiters - geezus, they just don't stop. I pretty much ignore them, which they have all caught onto these days so they email you over and over again...I will send back a one liner about 50% of the time after they've pinged me three times
4. weird link-sharing emails who want to put some kind of endorsement for some programming tool on my site that makes absolutely no sense to be in the context they are proposing - I usually just ignore these. Hard to tell if those are spam robots or what but they can be persistent with fairly emotionally charged "can you at least tell me what you'd be interested in?" kinds of replies...I mean these folks I'm sure are sending thousands of these emails out, are they sending out hundreds of frustrated third-requests to everyone who doesn't reply also?
I do feel for this developer since producing a JS web-development oriented library is going to generate lots more attention from a lot of users with relatively low levels of technical sophistication. I'm thankful that the Python world still attracts high quality people with reasonably good manners about things.
Which then leads to, those people are absolutely not going to read a blog post like this, they can't even read GIANT LETTERS IN BOLDFACE at the top of a github template telling them to please provide a test case / stack trace / etc.
After doing this for 16 years I have realized that while you need to put up guidelines, instructions for interacting, issue templates, etc., at some point you can't keep putting up signs to PLEASE DONT DO THIS - because the people for whom the ALL CAPS is intended for are the last people to read/ care about any of this, and the stern messaging otherwise brings the mood down for that vast majority of users who aren't going to be bothersome in any case.
You have to just have a pre-packaged response for the various things you get:
1. "hi" on IRC in private message from someone you don't know (obviously looking for help) - ignore. there's no response you can have for this person in this setting that will make the situation better (keep in mind, there are many forums / chats/ systems this person can use to get help, and they are well documented. these people ignored all that and are trying to go right to the main dev to get private help. they most certainly know how to find things because they found your nickname on an irc network. so this is overall a pretty rude move, but even then, some people just arent aware of what they're doing or how to act)
2. email asking for help - this is probably not too different from the "hi" in private message thing but I tend to give folks like this a short answer and point them to github discussions / irc, mentioning "there's some folks there who can help us further" (note the word "us", to soften the blow a bit). the emailers tend to be completely bewildered and generally lean heavily towards overall beginner types so I do try to gently guide them into the wider community for help.
3. recruiters - geezus, they just don't stop. I pretty much ignore them, which they have all caught onto these days so they email you over and over again...I will send back a one liner about 50% of the time after they've pinged me three times
4. weird link-sharing emails who want to put some kind of endorsement for some programming tool on my site that makes absolutely no sense to be in the context they are proposing - I usually just ignore these. Hard to tell if those are spam robots or what but they can be persistent with fairly emotionally charged "can you at least tell me what you'd be interested in?" kinds of replies...I mean these folks I'm sure are sending thousands of these emails out, are they sending out hundreds of frustrated third-requests to everyone who doesn't reply also?
I do feel for this developer since producing a JS web-development oriented library is going to generate lots more attention from a lot of users with relatively low levels of technical sophistication. I'm thankful that the Python world still attracts high quality people with reasonably good manners about things.
How about charging money for work?
[deleted]
Honestly, I don’t understand the entitlement that causes someone to have to write this.
Having experienced the “overwhelmed with requests” thing myself, I now find myself thinking anyone who becomes demanding of open source maintainers is not seeing reality. These folks have day jobs, they don’t work for you.
If you’ve implemented my library in a mission critical part of your system, then feel free to fork & fix or pony up the dough. Otherwise you’ll get the update (if it should be updated at all) when/if I have a minute.
This might be a bit hostile but truly, c’mon people.
Having experienced the “overwhelmed with requests” thing myself, I now find myself thinking anyone who becomes demanding of open source maintainers is not seeing reality. These folks have day jobs, they don’t work for you.
If you’ve implemented my library in a mission critical part of your system, then feel free to fork & fix or pony up the dough. Otherwise you’ll get the update (if it should be updated at all) when/if I have a minute.
This might be a bit hostile but truly, c’mon people.
That's not hostile at all. If someone decides it's best to use your code then you have already helped them out. Expecting you to do work for free for them because you already did something useful for them is just stupid.
It's great to have that kind of post published. I had that exact conversation just yesterday with a director who "love" open source and see it as "the future". When asked to pay market rate for the extra features he want, he was struggling to understand that 8k won't get him a few months of work and felt entitled on a discount on the basis that I'm doing open source and he is helping the project ...
I don't think this is hostile in the slightest. Nobody should expect free work
[deleted]
ikiris(2)
GoToRO(3)
I read Joe Elden Ring.
Although FOSS software is nice, it just doesn't seem worth the hassle to be involved any more.
I appreciate that an open source developer is likely to be burned out on some people's expectations or unthinking requests, but that page was too long for me to even skim.
Usability-wise, one could lead with a terse bulleted list of "use cases" for which people should contact you, and how.
Then state you can't handle all the other usual reasons people want to interact with an open source developer, maybe giving examples. Then follow it with explanation of why.
Usability-wise, one could lead with a terse bulleted list of "use cases" for which people should contact you, and how.
Then state you can't handle all the other usual reasons people want to interact with an open source developer, maybe giving examples. Then follow it with explanation of why.
Why not grow the maintainers group to multiple people? A trusted group of people that share the vision of the project. This way the project becomes a living thing that doesn’t depend on the goodwill of a single person. And that single person would not be overwhelmed.
People are not entitled for support but bringing something out as open source does come with some responsibilities. If not when others fork it the original author gets upset others stealing their project (assumption here).
People are not entitled for support but bringing something out as open source does come with some responsibilities. If not when others fork it the original author gets upset others stealing their project (assumption here).
> bringing something out as open source does come with some responsibilities.
No, it does not.
No, it does not.
There are many, many projects where "simply adding more maintainers" is not possible at all, i.e. there are no people that you personally can trust to do the right thing, and that have the necessary experience. For various projects that I maintain, I couldn't name a single person that would have the skill and would actually want to take over. Granted they may not be as popular as this persons's repositories, but still - this claim is not generally true.
Is this person OK? Doesn't seem it. I use single-spa. I'm now worrying about it's future with the sentiments and apparent dislike of users expressed here.
This person is more than OK. They're learning how to set boundaries and not let crappy people bother them.
Open Source will eat your soul if you let it. Low effort drive by issues, questions, or comments are crushing. On my humble project, something like 40% of people who open issues completely ignore the issue template, which means every. single. conversation. begins with asking for the bare minimum of details needed to even help them. Then you've got PRs with literally zero info, which you're expected to spend time reviewing / understanding.
Some people will even violate the Github boundary and email you directly to ask why their issue isn't being responded to, or why their PR isn't getting merged, or whatever. Honestly? Fuck these people.
OP is spot on.
Open Source will eat your soul if you let it. Low effort drive by issues, questions, or comments are crushing. On my humble project, something like 40% of people who open issues completely ignore the issue template, which means every. single. conversation. begins with asking for the bare minimum of details needed to even help them. Then you've got PRs with literally zero info, which you're expected to spend time reviewing / understanding.
Some people will even violate the Github boundary and email you directly to ask why their issue isn't being responded to, or why their PR isn't getting merged, or whatever. Honestly? Fuck these people.
OP is spot on.
> They're learning how to set boundaries and not let crappy people bother them.
Abusive mindsets parse boundaries as an illness. So saying that someone "seems unwell" simply because they want reasonable boundaries is definitely telling on oneself.
Abusive mindsets parse boundaries as an illness. So saying that someone "seems unwell" simply because they want reasonable boundaries is definitely telling on oneself.
That wasn't my impression from reading it. The writeup actually seemed very reasonable to me. They perhaps sound like they're having a bit more trouble than many at handling the onslaught and saying no, but given that, this felt like a fine way to set things up.
So I'm curious: what in the writeup indicates a dislike of users?
So I'm curious: what in the writeup indicates a dislike of users?
Do you not see the irony that as a user of their free software you completely missed the point of their post that is basically saying, the people using my software are asking so much and giving so little that I'm burning out?
I got the opposite read regarding their mental health. This was a very clear and well thought out statement of reasonable boundaries, especially for someone volunteering their time. I admire them for it.
I didn't get that vibe.
Seems to me, that he wants to keep going on it, but isn't really a "people person," and wants to control his agenda.
I can respect that.
I managed an open-source project for a decade, that was designed to serve an ... interesting ... demographic.
I think many of the folks here, would have defecated masonry, if they got some of the contacts that I did.
But I'm a fairly tough old coot. I held my own. It wasn't pleasant, though, and I learned a great deal, about interacting with ... interesting ... people.
Seems to me, that he wants to keep going on it, but isn't really a "people person," and wants to control his agenda.
I can respect that.
I managed an open-source project for a decade, that was designed to serve an ... interesting ... demographic.
I think many of the folks here, would have defecated masonry, if they got some of the contacts that I did.
But I'm a fairly tough old coot. I held my own. It wasn't pleasant, though, and I learned a great deal, about interacting with ... interesting ... people.
I don’t see a dislike of users, just a dislike of the stress that being an open source maintainer tends to place on people.
I got the sense that Denning might have some sort of mild anxiety disorder, but I'm not any sort of expert on the subject. It doesn't sound to me like he dislikes users, rather he dislikes certain kinds of interactions. E.g.:
> When something feels like a demand (even a small demand such as “please respond to me” or “please review this pull request”), I often retreat. It is very common for me to take days, weeks, or even months off from open source because I get overwhelmed by the people asking me to do it. I experience a lot of initial anxiety due to the demand, followed by additional anxiety about me delaying my response.
> When something feels like a demand (even a small demand such as “please respond to me” or “please review this pull request”), I often retreat. It is very common for me to take days, weeks, or even months off from open source because I get overwhelmed by the people asking me to do it. I experience a lot of initial anxiety due to the demand, followed by additional anxiety about me delaying my response.
Probably not. I think there is a difference between having guidelines for how to.contact you is not dislike if users.
Waking up at 4 am to reply to a poorly worded bug report with a demand you fix it immediately is exhausting and sucks your will to live
Waking up at 4 am to reply to a poorly worded bug report with a demand you fix it immediately is exhausting and sucks your will to live
The worst was the CEO of a small competitor company repeatedly hassling me over slack DMs and in github issues threads shamelessly trying to get me to prioritize free work that he wanted for his clients. Separately, over a period of several weeks, this same person asked me a ton of support questions and then compiled my answers without edits or attribution into a "white paper" he used as a resource to get people into the marketing funnel for his consulting shop. I came to hate that guy, such an asshole, but I couldn't totally block him because his company was a member of the open source foundation governing the ecosystem of tools my project was under.
Honestly, it was hell. The most stress and irritation I've ever had in any job. When I started the job I thought it was a dream getting paid to do open source, but now I consider that an anti-goal for any future role.