Sure, community managed sounds great, but does that automatically guarantee a solid project vision, predictable release cycle and lots of new features?
Don't want to sound negative but I think reasons for the fork needs to be clearly presented and potential switchers (like myself) got to be assured there's a better future with the fork rather than original
Right now, the initial release was pretty much just a cleanup effort to get the codebase ready for the new changes that are coming down the line. If you look at the PRs open for 1.1 there's a lot of goodies coming that I'm looking forward to.
I can't help but think about the open source maintainer burnout that has been featured so many times. Let off your project for a couple of weeks and you have all sorts of people demanding write access to the repository. That must be up to the mainatiner and his or her vision for the project.
Don't misunderstand me. Fork away. Forks are the social contract open source software stands on. But please, for the sake for the health of everyone around us, think of what language you use. Someone hasn't "disappeared" just because they're offline for a while. Make him or her proud or their community and what they did in the meantime instead. That's also a fork, just much less of the "I took my stuff and left!" vibe.
And I realize I'm overreacting to the choice of a few words on a project I've never been involved with and never seen before, it's just that some forks are just hostile for no apparent reason whatever and it's so unnecessary.
And forking is exactly how open source is supposed to work, you disagree with how something is run and you fork it. A lot of contributors weren't happy with how things were and they forked it, it's how open source should and does work.
And yes, I do think you are overreacting. I've been following and using Gogs for over a year now and the maintainer going away for months at a time has been very annoying, so I'm happy to see Gitea work.
The main dev seems to be a good guy and it was always a good experience to communicate with him on bugs/features or pull requests.
He is a single point of failure, though. There were quite some active contributors to Gogs. They work on Gogs quite a lot, fixing bugs and improving it. Even simple fixes like typos don't get merged for weeks. And that's when Unknwon is available. When he's gone, he's just gone and other developers have no idea if the project is dead now, or not.
Most of the recent activity in Gogs development came from the people who now work on Gitea. I hate that this fork happened because I really don't like the Gitea name and logo.. but that's where the development is happening now..
Graph of commits over the last year:
Less noisy graph that only shows master vs master:
Changes in the last 3 months:
Contributors in the last 3 months for Gogs:
Contributors in the last 3 months for Gitea:
This is the entire history.
Which shows the number of unique Go files to have ever existed to be 407 in Gogs and 1,753 in Gitea.
I'm guessing some files were moved around. I'll do a bit more digging and update if I find anything interesting.
This a diff from the point of divergent to the latest commit for each branch.
Gogs (69 commits with 106 diffs):
Gitea (528 commits with 2,062 diffs):
Even this is the case, Gitea has a lot a bug fixes that are still pending on Gogs.
So the difference isn't as drastic as it appears.
This was an issue when I tested Gogs a few months and I don't see any mention of a cache so I think it's still an issue.
For smaller repos though, Gogs works incredibly well.
Regarding this fork, it makes sense if the owner of gogs is not giving write access to others. At the same time it would be a shame if Gitea becomes popular and overshadows Gogs. I hope they can work out a mutually acceptable solution and merge.
This time, the community patience ended, and Gitea will continue on its own way.
I just want english so I can have some kind of understanding of what I'm doing but I can't find the setting either in my user profile nor in the app configuration.
LANGS = en-US
NAMES = English
Edit: tried and indeed it seems to work.
Odd to implement i18n and then automatically choose based on UA, but not have a user option?
Anyway, I think this is how OSS should be. We shouldn't have to force people to merge the code that we want. At the end of the day, it's his project anyway.
Good luck to both of projects.
My name is Angela and I do research for Atlassian. I’m kicking off a round of discussions with people who use Git tools. Ideally, I’d like to talk to people that sit on a team of 3 or more. If this is you, I would love to talk to you about your experience with <using> Git tools, or just some of the pain points that are keeping you up at night when doing your jobs.
We’ll just need 30 mins of your time, and as a token of my thanks to those that participate, I’d like to offer a US$50 Amazon gift voucher.
If you’re interested, just shoot me an email with your availability over the next few weeks and we can set up a time to chat for 30 minutes. Please also include your timezone so we can schedule a suitable time (as I’m located in San Francisco). Hope to talk to you soon!
Now if the project has potential or takes off a 'community' should fork it only if all other avenues have been exhausted and with good reasons.
Its important for a 'community fork' to let the community know the exact rationale or 'community' can easily becomes a excuse for some to seek to control or capitalise on others work. This does not help open source especially if the main developers are too busy developing while those who fork have time to market the fork to a community.
There is a single sufficient "good reason" to fork a project. You want to. People are free to use your fork or ignore it.
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?
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.
I think if gogs/gitea was self-hosting it would encourage the developers to find easier ways of collaborating.
This is my only complaint about gogs. It is amazing otherwise, suits my needs, is low maintenance and is an impressive piece of work. I would encourage anyone to try it that wants to have private repositories for personal projects.
Tracking Issue is https://github.com/go-gitea/gitea/issues/26
This is not the reason of the fork. The reason is that he refuses to give more people write access to the project to keep it going.
Before the first time he went AFK, he even removed write access from the 2 or 3 other people that had it.
Others don't need write access "to keep the project going" unless they intend to ship releases without him/her- they can make PRs and the maintainer will merge them when they are back. Perhaps the Gitea committers want a more predictable release cadence?
I agree that a fork is probably the best solution here, due to the impedance mismatch, the forkers don't seem to be fans of the BDFL model. Additionally, "community" is a much wider term than how you used it, it's not just other contributors but also includes users and bug reporters. I wish Gitea the best of luck, but I'll remain a Gogs user.
Forking is not a decision to be taken lightly. Even the most just fork will fracture the community and weaken the software's development. Contributors are now being asked to take sides and both sides are getting fewer contributions. The stress this puts on the original maintainers is also non-trivial.
Look at ffmpeg/libav. It forked for similar reasons on the surface, but in reality it was to forcibly take control of the vernerable project over petty disagreements. For years the users and developers suffered alike as libav was shipped by default in Debian due to politics and received subpar workmanship and more security vulnerabilities that were fixed on slower schedules, all while taking contributors and users away from ffmpeg. After nearly a decade libav is finally dead in the water and ffmpeg is becoming the default on Debian again, but not after lots and lots of damage to the project.
On the other hand, you have examples like nodejs/iojs, where there were much more tangible reasons and alternative solutions were explored longer and more earnestly, and they regretfully were forced to fork for the good of the ecosystem. And they were right, eventually the two projects merged together under better oversight.
But the gitea folks do not have nearly as much clout behind their efforts IMO, and as a result their move to fork is extremely harmful to gogs development.
Considering how fast GitLab is moving, if Gogs/Gitea wants to remain relevant, they really have to move at a much faster pace than they use to. Judging by Unknwon's comment in this issue
it seems like Gogs is driven by a passion and it doesn't matter at the end if he is the only user. As he puts it
> Gogs isn't a business, making it is what I love to do
I'm not sure if his stance has changed, since this issue was from July. I'm also not sure, if he fully realizes he is sitting on a potential golden goose. The market for Git hosting in Enterprise is still very much up for grabs.
Gogs is written in Go, easy to install, light on features and is lightning fast.
Gitlab is mostly Ruby (with some Go), a mess to install, heavy on features, and (at least gitlab.com) extremely slow.
I don't see how they compete at all.
As you point out, you either go with fast vs feature rich.
GitLab is working towards making things faster and easier to install. Is Gogs/Gitea working towards making it more feature rich?
If Gogs market are hobbyist who want to run it on a Raspberry PI, then I don't see GitLab being a threat. If Gogs wants to be solution that larger companies would consider using, then they are going to have to compete with GitLab's, which means introducing more features.
This Gitea fork appears to be a desire to move faster with more features. I've posted this in another response, but this a diff from the point of divergent to the latest commit for each master branch.
I obviously haven't gone through a lot of the diffs, but the changes appear to be formatting/commenting like this:
with others adding more functionality like this:
No matter what, it looks like there maybe no turning back for both groups. Hopefully this is not the case.
This issue was updated this morning with a plan to speed things up: https://gitlab.com/gitlab-com/infrastructure/issues/947
The maintainer cares about code quality, it seems like gitea does not
He can't expect others to not want to push for greater git mindshare. Gogs is licensed under mit and he has absolutely no say in how others want to evovle it. This is how permissive licenses work.
To expand on the goose metaphor, attempts to extract additional value from a goose that lays golden eggs oftentimes kills the goose: I'm sure a few years ago some VCs looked at CyanogenMod and saw loads of potential, but here we are.
It's perfectly fine for Gitea to evolve or even monetize via Gitea Inc, but it will continue to compete with Gogs if the maintainer wills.
The project that explicitly donated its code to the public to use and re-purpose as it saw fit you mean?
I got confused by the use of the word "took". And that you seem upset that other contributors get to choose how they want to contribute, even if the originator disagrees. So they are volunteering wrong? Or Hobbying wrong? Glad you can set them straight.
There are plenty of systems of generating code where the creator retains these rights and things are organized in a top down hierarchical manner. These are what FOSS license are explicitly fighting against.
"In my point of view, it's a sign of success of Gogs that Gitea forked it. Gogs is under MIT license and there is no problem with me totally that Gitea is developing its own version. It happens often in open source community(when you are not satisfied with upstream version, I fork a lot actually)."
In the same issue comment Unknwon also states that they believe Gogs and Gitea to have fundamental philosophical differences, and finishes off with thanking everyone and wishing happy coding.
I don't know all the facts and Unknwon's personal view may have changed in last 18 months, but just judging by the philosophy of the original author and maintainer of Gogs the lack of courtesy, tact and respect of their roots that you refer to might be an opinion of yours that Unknwon doesn't share. If that is so, then what do you mean they lack courtesy, tact and respect towards?
Of course, if I'm mistaken or there are more recent opinions of Unknwon's that contradict this, then please disregard this comment.
One faction of developers parted ways with another faction because they disagree on direction, in this case the minority faction has the rights to the name. We get a choice, they all get to donate their work to the public as they wish to.
This is unintuitive to our ape brains, but it is objectively better to remove ego and status concerns from collaborative projects.
Sure. 100%. It's up to him for how he wants to run an OSS project.
In the same way, if people in the community have different ideas they're more than welcome to fork. If you don't want that to happen, either listen more to the community or don't open source a project.
what a stupid excuse, reminds me of people excusing the creator of Coffee Script because "Jeremy he was busy". if your work depends on an open-source project and the author "has life" so that critical bugs aren't resolved or important PR aren't merged then the only mature thing is to fork and let the maintainer get "life" as much as he wants. Because he is not irreplaceable
Sure, 'copy' the features, and take inspiration from the UI and layout, but so much of gogs looks identical to GitHub that it's nothing but stealing.
I mean it's not like someone's breaking into GutHub's server room and stealing equipment.
You want to say it's a breech of copyright, patent or trademark? Maybe.
But then FreeBSD "stole" Unix, Windows stole Mac, Mac stole Xerox, Microsoft stole WordPerfect, and so on.
My point was around the developers being seemingly okay with ripping off Github's UI.
I agree that no one is being harmed, but personally I just thing it's shameful.
also I agree with you that stash and bitbucket are Really Not That Great.