GitLab.com runs the proprietary GitLab Enterprise Edition (EE). This is mostly to allow us to performance test EE features at scale, for more context see https://about.gitlab.com/2014/06/27/gitlab-com-runs-ee/ You can use the open source GitLab Community Edition (CE) to start a SaaS similar to GitLab.com. We hope people will recognize that CE is not crippleware and will be OK with hosting their code on GitLab.com. If not there are alternatives based on CE such as https://modernrepo.com/
Yes I've read that context and it makes sense. I was just observing that some people would want an absolutely pure (ie 100% free software) option rather than critiquing what you offer.
That said I do hope you take steps to reassure people who want to be using an option which preserves their software freedom, for example that the CE will not be slowly deprecated, more features moving into EE.
I admit that making a fully credible commitment is challenging: options include multi-copyrightholder-copyleft which presumably you don't want at all as an MIT licensed project + some proprietary bits in EE, and a variation on the Fiduciary License Agreement used for Qt. But those two options are copyright-focused; there are probably other mechanisms to be thought of.
We try to reassure people by adding more features to the open source version every month. In fact, since we released the proprietary enterprise edition, the pace of development for the open source version has accelerated. We never moved any features from the open source version to the enterprise edition and plan to never do this (except in edge cases with overlapping functionality). We're happy with the current MIT license. We tried an MIT license for the enterprise edition before but that was very confusing to customers.
I've been running Gitlab CE for a few years on a linode instance for a couple of dozen repos and it's really quite excellent; performance is very good. You do need to keep up with the monthly upgrades to get the new features (there's an upgrade script).
Recently Gitlab CE has undergone some quite significant UI updates along with very noticeable performance improvements. Excellent work guys!
If I read that uncharitably, (except...) looks like ample room to lead to the eventual demise of the open source offering.
But adding more features to the open source version every month is great. Hopefully that and a massive userbase sums to making it obvious that any substantial move towards deprecating the open source version will lead to a successful hostile fork, as there will be tons of people able and interested in doing that if necessary, resulting in you never making it necessary. :)
It is sad that enterprises are confused by freedom rather than demanding of it, but that's an issue for the software freedom movement to solve.
This is the big key to open source. The proof is right there. The source is out there, so you can't turn that source evil, people can just take it and run with it around you if you try.
I build and admin a public RPM repo for our product. After installing gitlab's RPM, I was blown away. I have never seen a single RPM that large work that perfectly on the first shot. Either I am lucky, or more likely, you really put a lot of effort into your packaging. Cheers to you for a brilliant demo.
It didn't quite fit into our workflow - I think we would like to use gitlab as a beautiful web client, but then push our code there back into our own vanilla git repo on https/ssh. Gitlab seems as it is a turnkey product, repo hosted internally. It was certainly very easy to import our existing projects into it.
Good to hear that! We put a lot of effort into packaging GitLab to make it a 2 minute install even though it is a Rails application. We could not have done it without the awesome Omnibus packaging system that Chef so kindly open-sourced.
May I ask what the reason is you don't want to host the repo's in GitLab itself?
First I want to thank you and the developers for your work on GitLab. Currently GitLab's binary packages are distributed as a big rpm/deb with every package needed by GitLab (like PostgreSQL, Redis, Nginx etc.) inside it, and there are no official repositories, so one must manually download and install the Big package. Why can't we use the more traditional way with package dependencies?
I want to piggy-back off this: PLEASE all projects, continue to offer monolithic packages as an option. It takes an act of Congress to get some servers internet access to fetch packages; being able to download a VMWare image or a blob to install makes testing a whole lot easier.
That is possible, but you need to either need to mirror all gems or pick the 135 ones used by GitLab. And you need to set up a Debian package mirror as well. This might take a lot more time than the 2 minute Omnibus install :)
From these servers you can frequently access a fileserver on which you can download files from the internet. But the server itself can't access the internet.
You're welcome. We're working on an official repository by using the awesome packagecloud.io software. This will be a big package but it will be easier to update (just use apt-get). Making a small native package is pretty hard but we're open to contributions http://feedback.gitlab.com/forums/176466-general/suggestions...
Thank you for coming forward in many discussions (not only HN), and giving time for people's questions.
I resent the way things went down, such as removing people's repositories, and paying gitorious developers to shut down the project. Those are history now, and I can't say they prevents anyone (anyone paying attention, that is) from taking a different route - fortunately, both projects are freely licensed and data is in git repositories.
They raise questions about the future though: next time people's code would be also removed? Will there be at least three months then, or less?
Since it bought the gitorious.org site, it's like you have two hosting sites, and want to close one down. For freely-licensed projects, making a copy is easy (whether people use it or not) - if Gitlab wanted to.
We didn't put Gitorious to shut down the project. Gitorious was no longer sustainable.
We don't move projects because we don't want to move them to a new organization and url without explicit consent. We're working with archive.org to make sure nothing is lost.
They will have to import their repo's into GitLab. This means that all their urls will change. This is quite unfortunate but we hope they'll appreciate the improved interface and features that GitLab brings such as a great merge request flow. Please let me know if you have any specific concerns.
I'm concerned about losing access to public projects that are not actively maintained, and thus won't make the transition to GitLab. Is it possible to leave Gitorious online in read-only mode after the May deadline?
Unfortunately that is not possible because of the hosting costs for Gitorious.org. We're reaching out to archive.org to index everything but it is probably not easy to git clone from there. Feel free to create mirrors of things that are important.
We don't want to move people's code without them agreeing with that move to another organization. But I agree the broken links are not nice. I'm not sure how practical it is to redirect projects that moved themselves.
Might it be possible to at least store copies on gitlab - say, have a project/user/organisation called gitorious with every gitorious project under it?
I can't admit that I know just how much stuff is hosted on gitorious, but it might not be too onerous.
Redirects can be a lot of work if there are many and you need to find out where to redirect too.
It would be awesome if an other individual or organization is willing to sponsor the hosting costs so we could keep it open longer, if so please email me at sytse@gitlab.com or comment here.
>How about giving the domain to another entity that is willing to pick up the hosting and/or redirection costs?
GitLab bought Gitorious so they could shut it down, not so they could give it to someone else. That is the purpose of acquisitions within the same field.
The main reason for the acquisition is to give and communicate a clear upgrade path for existing Gitorious users. If someone wants to pay for the hosting costs to keep gitorious.org running longer we'd be happy to do that. Please email me at sytse@gitlab.com or comment here if you're interested.
>The main reason for the acquisition is to give and communicate a clear upgrade path for existing Gitorious users.
That's a pretty disingenuous thing to say when it seems like the only reason an "upgrade path" is needed in the first place is because of the acquisition and shutdown.
Edit: Even with Gitorious being "no longer sustainable" in its current form, there are other methods that could have been used (price adjustments, fundraising, etc) rather than an outright and very short-term shutdown.
Responding after the edit. Price adjustments and fundraising make sense when a project is alive and growing, but Gitorious had been seeing less and less contributions over the last few years.
No problem, thanks for asking. With the 1GB RAM Pi coming out running GitLab is a lot easier. It would be nice to have a precompiled Omnibus package for it (like the ones for other platforms on https://about.gitlab.com/downloads/). We hope someone will contribute this.
Thanks for raising this, we'll look into it. Some of our team just got a RPi2 in our (very delayed) christmas gifts. So we'll be trying to improve the situation. But if someone knows why precompiling fails only on Rpi's please comment in the issues.
