I think you are right about how GitLab started. There is, and there should be, a lot of frustration about the biggest open source hub (GitHub) not being open-source themselves. This feels backwards and creates a harsh dictatorship that shouldn't be. GitLab tried to solve that by making an open source version and because it now can be improved upon by everybody new features start to appear. I love the self hosted aspect of GitLab and I think they should keep focussing on that however their instance of GitLab [1] is notoriously slow and unreliable. A hobbyist should not need to host their own repo, they should be able to rely on their SaaS. I would love it if GitLab.com could be rock stable like GitHub

[1] http://gitlab.com

> A hobbyist should not need to host their own repo, they should be able to rely on their SaaS. I would love it if GitLab.com could be rock stable like GitHub

Believe me, we would too and we are sorry about the current state of GitLab.com. We are working on improving performance in Q1 2016: https://gitlab.com/gitlab-com/operations/issues

It may be more stable than GitLab, but I have never thought of GitHub as "rock stable."

Can you comment more on why a hobbyist should not need their own repo? If I'm doing SaaS for everything, my monthly costs start to go up. I've found it is far cheaper, and far (way!) more educational to take an extra box out of the basement and install Ubuntu/GitLab/Node/Java/Apache/Etc. I have to pay for internet either way, and the electricity cost is nowhere near the cost of having multiple Saas?

Most of the time, it's because of opportunity cost: The time you're spending building a server, learning how to manage repos, setting up redundancy and just trying to get the thing working, you could've spent on whatever product you were trying to produce, and would likely be much further along with if you hadn't done everything the hard way.

That's not to say there isn't educational value, but a common piece of advice I've gotten is "Don't optimize for anything but your life." Or more easily explained: Don't optimize for things you don't need to.

The opportunity cost on the front side is often worth it but the long term benefit on the back side is you aren't dependent on that SaaS, are running stuff you know something about and have a lot of flexibility.

I'm from the old school, I use SaaS/PaaS mostly for stuff I know is painful to do yourself (sometimes file storage, nearly always email) but the rest lives on vanilla boxes configured with ansible (frankly ansible is faster to use once you get your head around it than learning 5 different PaaS setups).

Can you suggest a good way to get started with Ansible?

The ansible docs are excellent and walk you through the process, one thing I did (and would suggest) is use vagrant (or similar) with ansible, it has built in support for it and it allows you build/tear-down way faster while you are learning.

I just installed Ansible on a workstation and started playing with it to configure a server (the server only needs SSH). Or, use this guide:

http://www.ansible.com/get-started

Building on the other answers, I think it is more awful for pros. Hobbyists don't have deadlines and spend time on computers because of love, not to pay rent.

That said, you do have a point, and you decide what matters to you as a hobbyist (or whatever you decide to call yourself).

I personally like (and need, most of the time) stuff that "just works", so I totally get your point about optimizing and agree with it.

what's the cost of freedom and independence ?

I'm personally glad to have done things the hard way, sure it took some time to learn but learning sysadmin made me a better developer.

To me, setting up a repository, an issue tracker, a wiki etc. was more about learning about a process than learning "how to make it work on the server".

Process as "how to organise the production of writing software" and this is imho extremely important, I reuse what I learned all the time from web app to mobile app to server backend etc.

Simply put, I see a lot of people who fail to deal with software production simply because they just use the tool "a la mode" like Github, but are completely oblivious to the benefits of using semantic versioning, an issue tracker, a wiki for documentation, etc.

When you learn all that by yourself, you can compare different tools and have a feel for what's a "bare minimum", you just know how to manage/organise a project a make it work in production.

Time isn't free and maintaining Gitlab, for instance, eats up maybe 30 minutes a month.

Maintaining the 10x SaaS services you use in a similar vein suddenly starts eating up close to whole days.

> A hobbyist should not need to host their own repo, they should be able to rely on their SaaS. I would love it if GitLab.com could be rock stable like GitHub

I completely disagree, here a little story

before 2005 I was hosting my own SVN repos, then came a community "we host your open source project for free" and I moved my sources there

and it closed, so I moved all my repos (they kept growing) to google code

my main reason to move to google code was "its' google they will never close down"

guess what? few years later, google code close down

at that point I decided NERVER EVER AGAIN, I moved all my repos to my own private dedicated server

now I do use Github but as a mirror, they can close down tomorrow I don't care (note: I don't wish them that)

Some people take their repositories very seriously, hobbyist or not, for me it's like backup you only see how important the infrastructure is when the shit hits the fan.

