If you're in (for example) a CI context and do a git checkout @tag, there's no guarantee that you'll get the same content as the last time you fetched that tag.
Where is this mythical social contract found? I stand by my point: it's a software license, not a marriage.
Free users certainly would like it to be a social contract like I would like to be gifted a million dollars. Sadly, I still have to work and can't infinitely rely on the generosity of others.
Your analogy doesn't make sense. You are getting benefits from using the shopping cart and you bring back as it's expected as part of the exchange. You bring the cart back to where you took which is a low effort commitment entirely proportional to what you got from it.
Free software developers are gifting you something. Expecting indefinite free work is not mutual respect. That's entitlement.
The common is still there. You have the code. Open source is not a perpetual service agreement. It is not indentured servitude to the community.
Stop trying to guilt trip people into giving you free work.
MinIO accepted contributions from people outside the company who did work on it for free, usually because they expected that minio would keep the software open source.
I always preferred people who didn’t, when I worked in retail. It generates a nice chill task (wander around the parking lot looking for carts). But if you want to do a favor for the faceless retailer, go for it. Mostly I chuck my cart in the corral to get it out of my way, but this sees more like a morally-neutral action to me.
In this context the social contract would be an expectation that specifically software developers must return the shopping cart for you, but you would never expect the same from cashiers, construction workers, etc.
If the software developer doesn't return your cart, he betrayed the social contract.
Maybe this is the case, but why is your presumption of entitlement to free labor of others the assumed social contract, the assumed "moral" position, rather than the immoral one?
Why is the assumed social contract that is unwritten not that you can have the free labor we've released to you so far, but we owe you nothing in the future?
There's too much assumption of the premise that "moral" and "social contract" are terms that make the entitled demands of free-loaders the good guys in this debate. Maybe the better "morality" is the selfless workers giving away the product of their labor for free are the actual good guys.
That's not what a social contract is you are thinking of a legal contract, something very different. A social contract is by definition, implicit rather than explicit.
It was not expectation when they started, did a lot to lure many into the ecosystem. When you release it free, wait for the momentum to build, then you cut off, it is something else. And the worse is they did it in a very short time. Check out elasticsearch, the same route but did not abandon the 7 release like this.
I know all about ElasticSearch, MongoDB, Redis, etc. Yes, what they did sucks. No, it doesn't make the maintainers bad or anything. It's still on the user to know that anything can happen to that spiffy project they've been using for a while, and so be prepared to migrate at any time.
Expectations are maybe fine maybe not, but it's funny that people can slap the word moral onto their expectation of others being obligated to do free work for them, and it's supposed to make them be the good guys here.
Why do you presume to think your definition of morals is shared by everyone? Why is entitlement to others labor the moral position, instead of the immoral position?
This is technically true, and nobody contested the CABF's focus on HTTPS TLS.
However, eventually, the CABF started imposing restrictions on the public CA operators regarding the issuance of non-HTTPS certificates. Nominally, the CAs are still offering "TLS certificates", but due to the pressure from the CABF, the allowed certificates are getting more and more limited, with the removal of SRVname a few years ago, and the removal of clientAuth that this thread is about.
I can understand the CABF position of "just make your own PKI" to a degree, but in practice that would require a LetsEncrypt level of effort for something that is already perfectly provided by LetsEncrypt, if it wouldn't be for the CABF lobbying.
> CABF started imposing restrictions on the public CA operators regarding the issuance of non-HTTPS certificates.
The restriction is on signing non web certificates with the same root/intermediate as is part of the WebPKI.
There's no rule (that I'm aware of?) that says the CAs can't have different signing roots for whatever use-case that are then trusted by people who need that use case.
> The CA/Browser Forum is a voluntary organization of Certification Authorities and suppliers of Internet browser and other relying‐party software applications.
IMHO "other relying-party software applications" can include XMPP servers (also perhaps SMTP, IMAP, FTPS, NNTP, etc).
It is a single member of the CAB that is insisting on changing the MAY to a MUST NOT for clientAuth. Why does that single member, Google-Chrome, get to dictate this?
Has Mozilla insisted on changing the meaning of §1.3 to basically remove "other relying‐party software applications"? Apple-Safari? Or any other of the "Certificate Consumers":
The membership of CAB collectively agree to the requirements/restrictions they places on themselves, and those requirements (a) state both browser and non-browser use cases, and (b) explicitly allow clientAuth usage as a MAY; see §7.1.2.10.6, §7.1.2.7.10:
Knocking down half the towns that the WCML runs through to build more tracks carrying trains that aren't going to stop there would be neither easier nor cheaper than HS2.
Do you think the people who designed HS2 have not considered these aspects?
You analysis is very narrow and only considered the benefits to a certain set of people.
HS2 actually follows reasonably closely to the old GCML. And for the same reason, its the best route to build a fast rail-line along.
I think your proposal complete ignores the additional cost of such a route change. And the cost alone, aside from anything else would make it unreasonable.
Many things go into selecting a route and in most cases where I think they made the wrong choice its usually because of cost concerns, like not building the needed tunnels into cities.
The reason HS2 route cost so much money is because so much is tunneled. Why is so much tunnelled? Because rich people live there and won't accept a blot on the landscape, partially because they don't see a personal benefit.
If you can remove the tunnels it doesn't really matter that the route is slightly longer or has slowly less optimal geometry.
That not totally true. Yes, HS2 spend additional billions on tunneling. But even without that you don't magically solve all the issues and in some places where they do tunneling its actually not completely stupid. Tunneling accounts for a few billions, not many 10s of billions.
And you don't get magically rid of all issues with people complaining, because guess what, other people live on that other imaginary route that lives in your head, and they would demand tunnels too.
And its really the politicians fault, a few people who don't like the look of the train should not have the power to stop it, specially not in a place as centralized as England.
The subtext here is that there's a difference between someone saying "I don't like this community, I'm going to make my own" and "I don't like this community, I'm going to change it".
Building communities is hard. It's not obvious why someone who wants a community on their terms gets to piggyback on an existing community rather than putting the effort in to make their own.
The point of "just fork it" is that if your ideas are popular, then sustainability shouldn't be a problem.
Every community is the sum of its members. Each person who joins changes it, at least a bit. And each of those members is changing and growing.
When community members have different needs, forking should be a last resort. It's expensive, and it's wasteful unless two different groups have irreconcilable needs. It should only ever be suggested as a last resort, after other options have been exhausted.
However, it's often used as a first resort to shut down criticism and to protect existing power structures. The person who speaks up is, as here, treated as an outsider and an exploiter.
I rarely see good faith engagements being immediately shut down with "just fork it" (you'd never accept issues / MRs!). Instead it's usually used as a last resort when the "exploiter" doesn't get their way and starts whining about it.
If a change is proposed that's completely counter to a community's stated values, then I guess "fork it" is a more appropriate immediate response, because it's hard to see how such a clash could be resolved without fundamental change.
Edit
> Every community is the sum of its members
A community is much more than the sum of it's members.
> Instead it's usually used as a last resort when the "exploiter" doesn't get their way
I am not saying the phrase can't be used legitimately. Like the article's author, I just think it's often used in a way that isn't. Perhaps we're sampling from different areas of open-source culture, but when I think specifically of HN, I think just-fork-it style responses of the kind that the author is criticizing are common.
> A community is much more than the sum of it's members.
Sure, I agree with that. But you write it as if it's in contradiction with my point, which I'm not seeing.
> But you write it as if it's in contradiction with my point, which I'm not seeing.
My point was that a community is members + values + practices + other stuff. In the case where one member who wants to upend the values and practices of an existing community, "just fork it" is an entirely reasonable response.
I imagine with coding agents, maintaining private forks (reapplying patches on upgrade) will be a lot easier. Though, a plugin architecture would be better, where feasible.
If there there's a big enough community swapping patches that upstream isn't accepting for some reason, that's when a public fork becomes reasonable. (This is the Apache web server's origin story.)
The problem with that premise is that often, projects can be having trouble with sustainability already, so even if you're getting 90% of the people in your fork, that might still be too few.
If 90% of the contributions are by 10 people, if the project is large enough, losing one of them is going to be an enormous additional tax on people unless you can get an additional one to step up.
It has to be the source of the distribution the user currently has a copy of. So they can't just say "sure" and then wait until the next public release. I'm not sure about timeliness, though.
> I have generally told that story with the ISV anonymized -- but you clearly found an example where I named them.
It was on one of the OaF podcasts about dtrace. I worked for Reuters at the time and contempt for their customers was definitely a thread that ran through some parts of that org, even as it made a bunch of us feel very icky.
(I still have a side quest to find / talk to some of the people involved on 'our' side of the fence about this!)
There's a bus factor equivalent with the cloud, too. The power to severely disrupt your service (either accidentally, or on purpose) rests with a single org (and often, a single compliance department within that org).
Ironically, this becomes more of a concern the larger the supplier. AWS can live with firing any one of their customers - a smaller outfit probably couldn't.
Tags are not immutable.
reply