Comment by aliqot
3 years ago
> First you do the right thing and kindly ask to repair trust that has been breached
Gitea is a self-labeled "DoOcracy". nobody owes an apology. forking is inherent to open source methodology. ideological conflicts help nobody but those who lead them. the fact is that the work is done by few, and those few have decided to exercise their rights in open source to do what is their prerogative.
> the fact is that the work is done by few, and those few have decided to exercise their rights in open source to do what is their prerogative.
There's a whole bunch of contributors to this project, who've never been informed. Even maintainers were caught by surprise as only some marginal bits of info were apparently spread.
A project creating CONTRIBUTING guidelines, then Owners not honoring them? Effectively just pretending to be a community-driven project. Probably legally the ones incorporating have done nothing wrong. And culture, norms don't count in business world. But they do in free software community.
Yes, a fork may be in order. But technically this could still be mended and things be put right.
What contributing guidelines were not honored?
https://github.com/go-gitea/gitea/blob/main/CONTRIBUTING.md#...
The current holder of the domains and trademarks was elected as the custodian for a limited time (through the end of 2022). The terms of that election included an agreement to hand over custody to their eventual elected successor. But they've instead created this for-profit company and transferred it ownership of the assets.
What happens when a new custodian is elected by the community who is not affiliated with this new company? Will the company give up control of the assets as previously agreed?
I feel you're missing the point. This person is saying that one should communicate first. If you perceive communication exclusively as "activism" or "apology" seeking (or cancellation?), then I understand why you might not choose that path.
But others often choose open comms before heavy action, and many contributors would support that.
And yes, "forking" is subjectively a heavier action to some ppl. It's subjective, for sure. To each their own, I guess :)
Respectfully, I'm not one who would take or support your advice to act earlier (and such is my right)
What an absurdly condescending and inaccurate comment, especially for someone saying just fork it instead of actually interacting with people to try to reach resolution of an issue. “Just fork it” is literally the opposite of working with others.
Splintering an ecosystem can end up with a worse outcome for everyone. A fork that no one cares about, created because someone had a tantrum instead of reaching resolution is not a home run. It will eventually fall so far out of sync with the main project that it will no longer get any of the maintenance or other benefits of a large project.
1 reply →
I'm having trouble understanding why you're so bothered by people having a quick round of communication or two before deciding forking is necessary, when it's possible it may not be.
It's not "get[ting] mad about a ball game", it's basic communication. Right?
Forking is inherent to open source methodology, however many open source projects depend on a community of contributors and users to maintain the project, fund it, and push it forward.
While a simple personal fork of a repository/codebase is not very aggressive, forking a community (or attempting to) is a pretty significant step that will almost always create drama and bad feelings.
Working to communicate and resolve issues before attempting a fork of the community is always a good idea since they should be avoided when possible.
While the owners of an open source project absolutely have the legal rights to do as they wish, if those owners are interested in maintaining a community around their project, it behooves them to listen to that community, especially to those who have put their own time and effort into that project and community.