Things like Github, Gitlab, etc. are nice but it's merely a beautiful web UI on top of what is important: the repository.

My point is even if you are an hobbyist you should own and control your repository, if you can host it on a dedicated server, or at home on a spare box, whatever, do it, do own it (the infra), yes because a tarball archive of your repo and a JSON export of your issues is completely useless.

> you should own and control your repository

Doesn't every distributed system let you keep your own repo under your control? I have all my projects on github but if github disappeared tomorrow I'd just push my repos to a different service.

As a hobbyist I only commit one small thing a week or so without any issues. I'm curious what stability issues they have for later projects, if you'd care to elucidate?

We are dealing with a lot of sensitive data and code which is legally not allowed to physically leave our group and GitLab is in my opinion the best open source choice for that.

I feel its community edition is up to par with github in most aspects and it a was a change towards the better from our previous svn based solution (Redmine)

A good friend of mine likes to run https://gogs.io/ .. I havent used it heavily but Ive been impressed so far.

I wonder why they advertise the "platform"/implementation language so clearly (in this case Go). It shouldn't matter for the users? I get sceptical, as if the only reason they exist is to provide the same service but in a new implementation.

Performance. That thing is _fast_ when compared to a Ruby-based stack.

Does this really affect end users? In the end, this decision should mostly mean less servers, no...?

Sysadmins are people too :)

I've been using Gogs for personal use for a while. I love its speed and its simplicity.

That said, it's probably not a good fit for most businesses at this point. It's relatively new, and mostly maintained by a single developer, who spent the last summer on vacation.

He's very active when he's around, and almost always working on improving Gogs, but there's a lot of people with features requests (the issue that's always getting comments today is for opening pull requests across branches within a single repository -- i.e. not forking.)

It's a bit of a pity that they don't self host, even if they also have a Github repo.

I was unaware of this. Thanks for the link.

It seems just about everything is being re-written in Go these days...

Go is easier to deploy than Rubby on Fails.

> Go is easier to deploy than Rubby on Fails.

You could have said that without cheapening the level of discourse.

Does that even matter in the world of Docker?

Yes, because not everyone uses Docker yet. Some may never adopt it. So long as that remains a viable path, then the matter of deployment systems and complexity is relevant.

Unless you are smart enough to be a Rubyist.

If you're not you just seem like someone who came to the NodeJS Party late and didn't understand Go is C for gigantic codebases using parallelism. :D

You should also consider Apache Allura (https://allura.apache.org/), Fossil (http://www.fossil-scm.org/), Phabricator (http://phabricator.org/) and GitBucket (https://gitbucket.github.io/gitbucket-news/).

There's also Stash (now renamed to BitBucket Server (edit: fixed name, as pointed out in the reply)). It does not include some of the features (such as issue tracking), and I think rightly so. I haven't used GitLab for maybe 2 years now, so I can't compare the two.

To be clear, it doesn't support issue tracking because it is an Atlassian project. Issue tracking is done through Jira, another product they offer.

Umm no, you are incorrect. Bitbucket does have its own issue tracker like GitHub.. (but it is not turned on by default) and what I am referring to is NOT JIRA Software.

https://confluence.atlassian.com/bitbucket/enable-an-issue-t...

That looks to be for Bitbucket Cloud. We were discussing Bitbucket Server, the hosted solution.

It's named bitbucket server or something like that - don't confuse it with bitbucket proper.

We've been using GitLab CE internally in our organization for more than a year. We needed an on-premises solution because of the company's policy. The experience has been great thus far.

On EE, there's nothing that we miss from the EE version, although we might end up going with EE after the team will grow. We also have dedicated dev-ops, otherwise having support for it would sounds good. And the pricing for EE if you go that route is much better than for GitHub Enterprise.

Personally I have mixed feelings about the "open core" model, as many times it's just a marketing stunt. But for now that's not the case with GitLab.

Thanks for sharing your experience. I'm happy to hear that in your case the feature tradeoff we made between CE and EE worked out.

> I still don't know how I feel about GitLab. My initial reaction was that they were an underhanded, cheap knockoff of GitHub. It felt kind of dirty, like they were stealing GitHub's thunder and giving it away for free.

Seems like they were just following in the footsteps of one of Open Source's great prophets: https://en.wikipedia.org/wiki/Richard_Stallman#Events_leadin...

Richard Stallman is the "prophet" of free software. The EE license is not a free software license (and probably isn't an open source one either). The given license doesn't give you any of the four essential freedoms.