Comment by freshhawk
9 years ago
If the main developer doesn't want forks then don't use an free/open source license. It is very simple. "Capitalise on others work"? That's insane, that license is very explicit that this work was donated to the public under well specified terms. It welcomes all of us to capitalise on it, that's the whole damn point.
There is a single sufficient "good reason" to fork a project. You want to. People are free to use your fork or ignore it.
The point was not against forks but transparency and good faith. Open source is not just about forking but also contributing, no?
What have the forkers contributed to the product so far? Where are the technical reasons for the fork? Where is the community discussion and consensus? Has there been any kind of democratic action? So on what basis is the word 'community' used?
A fork shoud not simply be about people misusing the word 'community' for seeking control and ownership because that's not what open source is about, is it?
As already said, nearly all people in the org are former Gogs contributors, the owners have been elected by the other people who joined the effort, everybody who has contributed 4 pull requests can join the maintainers team of gitea, the owners will be elected every year by the community, EVERY scripting for the infrastructure and the website and so on its entirely published. The only thing that is a secret shared between the current owners are the secrets for the services like github tokens, github oauth or email credentials. Everything else is open, accessible by everybody.
> What have the forkers contributed to the product so far?
A lot of the forkers and go-gitea group members wrote essential features for Gogs and contributed thousands of lines of code. They simply got impatient waiting sometimes 3 months for their PRs to get merged. Especially bkcsoft did tremendous work on Gogs. As a contributor to Gogs that stopped contributing because whose last PR wasn't merged for a very long time, I welcome Gitea's idea of a faster development schedule.