I just setup the Gogs docker image the other day to play with, and it seemed pretty painless to me.
Edit: I just found https://blog.gitea.io/2016/12/welcome-to-gitea/ which somewhat answers this - essentially a different governance model and more development, but not any major functional differences.
I set up a private gogs server at work in about 1 hour (most of that time was spent learning how vagrant works with ansible). My first reaction looking at Gitea is how similar it looks to gogs. The landing page seems identical.
If you're like me and were staring at Gitea's web site thinking, "dang, how do I run this as a daemon," Gogs (from which Gitea forked) has a nice page on doing this: https://gogs.io/docs/intro/faqs.html
The link shows how to run the app, not how to run it as a daemon. That said, the answer is platform specific, although it would be useful to have some common examples.
Another great thing is, they offer a lot of binary releases, especially for ARM platforms, so it works out of the box on e.g. Synology NAS (the Marvell based ones).
It's because Go doesn't use gcc or LLVM for linking - it has its own built in linker that doesn't depend on the host system, so cross-compiling is totally trivial. I have no idea why gcc wasn't written like that.
I like it. At my work(big corp that built a wall for for all engineering work and prevents engineers from using SAAS), this will be very helpful as it is a single binary built from open source Go. I'll try hosting our team's internal scripts and tools through this.
I'm eagerly looking for a solution good enough to let me ditch our current paid/hosted service. Gitea seems like it's getting really close, but a couple concerns linger:
* how does the pull-request/code review UI look? didn't see any examples on https://try.gitea.io/ or main website
* mobile/responsive UI would be really nice for small screens
This time looking at this, I notice they have Dockerfile.rpi.
the kicker for moving to gogs from gitlab was that gogs had a prebuilt official rpi image... but it was several version behind the x86 one. I have no issues building images myself, but usually it feels like a lot of hoops to jump through to make things work on rpi. Having an rpi dockerfile really just makes me feel extra comfortable about things - not having to worry about weird x86 only dependencies and having to resolve them myself.
That's great! Zero-dependencies services are much appreciated.
In line with recent discussion how Maintainers Don't Scale [0] I think that software like this is a bit of an answer for dev-tools.
I think that kernel developers prefer tools that they can reasonably understand. Eventually tools that are easy to host (while having certain mindset). That's why most kernel related web services are probably written in Perl, in C (cgit) or in Python to some extent. I think Ruby on Rails or Java is not compatible with this mindset. Maybe Go is?
When I am thinking of self-hosted web facing services myself I have similar mindset. Every time I see that it's written in Java, Ruby or Node.js I pass. For certain it's many times counter productive, but I can't (or don't want to) help myself.
I tried to find the source behind LKML, but it's hard because most searches containing LKML will be just kernel related. It probably is written in Python as the developer behind LKML is a Python developer.
I have been using takezoe/gitbucket for a while now and have been happy with it , gitea seems to be the new kid on the block :), its also impressive to note that DigitalOcean has sponsored their hosting. One advantage I see with Gitea is that it uses Go and this will give it the power of scaling. Congratulations to the team and I look forward to the evolution of gitea
I read through the Gogs repo and there didn't seem to be any organized 'community' of users or talk of a fork. The author was away for a couple of weeks to come back to this news.
Is open source about contribution or just forking? At the moment it seems the the best way to open source is to be a well funded project with tons of resources and people specifically to manage the community because of intense expectations with projects declared dead even for one week of inactivity by some users.
What I am increasingly noticing with small teams or one man projects is if the project gains some popularity some 'community' folks pop up who first place an oppressive burden of expectations on the author and then try to fork the project. There is some element of misuse of the word 'community' by a small clique of people.
Why are community expectations so high, is continuous development and an ever expanding feature set the only way to develop? I think a culture of undue pressure is being created on open source authors and projects.
gitea was initially just a fork so development could continue - with every intention of merging it back into gogs.
However, Unknwon, responded here [0], let me point out his main reason for not merging back:
> Gitea won't be merged back to Gogs, it's not about merging work is huge and hard, it's the differences of fundamental philosophy. I personally do not like to push hard to release new features, but make code neat and clean, it's not good for business, but Gogs isn't a business, making it is what I love to do.
Success in open source is simple and hard: make useful code and let others help make it even more useful (and better). Being well funded isn't a requirement, and may be a two edged sword (docker vs rethinkdb).
Exactly. I had, at one point, run through all of the latest open source offerings in this space. Right after I got everything up and running, the initial whisper of maintenance came back and I purchased the entry level GitHub subscription. There are other aspects which help these commercial offerings as well, such as brand affinity and switching costs. This usually leads to more newer developers using the same platform as their colleagues, thus prolonging the aforementioned brand affinity.
While I agree with your second assertion, I would think that most companies would prefer to have on-premises hosting for their intellectual property. Github and Atlassian offer this.
My impression is that many large organisations would prefer that, but most small organisations would prefer to outsource these kinds of things if possible. From a perspective of how much money you will make, I think focusing on the small organisations will be better. The economies of scale just don't kick in until you have a couple hundred employees (or more!). Especially from the standpoint of security, most small organisations simply can't hire the staff they need (couldn't afford them even if they could find them). So there is a solid market need there. On the other side, large organisations have the skills they need to roll their own if they choose, so your business plan has to rely on walking that line of offering software/services more cheaply than these big organisations can do for themselves. Personally, I think that long term this will be a losing battle. Although Github has a strategy for large businesses, I think they are better positioned to service small businesses. For this reason, I much more bullish on Github than I am Atlassian (which seems to tie their horse to enterprise at every turn).
Wow, that must really sting. They literally stole his creation. He shouldn't have released it under a permissive license if he's not willing to collaborate.
So first of all, no one stole anything. Wether the author should have released this under a permissive license or not is a different debate. However, he did, so no stealing, literally.
The author is also not unwilling to collaborate. Just look at the history of accepted PRs for example. However, he is unwilling to give others wider access and control over the direction of Gogs (which is totally his right):
> This happened not before trying to convince @Unknwon about giving write permissions to more people, among the community. He rightly considered Gogs his own creature and didn’t want to let it grow outside of him, thus a fork was necessary in order to set that code effectively free.
As to whether it stings I'm not sure. They had conversations around this topic and the conclusion was that a fork was what's needed for what (part of) the community wanted. Though it's possible for the original author to see this as a slap in the face I hope he sees it more as a huge testament to what he's achieved with Gogs so far.
The original author has absolutely no duty to be willing to collaborate or to spend X amount of time on his project (which seems to be the bigger issue here, project blew up while the creator has less time for it), permissive license or not. He can run his project however he likes. And with the permissive license, those that disagree can run their fork however they like. No stealing or bad blood necessary.
> 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). [0]
