Hm, I think there’s a specific bit which goes beyond “open source software starts and stops with the software and its license”. I observed several times how it went wrong. To take the most extreme version of it,
Don’t lie in the readme.
If the readme advertises that the project as reliable, production ready, safe and performant, but it is actually not, then it is ethical for the users to point this out and request clarification.
The license says that the code comes without any warranties, so it is legal to create misleading expectations. It’s not good though.
Do you think it’s reasonable to get mad at me just because I changed the software such that you can’t use it anymore?
Of course it isn’t, but I think it is reasonable for people who can’t use the software anymore to discuss what to do, and fork the software so that they can continue to use it, and even advertise to users of your software to switch to the fork in case they want to.
I think this discussion was slightly flawed because it only had author and consumer as the two roles and that relationship was static. When you release something as open source, one of the parts of the social contract is that there’s an expectation that some of the people who find it valuable will contribute. They may contribute money, code, documentation, bug reports, logos, or in other ways. A good bug report with root-cause analysis is a valuable contribution.
Successful open source projects tend to be the ones that have a good pipeline for turning users into contributors. The other side of this social contract is that an open source project is that a project is willing for people to make this transition, from consumer to casual contributor to active contributor, and will welcome them.
Absolutely, but that’s very different from treating the author in a, well, unethical way. The issue is some people both take things way too personally (authors too!) and believe they have certain rights when they actually don’t. As described, the sooner people realize their rights, the better (and discussions should remain civil).
This is part of the weakness of Open Source as a social construction: It is inherently exploitable without limitation, leading to a flimsy and easily-rent commons which cannot enforce its own moral expectations.
The author says, “To me, open source software is source code that is licensed in such a way that I can use it for free.” In this tone, I would imagine that Free Software is source code that is licensed in such a way that I cannot deny others the freedom to use it for free. With this extra restriction on me, I would be legally bound in a way which aligns with the moral expectations of the Free Software community.
This seems to miss understand how the vast majority of open source it’s made: either by a corporation or by a foundation.
I don’t hound individual contributors who wrote some weird and wonderful little library that stopped working with the new release of libc. But when firefox, linux, systemd, gnome, gcc and any of the essential projects start doing some really dumb shit pointing out to users that the software is no longer fit for the purpose it’s been used for decades is a public service and the first step in starting a fork.
Saying that redhat is a vampire squid on the face of open source isn’t me being entitled, it’s me letting everyone know that the interests of IBM are misaligned with the interests of the open source community and we should be really looking for option B for any software they are in charge of.
Automatic updates turn your USB stick into an addon that summons further USB sticks, which may contain software that behaves radically differently, and plugs them in for you. If you’re lucky, you’ll have a backup of the old USB stick. If you saved data on the old USB stick, you may or may not lose it forever.
(No I will not update Firefox, Android, stop asking.)
Morally, when you invite users to sink time into your software, you have to treat that time with at least a minimum of respect. The more time your users will sink into your software, the less callously you should treat the products of that time. Lock-in is less of an issue for open source, but it is still an issue, especially if the user doesn’t have the technical chops to fork.
Hm, I think there’s a specific bit which goes beyond “open source software starts and stops with the software and its license”. I observed several times how it went wrong. To take the most extreme version of it,
Don’t lie in the readme.
If the readme advertises that the project as reliable, production ready, safe and performant, but it is actually not, then it is ethical for the users to point this out and request clarification.
The license says that the code comes without any warranties, so it is legal to create misleading expectations. It’s not good though.
Of course it isn’t, but I think it is reasonable for people who can’t use the software anymore to discuss what to do, and fork the software so that they can continue to use it, and even advertise to users of your software to switch to the fork in case they want to.
I think this discussion was slightly flawed because it only had author and consumer as the two roles and that relationship was static. When you release something as open source, one of the parts of the social contract is that there’s an expectation that some of the people who find it valuable will contribute. They may contribute money, code, documentation, bug reports, logos, or in other ways. A good bug report with root-cause analysis is a valuable contribution.
Successful open source projects tend to be the ones that have a good pipeline for turning users into contributors. The other side of this social contract is that an open source project is that a project is willing for people to make this transition, from consumer to casual contributor to active contributor, and will welcome them.
Absolutely, but that’s very different from treating the author in a, well, unethical way. The issue is some people both take things way too personally (authors too!) and believe they have certain rights when they actually don’t. As described, the sooner people realize their rights, the better (and discussions should remain civil).
This is part of the weakness of Open Source as a social construction: It is inherently exploitable without limitation, leading to a flimsy and easily-rent commons which cannot enforce its own moral expectations.
The author says, “To me, open source software is source code that is licensed in such a way that I can use it for free.” In this tone, I would imagine that Free Software is source code that is licensed in such a way that I cannot deny others the freedom to use it for free. With this extra restriction on me, I would be legally bound in a way which aligns with the moral expectations of the Free Software community.
This seems to miss understand how the vast majority of open source it’s made: either by a corporation or by a foundation.
I don’t hound individual contributors who wrote some weird and wonderful little library that stopped working with the new release of libc. But when firefox, linux, systemd, gnome, gcc and any of the essential projects start doing some really dumb shit pointing out to users that the software is no longer fit for the purpose it’s been used for decades is a public service and the first step in starting a fork.
Saying that redhat is a vampire squid on the face of open source isn’t me being entitled, it’s me letting everyone know that the interests of IBM are misaligned with the interests of the open source community and we should be really looking for option B for any software they are in charge of.
Automatic updates turn your USB stick into an addon that summons further USB sticks, which may contain software that behaves radically differently, and plugs them in for you. If you’re lucky, you’ll have a backup of the old USB stick. If you saved data on the old USB stick, you may or may not lose it forever.
(No I will not update Firefox, Android, stop asking.)
Morally, when you invite users to sink time into your software, you have to treat that time with at least a minimum of respect. The more time your users will sink into your software, the less callously you should treat the products of that time. Lock-in is less of an issue for open source, but it is still an issue, especially if the user doesn’t have the technical chops to fork.