
Dear open-source maintainers, a letter from GitLab - levlaz
https://about.gitlab.com/2016/01/15/making-gitlab-better-for-large-open-source-projects/
======
jbk
With VideoLAN, we're not on github, but I believe we fit the 'large open
source project' description. We host VLC, FFmpeg, x264 and quite a few related
libraries.

For VLC and all related VideoLAN projects, we're moving to our own instance of
GitLab hosted on our infrastructure.

And to be honest, it's quite good, but a few stuffs are ridiculously limited,
to the point that some people in the community are resisting the change.

The first part is the groups and subgroups: it seems incredibly difficult to
give sub-groups access to repos (like a team for iOS, one for Android, one for
libVLC... but all are under the "videolan/" group). It seems there is a way
with the EE, but not in the CE; and the current idea for the CE is to have
sub-projects, which is not good, because it will make our URLs way more
complex than needed.

The second part is the bugtracker/issues tracker. We use trac for VLC, and we
want to leave it for something better; but gitlab issues is way too limited,
even when using the templates. Especially, it seems to be impossible to add
custom searchable fields (like "platforms", "priority" or "modules") which are
very very useful to do queries. Also, there is no way to do custom queries and
store them ("I want all the bugs for Windows, which are related to the
interface modules").

If I remember correctly, this second part was also a complaint in the open
letter to github.

Finally, it's not really related, since it's more a feature request, but we'd
love to allow external people to fork our repos, but not create completely new
ones (or have them validated) because we don't want to host any projects under
the sun (there is github and gitlab for that). So far, you either allow both
features or none of them.

PS: can we have custom landing pages and custom logo in the CE version? :D :D

~~~
sytse
We would love to help you to host VideoLAN on a on-premises GitLab instance.
Thanks for raising the issues you did.

1\. Our EE version has the function share project with other groups
[http://doc.gitlab.com/ee/workflow/share_projects_with_other_...](http://doc.gitlab.com/ee/workflow/share_projects_with_other_groups.html)
If this is essential for you we'll give you a free lifetime license for GitLab
EE.

2\. You can add custom labels on issues and the searches can be stored in urls
that you can bookmark and use in links. You might have considered this already
and need more functionality. Maybe it is best to discuss this in an issue so I
created [https://gitlab.com/gitlab-org/gitlab-
ce/issues/10712](https://gitlab.com/gitlab-org/gitlab-ce/issues/10712) Please
add there what you need in addition to the labels functionality. We addressed
the long list of items raised in the original Google Doc letter below the
signatures in [https://gitlab.com/gitlab-org/gitlab-
ce/issues/8938#improvem...](https://gitlab.com/gitlab-org/gitlab-
ce/issues/8938#improvements) The first item under improvements details our
reponse to that question.

3\. In GitLab you can give each user a fixed number of new projects. That
should prevent people from storing a excessive amount of repo's. But feel free
to make a feature request to limit people to only forks. As other replies have
indicated that still allows people to work around it but at least the
intention will be clear.

4\. A custom landing page and logo is an EE feature
[http://doc.gitlab.com/ee/customization/branded_login_page.ht...](http://doc.gitlab.com/ee/customization/branded_login_page.html)
We think this is more relevant for larger organizations so we're comfortable
for having it as EE only at the moment. As mentioned under 1. we're open to
offering you (and other open source projects considering self-hosting) a
lifetime EE license.

I'll be in the comments today (just woke up in SF). You and any other open
source project can always reach me at sytse@ company domain to get assistance
or claim the EE license.

~~~
sytse
Instead of offering a free EE license I think the better thing to do is to
open source features in EE that are deemed essential. So if you run a
significant open source project and are considering switching to self hosted
GitLab please let us know what EE features are blocking you (if any). This
will allow us to open source them.

~~~
scrollaway
systse, I have nothing of value to add to this topic but as usual I want to
thank you guys for the work you do. Gitlab may not be perfect but it's
heartwarming to see an awesome open source project being supported like this
and it's always really nice to see companies thrive on FOSS-first models.

------
nathan_f77
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. Then they
started charging for enterprise features and turned it into a business, which
felt even weirder. And then they raised a lot of money, which kind of made
them seem more legitimate. And now this letter, which changed my perspective
quite a lot. I didn't know that had features like voting on issues, and issue
templates.

So now it even feels like they're doing Git hosting the right way, making the
core software open source, and charging for enterprise features.

On the other hand, I would have probably never paid for GitHub if they
followed this model. So I don't think GitHub would have been as successful.

~~~
vincentkriek
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](http://gitlab.com)

~~~
georgefrick
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?

~~~
quaunaut
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.

~~~
noir_lord
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).

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

~~~
noir_lord
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.

------
mdw
I've recently made an iOS App that integrates with GitLab. The people at
GitLab have been incredible, they respond to my issues, improve the API with
every release, I didn't expect this level of awesomeness when I started the
project.

What's great about GitLab, there's a release on the 22nd of each month, so you
can depend on pretty much continual improvement. Even if you don't think
GitLab is suitable for your Open Source project, talk to the team on their
issue tracker, things get solved pretty quickly!

~~~
dordoka
Thanks for building Trident! Happy customer here. Gitlab servers work really
well and is super fast. Patiently waiting for the Github servers
functionallity to be on par with the Gitlab one :)

~~~
mdw
Appreciate this compliment :) Please open any issues you see with the App in
the issue tracker, helps me prioritise new features and candid feedback helps!

~~~
dordoka
Already opened some enhancement request on the issue tracker, thanks! Any help
you need :)

------
_yy
Meanwhile, Phabricator has implemented all of these (and even more).

Custom templates:
[https://secure.phabricator.com/book/phabricator/article/form...](https://secure.phabricator.com/book/phabricator/article/forms/)

Votes:
[https://www.mediawiki.org/wiki/Phabricator/Tokens](https://www.mediawiki.org/wiki/Phabricator/Tokens)

It's better in almost every aspect than GitLab and GitHub.

See
[https://en.wikipedia.org/wiki/Phabricator](https://en.wikipedia.org/wiki/Phabricator)
for an (incomplete) list of open source projects using it.

~~~
aaviran
As a quite disappointed user of Gitlab (due to issues raised here, e,g, CE vs
EE and the Ruby infrastructure), has anyone had experience with both? I
understand that Phabricator is a more "complete" solution, but how do they
compare in the core features that they both share?

Also, do they pride themselves for writing this in PHP? I consider this an
anti-feature, but this might be highly opinionated.

~~~
marceldegraaf
We've been using Phabricator for a few months, coming from private repos on
Github.com. We initially liked it because it "ticked all the boxes" for the
features that we needed from a source code and issue tracker. However, we ran
into major issues along the way, basically because some of the concepts in
Phabricator aren't compatible with our workflow. We decided to switch to
Github Enterprise and haven't looked back since.

Some of the issues we had with Phabricator:

1\. Phabricator is actually a suite of different applications that do specific
things (e.g. source code hosting, issue tracking, project management, ...).
Although Phabricator ticked all our feature boxes, some of the components it
ships with are very immature and/or don't get a lot of attention from the
development team.

2\. For some reason the platform as a whole feels like a CRUD layer on top of
a data model. The UI and various workflows in the applications are very
tightly coupled with the underlying data model. I guess that makes it easy to
develop and maintain the various core applications of Phabricator, but it
doesn't make for a very user-friendly or usable product.

3\. We have ~150 internal repositories, we actively work on ~40 of them at any
given time. The source code application doesn't seem intended for that many
repositories (e.g. navigating to a specific repository is non-trivial)

4\. Phabricator has a fundamentally different approach to "pull requests". It
works really nice, but only if you commit to using the Phabricator Way Of
Doing Things. However, our team has been working on Github.com for years, and
we're so used to the Github-workflow that we couldn't get used to the
Phabricator workflow.

In the end Phabricator just wasn't the right tool for us. It definitely has
some attractive properties: it's easy to install and upgrade, the command line
tools are solid and provide all functionality you need, and it performs
extremely well even on a small EC2 instance.

(EDIT: formatting)

~~~
_yy
> 1\. Phabricator is actually a suite of different applications that do
> specific things (e.g. source code hosting, issue tracking, project
> management, ...). Although Phabricator ticked all our feature boxes, some of
> the components it ships with are very immature and/or don't get a lot of
> attention from the development team.

The features which aren't explicitly marked "experimental" work very, very
well in my experience. Especially the code review part, which I find more
pleasant to use than Gerrit.

> 2\. For some reason the platform as a whole feels like a CRUD layer on top
> of a data model. The UI and various workflows in the applications are very
> tightly coupled with the underlying data model. I guess that makes it easy
> to develop and maintain the various core applications of Phabricator, but it
> doesn't make for a very user-friendly or usable product.

Have you got some examples? They're hiding the database pretty well IMO, and
we haven't had many usability complaints that weren't about minor issues. Many
of the experimental features are cumbersome to use though and we've turned off
some of them again to avoid confusion.

> 3\. We have ~150 internal repositories, we actively work on ~40 of them at
> any given time. The source code application doesn't seem intended for that
> many repositories (e.g. navigating to a specific repository is non-trivial)

Have you raised an issue about this? They're very responsive to issues
encountered in real-world use and usually decide about feature requests by
user demand. I do know that they're working on improving this - the
"callsigns" will become optional, for example.

> 4\. Phabricator has a fundamentally different approach to "pull requests".
> It works really nice, but only if you commit to using the Phabricator Way Of
> Doing Things. However, our team has been working on Github.com for years,
> and we're so used to the Github-workflow that we couldn't get used to the
> Phabricator workflow.

Their way of doing (or actually, not doing) pull requests is the most
important feature of Phabricator. Their approach scales much better than the
traditional style and is - in my opinion - the most important reason to choose
Phabricator over Github-style tools. This might not matter for small projects,
but in a company, it sure does.

Someone wrote it up quite nicely there: [http://cramer.io/2014/05/03/on-pull-
requests/](http://cramer.io/2014/05/03/on-pull-requests/)

~~~
marceldegraaf
Hi, sorry for my late reply, apparently I'm not notified of responses to
comments :-).

1\. That's true; the non-experimental parts of the suite are mature and work
really well.

2\. This was most apparent in experimental features like
Harbourmaster/Drydock, where you need a lot of clicking around to configure a
basic build setup. Granted, that didn't apply as much to the core
applications, but we didn't find those very user friendly too. The task detail
screen in Maniphest, for example, is super-cluttered with all kinds of labels,
links, and text in the main panel of that screen. Also, the fluid layout in
Maniphest makes it hard to read task descriptions/comments because lines of
text get very long.

3\. No, we didn't, because we were going to switch away to Github Enterprise
anyway. You're right about responsiveness of the team, we noticed that too,
and that's really nice.

4\. Exactly, code review is how Phabricator started and I can definitely see
merits in their approach. However, we aren't interested in changing the core
workflow of 15 engineers just because it's theoretically a better way of doing
code review. We're getting actual work done just fine with Github's PR system,
despite the flaws it has, and that was one of the main motivations to go back
to Github (Enterprise, in this case).

Like I said earlier: I think Phabricator is actually a very nice tool and I
can see how it works really well for large teams that are willing to commit to
the code review style. It just wasn't the right tool for us :-).

------
akerro
My company with ~300 developers are moving to Gitlab in the next few months.
Today our CTO/PM shared opinion about Gitlab and he was very happy we're doing
it, even better I recommended it to him :)

I'm a Gitlab users for a few years now, personally I like it much more than
Github, one of the reason is that I fear that Github contains too many
projects and gains too much control over OSS, I also dislike their CoS.

Good luck Gitlab!

~~~
reledi
> one of the reason is that I fear that Github contains too many projects and
> gains too much control over OSS

I don't understand this fear. All repositories on GitHub can be hosted
elsewhere. Moving metadata (e.g. issues, milestones, PRs, etc.) is more
difficult but mostly possible.

Disclaimer: I like that GitHub is the "central" place for OSS, it makes my
life much easier. I know how to use the product very well and it's convenient
having almost every project that interests me available there.

~~~
lewisl9029
> Moving metadata (e.g. issues, milestones, PRs, etc.) is more difficult but
> mostly possible.

I'm curious as to how people tend to go about doing this. Any recommendations?

~~~
sytse
GitLab has an importer for GitHub repo's, issues, pull requests and in 8.4
(out on Jan 22) wiki's.

------
glandium
Just for this, I'm tempted:

 _One issue that was raised several times was the ability to not create merge
commits. In GitLab you can, as an alternative to the merge commits, use fast-
forward merges or have merge requests be automatically rebased._

The main thing keeping me from actually doing it is the network effect... and
this:

 _Disadvantages

Right now GitLab.com is really slow and frequently down. This is because of
fast growth in 2015._

~~~
throwaway999888
There is already built-in support for pull request[1] and patch based
workflows in Git itself. Why do we need to wait for, and choose based on,
hosted services providing things like that? EDIT: for more clarity; using pull
requests and patches with Git itself means that it simple to rebase or
whatever, since you're just working with branches and patches directly.

Or am I missing something? Other than something like usability, perhaps...

[1] I'm not actually quite sure if there is a specific command for that
format. Though it should be easy enough to have a third party solution that
uses a format through email.

~~~
glandium
I hate that github does pull request merges with --no-ff, so what happens is
that I manually pull the PR, merge it locally, and push. Github is nice enough
to notice that the PR was merged, so its status is appropriately closed (if
that was a fast forward, I don't think it detects rebases), but that makes me
have to go out of the browser to start typing commands when I could have just
clicked a button and be done with it. Essentially, it's a smoothness problem.

------
gravypod
If GitLab plays their cards right, they can take the market from github. That,
in my book, will be good because unlike github, we can all contribute to
making GitLab better.

The only question left is if your servers are powerful enough to run gitlab.
Maybe I'll sacrifice a goat for some new server hardware and 256GB of ram.

~~~
sytse
Don't be cruel to animals. I'll ship you the 256GB of ram personally, email me
at sytse at company domain.

~~~
thewhitetulip
By the way, I don't want to troll you, but at my company we use Gitlab 6 self
hosted version and I wasn't able to do a simple git push origin master the
repo I held in my machine was barely 5MB and still remote server closed
connection HTTP 500 I solved it by increasing the POST buffer. I never had
this issue with github, maybe you can check why it was an issue with gitlab?
it might help to advance your product!

~~~
randx
Thank you for feedback. We improved git push a lot since version 6. So when
you update to recent version it should not be a problem anymore.

~~~
thewhitetulip
cool

------
thejameskyle
I'm one of the co-authors of the Dear GitHub letter. This is the type of
response I want so badly from GitHub (but wasn't expecting).

GitLab still has a ways to go in terms of performance/reliability and
polishing their product, but GitHub aught to be very nervous about them.

~~~
johnmaguire2013
Could you explain what still needs to be done? I use Gogs for personal use,
but evaluated Gitlab briefly and it seemed about as polished, if not moreso,
as Github to me.

------
rcarmo
I chose Gitlab for my former company over GitHub Enterprise because we wanted
an on-prem solution, and it worked well enough for ~200 folk. We did have to
tweak (and occasionally break) a few things, since quite a few people suffered
from NIH syndrome and wanted things done "the right way".

In general, I liked it, but it always irked me that its Ruby underpinnings
made it hard to upgrade/migrate stuff (we basically just swapped LXC
containers at one point, not sure how it was handled during the last upgrade).
If anyone ever manages to do a credible alternative that does _not_ use Ruby
in any way but keeps the overall GitHub-like workflow, a lot of operations
folks will switch _instantly_.

(Like [https://try.gogs.io/explore](https://try.gogs.io/explore), for
instance)

Also, like some commenters already pointed out, the CE edition was
ridiculously limited in some regards - we mostly skipped the bits we didn't
like and did product-level ticketing outside it (using Trac), with Gitlab
issues used only for "techie" stuff, tracking fixes, etc.

But today I'd probably just sign us all up for GitHub and be done with it, or
fire up a VM image from some marketplace - there's hardly any point in
maintaining our own infrastructure or doing a lot of customization.

~~~
sytse
I'm sorry to hear you're not satisfied with GitLab and I would love to know
more.

1\. What things did you have to tweak?

2\. Did you try our Omnibus packages for upgrades? It should be just apt-get
upgrade
[https://twitter.com/J_Salamin/status/687884326629937152](https://twitter.com/J_Salamin/status/687884326629937152)

3\. What features of EE belong in CE in your opinion?

~~~
rcarmo
1\. For starters (besides other internal stuff), we were the guys who needed
Shibboleth support. You might recall there were a few pull requests from a
colleague of mine regarding that :)

2\. No, we had to tweak the source, so I don't think the packages were useful.

3\. Static pages, hooks and merge approvals would be right at the top of my
list. Audits would be nice to have, but we figured out how to do that on our
own.

Also, issue handling needs some improvement. We just couldn't map our Trac
workflow to it - but that's a fairly longer story, and it would probably be
the same if we used GitHub.

~~~
sytse
Thanks for your reply and for contributing code.

1\. Shibboleth is now supported in the Omnibus packages
[https://gitlab.com/gitlab-org/gitlab-
ce/blob/master/doc/inte...](https://gitlab.com/gitlab-org/gitlab-
ce/blob/master/doc/integration/shibboleth.md)

2\. Hopefully you can use the packages now that the Shibboleth code is merged.

3\. GitLab Pages, git push hooks, merge request approvals and audit logs are
available in EE.

~~~
jorams
Note that point 3 was an answer to the question

> What features of EE belong in CE in your opinion?

which means rcarmo knows they're in EE, but thinks they belong in CE.

~~~
sytse
OK, thanks.

------
neumino
I've been using GitLab instead of GitHub recently for all my new projects and
honestly there's nothing worse than GitHub and a few things are better - like
having protected branches and master by default in it -, private respositories
etc.

That being said, what both GitHub and GitLab are missing is actually becoming
a "social network" or maybe more an active network. There are tons of
interesting projects that pops up every day, that I would be interested in
knowing about, contributing, but there's basically no way to learn about them.

Kudos to the GitLab team for all its work :)

~~~
benwaffle
[https://github.com/explore/subscribe](https://github.com/explore/subscribe)

------
alexbardas
Both products are really good, but Github needs to realise that they have to
be more open and listen more to their users.

There is an opportunity for Gitlab here and I'm happy that they decided to
make this announcement.

The community is the actual winner of this healthy competition.

~~~
sytse
Thanks alexbardas!

------
filleokus
It seems as the linked issue, for the "long list of suggestion", is being
spammed or something?

[https://gitlab.com/gitlab-org/gitlab-
ce/issues/8938](https://gitlab.com/gitlab-org/gitlab-ce/issues/8938)

I have never used GitLab myself, but some of the features mentioned in the
article (like a true voting system) is something I've really longed for. Might
have to reconsider trying out GitLab more.

~~~
sytse
GitLab.com is dealing with a lot of spam over the last week, but at this point
[https://gitlab.com/gitlab-org/gitlab-
ce/issues/8938](https://gitlab.com/gitlab-org/gitlab-ce/issues/8938) seems
spam free to me.

------
bitshepherd
I remember GitLab. They interviewed myself and a bunch of my colleagues to
test the salary waters here in the Bay Area and hired nobody because we were
all "overpriced", with several being underpaid for the area.

If you want the talent you need, especially in the Bay Area, you have to pay
more than what the average developer makes in Amsterdam. I want to like
GitLab, but I just can't get that bad taste out of my mouth.

~~~
sytse
We never interview people to test the salary waters, we know interviewing is
serious for you and it is serious to us too. We're very aware of the salaries
in SF (writing this from SOMA). But since we're a remote first company we can
hire for anywhere in the world and because we're open source we get a lot of
great applicants. So the bar is high and for the Bay Area it is even higher.
Feel free to email me at sytse at company domain if you want to discuss your
application.

~~~
lwhalen
So sorry I missed this thread when it was hot.

If you know you're not going to pay SF (or even US) sized salaries, why waste
everybody's time with multiple interviews then? State up front "We're only
willing to pay $80k, even if you've got the history (previous salary, measured
prior project impact, demonstrated skill in the areas we need, etc) to justify
2x or 3x that". You won't be able to pick your interviewees brains on possible
solutions, but you also won't be wasting their (and your) time.

~~~
sytse
We don't want to waste anybody's time, actually efficiency is one of our
values
[https://about.gitlab.com/handbook/#values](https://about.gitlab.com/handbook/#values).
We do pay SF and US salaries (see
[https://about.gitlab.com/team/](https://about.gitlab.com/team/) for an idea
where our team is). But as said the higher the salary the higher the bar. We
think there are exceptional people in the SF Bay area and we would like them
to work for us.

I tried to figure out a salary range for positions to prevent wasting
everybody's time. But we still very frequently go higher or lower than I
guessed based on the person's ability and their location (and cost of living).

I would like to prevent disappointing people like bitshepherd and I'm open to
suggestions.

~~~
lwhalen
My suggestion would be to be completely up front in what you're willing to
pay, even going so far as to add it to the job description. If that means you
have salary 'bands' dependent on what region of the US an applicant is from,
put 'em up.

Ninja-edit: also, if the money just isn't there, consider taking on someone on
a part-time basis. $80k/yr is terrible FT wages for the senior-level folks
you're looking for, but if you say "We'll pay you $80k, and you just clock in
M-W 9-5 (or M-F 9-1, however the math makes sense for you to divvy up a
20-hour week)" I think you'll see an uptick in interested, qualified
applicants. Yes, it's a compromise (just like asking a senior-level anything
to show up for $80k) but at least you'll get the senior-level brainpower on
the team and still be within your budget.

Ninja-edit x2: Looking at the 'Team' page, I'm not getting a good sense of
where your devops/engineering talent hails from. The folks who appear the most
USian are the guy who lives 'on a farm', another who 'attends SFO Giants
games', a third who 'enjoys the slopes in the Sierra Nevadas', etc. Everyone
else's location is either unmentioned, or they seem to hail from Brazil, the
UK, Greece, etc. The interactive map at the top seems to be mapping the
accounts of suits and c-levels, but very few devops/engineers.

~~~
sytse
Thanks for looking into this and your suggestions.

I think the salary bands per region is an interesting idea. If we would have
these today we would put them up.

In some functions (for example finance) we have part-time team members. But in
a fast growing startup it makes sense to have many full-time people to reduce
(communication) overhead. We are prepared to pay up where that is needed. We
do allow flexible workdays for everyone. And based on ability and
responsibility we also consider 4 day workweeks.

The map at the top is something we invite all our team members to join.
Currently we don't have any engineers living in SF/NYC. We do have other team
members in sales, finance and marketing living in SF and NYC. I do expect us
to higher one or two engineers in SF in the coming months.

------
lowpro
Great PR move by gitlab, and I don't mean that negatively. This kind of direct
response is exactly what a company looking to improve should do, hats off to
gitlab!

Once their performance increases, maybe we'll see the momentum shift from
Github.

------
sandGorgon
Please improve your mobile UI - phones have lesser horizontal space than
vertical. You have put a cool looking sidebar on the left side which takes up
a lot of space causing text layout to be funny on my 5.2 inch LG G2.

Github OTOH has an extremely usable mobile UI.

~~~
sytse
You should be able to collapse the left sidebar. But we are the mobile UI has
deteriorated in the last few releases and we plan to look into it in the
coming months. If you want to get paid to contribute, we're hiring front-end
engineers [https://about.gitlab.com/jobs/](https://about.gitlab.com/jobs/)

~~~
sandGorgon
Thanks for that offer. Already have my hands full. Look for me on Bookface ;)

~~~
sytse
Sorry, I missed that you're YC too :)

------
chris_wot
GitHub probably want to, you know, actually pay attention to their developers
now. Gitlab might just eat their lunch.

~~~
mahouse
Actually, that will not happen.

~~~
J_Darnley
What? Listening to the developers?

~~~
mahouse
A migration to Gitlab. GitHub would have to start fucking the developers asses
in a serious and violent way for them to move to another place, the same way
that the SourceForge -> GitHub move was done.

~~~
pekk
Maybe you didn't notice, but this already happened for some projects.

~~~
digitalsushi
I'm curious enough to ask for an example please.

------
onuras
Their issue tracker seems really busy atm:
[https://i.imgur.com/Iv46xnx.png](https://i.imgur.com/Iv46xnx.png)

~~~
nearlythere
Gr... yeah, spammers gonna spam. We're fighting it. Here you can find out more
[https://gitlab.com/gitlab-org/gitlab-
ce/issues/5573](https://gitlab.com/gitlab-org/gitlab-ce/issues/5573)

~~~
nearlythere
FYI - Users of GitLab can report spam. Click the (!) button on the offending
user's profile. This triggers moderation.

Screenshot -
[https://twitter.com/gitlab/status/688103614556995584](https://twitter.com/gitlab/status/688103614556995584)

------
danielsamuels
Perhaps if they had the same uptime, page load speed and UX as Github, I would
consider it. Unfortunately we tried it for a week at work and none of us could
figure out our way around it (when it was working).

~~~
sytse
I'm sorry that GitLab.com was unavailable an slow. As mentioned on
[https://about.gitlab.com/gitlab-com/](https://about.gitlab.com/gitlab-com/)
we're working on that. Have you considered self-hosting it?

------
cyphar
While I've always admired GitLab being a free software alternative to GitHub,
the whole EE licensing stuff really rubs me the wrong way. EE is completely
proprietary software, even for people who have paid for it (it only allows the
freedom to modify the code, but you cannot run it as you wish or distribute
code freely). I understand charging money for your software, but you can also
charge for feature requests and support. There's no need to lock away features
from people using your free software just because you've deemed that feature
"not useful for you" or "pay-to-use".

What I _really_ don't get is the argument that "we won't liberate feature XYZ
from EE because it's only useful for companies with 100+ developers". I think
it's quite impressive that you can know what every user of your free software
needs, and that you'll protect them from code only suited for enterprise.

I'll still use GitLab (the fact there's a free software version is great), and
I'll be the first to fork (or back someone else's fork) CE as soon as you get
acquired and your free software is no longer maintained by you (see: Oracle
with Solaris, and every other acquahire ever).

~~~
sytse
What do you mean with 'cannot run it as you wish'?

Regarding choosing features for EE, I recently updated the text on
[https://about.gitlab.com/about/#stewardship](https://about.gitlab.com/about/#stewardship)
to read "is this feature much more relevant for organizations that have more
than 100 developers?". Obviously every features is relevant to smaller
organizations too. We make a guess and if we find out we guessed wrong we'll
open source the feature, as happened today in this article
[https://gitlab.com/gitlab-org/gitlab-
ce/issues/11489](https://gitlab.com/gitlab-org/gitlab-ce/issues/11489)

We think it is great that people have the freedom to fork CE. We open sourced
our release tools [https://gitlab.com/gitlab-org/release-
tools](https://gitlab.com/gitlab-org/release-tools) and the Omnibus Packaging
[https://gitlab.com/gitlab-org/omnibus-gitlab/](https://gitlab.com/gitlab-
org/omnibus-gitlab/) to ensure that people can easily generate and alternative
distribution.

------
nevi-me
At least with Gitlab I can open an issue somewhere and follow it, like with
open source projects. It doesn't disappear into the abyss with no feedback on
what's happening.

I've implemented two self-hosted Gitlab instances at work, for one of the
instances on our private network, I'm still fighting with IT to allow us to
use LDAP. Gitlab EE is still off our 'pockets' as management aren't too keen
to pay for it, at least yet, but I hope that we'll get there.

Our self-hosted instance is also a bit slow, not as slow as Gitlab.com, and if
it was written in a language that I'm familiar with, perhaps I and some of my
team could contribute to 'making it faster'. Pity I don't have enough time
left in the day to learn Ruby. I've read up a bit on the work going on around
Unicorn and workers, but maybe some of these things could be better written in
other more 'performant' languages?

For personal projects I still use Bitbucket + JIRA. I got to the point where I
decided to stop looking for freebies and pay. JIRA has been awesome, totally
worth the price.

------
Ellahn
Congratulations on GitLab, I personally use it and love it, and it's awesome
to see amazing people like the VLC team considering GitLab.

A suggestion I have is to consider open-sourcing and re-branding EE on a GPL-
Like license that also requires projects hosted with it to be open sourced,
while specifying that contributions to this version can be re-licensed by
GitLab to be used by paying customers (Or re-licensed to MIT and released on
CE). This way open source people get it all, and if you want to use it on
closed source you pay GitLab.

This also has the benefit of allowing open source developers to work with GPL,
and the changing to MIT could even be decided before merging (Sending to
either CE on MIT or EE on GPL+GitLabProprietary, according to developer
decision).

There's a lot to fix on the OpenSource world, but there are also so many
possible ways. Best of luck to the GitLab team, I hope we see more amazing
stuff from you (Btw, GitLab CI got a lot better recently, I hope you keep
improving it. :D)

~~~
sytse
Thanks for the kind words Ellahn. You suggestion is interesting. I'm afraid
that releasing EE under a GPL-like license that prevents private projects is
confusing. It would be GPL-like instead of GPL. I think that such a license
muddles the waters and would not be in the best interest of open source. I
presume that people want to be free to do as they please with the software,
not be restricted to how they use it.

------
allan_s
For me the big things missing (not only for big open source projects)

    
    
      1. more than one level of subdivision for groups/projects (see below)
      2. groups of users (call it department/team): because of 1 we have a lot of groups, (because all the small libs are in separate projects, so the project itself is a group, but of course we have several projects), so everytime somebody join the company, we have to add him in every single project (for them to be able to read the code),  and we have also subcontractors, we would like to have a nice way to separate from the others
    

I think this things are most "day to day annoying", other than that gitlab is
pretty good, the CI system, the hook system, it's pretty easy to put that
links to issue section, ticket reference redirect to redmine , taiga , jira or
whatever.

~~~
sytse
Regarding:

1\. Nested groups should solve that in the future [https://gitlab.com/gitlab-
org/gitlab-ce/issues/2772](https://gitlab.com/gitlab-org/gitlab-
ce/issues/2772)

2\. We're thinking about that but for now the invite other group feature in EE
will have to do.

------
k__
I read that Babel uses Phabricator.

How does GitLab compare to Phabricator?

------
georgefrick
I've been using GitLab myself and suggesting it to any clients with the proper
infrastructure. When I found GitLab I tried it out, and finally ended up
moving my SVN to Git (private projects). It's a great piece of software and I
love the web hooks.

~~~
jobvandervoort
That's great to hear. Any way we can improve web hooks for you?

~~~
georgefrick
Arguments from the project/push add to url would be great! A page outlining
why you are better than gitblit would help with clients :-) (who are all
possible future EE users)

~~~
jobvandervoort
Thanks! I created an issue here [0], I'd love it if you could clarify it a bit
there.

I think we can do better in our comparisons with competitors. I created an
issue [1]. I haven't heard someone asking before about a comparison with
Gitblit. Please feel free to email me at job at companyname dotcom if you'd
like me to discuss it with your clients.

[0]: [https://gitlab.com/gitlab-org/gitlab-
ce/issues/10860](https://gitlab.com/gitlab-org/gitlab-ce/issues/10860)

[1]: [https://gitlab.com/gitlab-com/www-gitlab-
com/issues/514](https://gitlab.com/gitlab-com/www-gitlab-com/issues/514)

------
infocollector
Any chance you can support Mercurial? There was a highly voted issue that I
saw sometime back.

~~~
sytse
We'll not support Mercurial, this would be an additional layer of indirection
and limit us to features that are supported in both Git and Mercurial.

~~~
infocollector
Maybe just support hg-git? All someone has to do is write some tests for
Gitlab, and then you are all set?

~~~
bronson
hg-git already works with gitlab, doesn't it?

~~~
infocollector
I was having problems even cloning using hg-git + ssh.

------
spudfkc
I get why GitLab wrote this, but it seems like just a stab at GitHub.

There seems to be a lot of hating on GitHub here, but I personally love GitHub
(and we use GitLab at my current employer).

I think GitLab is doing a great thing, and I appreciate that their community
edition is free and open source, but GitHub has been able to provide an
invaluable service. They have a great community that facilitates open source
projects and a vastly better UI than GitLab (though that isn't saying much
with how awful GitLab's UI is).

I'm eager to see how GitHub evolves in the future with GitLab as a competitor,
as GitLab has a lot of nice features (built-in CI, etc).

~~~
s986s
It is a stab and tbh Im glad they took the opportunity. There are few times
when a product can be marketed to such effect for as little cost. What they
did was show everyone how awesome they are and how stagnent Github is. Github
can easily change but most of their decision making is done behind the scenes.

Github grew popular because it was popular. Maybe thats worth something but
long term they must adapt just like Gitlab

------
pmilot
This attempt by the Gitlab folks to ride the Github dissatisfaction wave seems
a little low-brow. Why respond to a letter that's not addressed to you? I
would have preferred them to simply post an honest "Why you should migrate
from Github to Gitlab" article. The tone just seems a little devious to me.

By the way, we're using self-hosted Gitlab at work and we love it. This isn't
a knock against the actual product. In fact, I think Gitlab has improved
tremendously in the last 18 months. I just wish they would be a little more
up-front about their marketing efforts.

~~~
Jedd

      > This attempt by the Gitlab folks to ride the Github dissatisfaction
      > wave seems a little low-brow.
    

There's a github dissatisfaction wave?

Anyway, opening sentence of gitlab's open letter: "The letter of GitHub’s open
source community is clearly not addressed to us, but we’re thinking a lot
about the issues that were mentioned in it."

Does that cover your concerns?

I think if github was the free software entity, and gitlab had no free
software edition available, then the tone would be, as you suggest, totally
inappropriate. However given the arrangement is the other way around, it seems
quite reasonable they would hop onto this issue at this time, especially given
the very clear caveat quoted above.

~~~
pmilot
"Wave" might be too strong a word, but I've seen three or four posts on HN in
the last few days that were pretty critical of Github's closed source nature
and insufficient transparency.

I'm not sure why offering a free software edition somehow gives you a pass.
Both Github and Gitlab are commercial entities as far as I know.

Anyway, my concern wasn't a big deal, I was just a bit taken aback at the
opportunism. In retrospect, I think my reaction was a bit overblown.

~~~
Jedd
Fair enough. I feel like there's been stories / sentiment along this line for
a while, though apart from Microsoft's ChakraCore announcement last week (?),
the only two specific stories I recall from last year were about github's
valuation (US$2B) and when they threatened to remove someone's repository
because it contained the string 'retard'.

You're right that both github and gitlab are commercial endeavours - obviously
very much in the same space - so I'd expect them _both_ to pop up in any
discussion about bug & feature trackers, community involvement, etc -
especially if there's the potential to improve their business.

On the other side of the coin, I'm curious why Github seems to often get a
pass by the free software community.

------
nik736
Off topic:
[https://jumpshare.com/v/MOEwe43eAHatINgDTi0z](https://jumpshare.com/v/MOEwe43eAHatINgDTi0z)
What does this stand for? ;-)

~~~
nearlythere
wm in wm_web refers to "wordmark" \- looks like it's not displaying correctly
in your browser! which one?

~~~
nik736
Safari 9

~~~
nearlythere
Thanks! That's helpful. I posted a bug report [https://gitlab.com/gitlab-
com/www-gitlab-com/issues/513](https://gitlab.com/gitlab-com/www-gitlab-
com/issues/513)

------
grimborg
Using gitlab for go development, "go get" doesn't work. Googled around,
couldn't find a solution. With github, on the other hand, it just works.

I love gitlab (even made a git tool to easily create repositories from the
commandline, gitgitlab) but these small things make a real difference. I'll
end up paying for a github organization account just to get this annoyance out
of the way.

~~~
sytse
This should work, see
[https://github.com/gitlabhq/gitlabhq/pull/5958](https://github.com/gitlabhq/gitlabhq/pull/5958)

Please open an issue with what you tried exactly.

------
MoSal
Somebody just spammed their Issues page[1]. The one they link to in the
letter.

I think the spammer is trying to make a point! For starters, there seems to be
no rate limit applied.

[1] [https://gitlab.com/gitlab-org/gitlab-
ce/issues](https://gitlab.com/gitlab-org/gitlab-ce/issues)

~~~
sytse
GitLab has rate limiting on the API
[http://doc.gitlab.com/ce/security/rack_attack.html](http://doc.gitlab.com/ce/security/rack_attack.html)
but by default we set it pretty high.

~~~
sytse
We added recaptcha a week ago and will merge akismet and RBL support this week
to reduce spam.

------
merb
What I would like to have in the free version is: \- Project importing from
Stash to GitLab \- Mirror Projects \- Display merge request status for builds
on Jenkins CI \- Rebase merge requests before merge \- Git hooks (commit
message must mention an issue, no tag deletion, etc.)

These are pretty essential.

~~~
sytse
Thanks for voicing your wish.

1\. Project importing from Stash makes sense, we already have it for
BitBucket.com, any reason why you want Stash instead of using any repo by URL?

2\. Mirroring sounds like a good one to open source. Feel free to make an
issue.

3\. There is a open source Jenkins plugin [https://wiki.jenkins-
ci.org/display/JENKINS/GitLab+Plugin](https://wiki.jenkins-
ci.org/display/JENKINS/GitLab+Plugin) that uses our new build status API, so I
think this is doable already in CE.

4\. If you want to use rebase before merge and git hooks can I ask how large
your organization is?

~~~
merb
1\. Currently It's hard to migrate a whole Stash Server / Bitbucket Server.
2\. Thanks 3\. Oh, ok we already use a thing like that for Stash 4\. Currently
we are 5 people, but we use Git Hooks extensively and used a rebase workflow
before we used a Stash Server. Also we only use a special style of commits
that go into our global git server, people should take time to write their
commit message.

> yearly per user purchased in packs of 10 $390 per pack

Remove the Pack and we are happy. Paying monthly would help also we try to
grow, but sometimes we need to shrink (if people don't fit) we move really
slowly when it comes to people, we had some issue's at the beginning, so we
learned from that the hard way.

------
p1mrx
GitLab could differentiate their service by offering IPv6 support, which
GitHub has so far declined to do.

~~~
sytse
Cool, I created an issue [https://gitlab.com/gitlab-
com/operations/issues/43](https://gitlab.com/gitlab-com/operations/issues/43)

~~~
p1mrx
Thanks, subscribed. When Google Code shut down, I migrated the IPvFoo[1]
source code to GitHub, but it felt dirty using an IPv4-only service for that
purpose; I'll probably move again to GitLab if they follow through.

[1] [https://github.com/pmarks-net/ipvfoo](https://github.com/pmarks-
net/ipvfoo)

~~~
sytse
We will, Ian is already working on it.

------
sqldba
Because the thread has turned into a "why I like/dislike GitLab over GitHub",
I'll say one thing that keeps sending me back to GitHub is the neat-o desktop
client.

I use a command line for everything else in life; but with Git I'm hopeless.

~~~
jazoom
The GutHub GUI (GutHub Desktop) is pretty bad. Try GitKraken or Sourcetree.
You can even use GitHub Desktop with Gitlab if you really want.

~~~
mdk754
I currently do this for the basics, and drop down to git at the shell for
anything more complex than the one or two things GitHub's client does well.
It's a decent trade off in my opinion.

------
simi_
Sourcegraph has pivoted into a git hosting appliance, it's pretty cool, even
if nowhere near as full-featured.
[https://sourcegraph.com/](https://sourcegraph.com/)

------
jorisw
Before you think of switching to GitLab, look at their status Twitter account
over the past few months. They've had a lot of down times. They run on
Microsoft Azure.

~~~
shocks
> They run on Microsoft Azure.

What does this have to do with anything? Are you suggesting that service run
on Microsoft Azure are not stable?

~~~
dingo_bat
Most people associate a lack of reliability with anything Microsoft-related.
Although I do not think that is the cause of Gitlab's problems.

~~~
castell
Reading their Twitter status messages. Microsoft sponsored Azure for Gitlab.
Between Oct and Dec they were on Azure, and they had major issues with the
Azure platform, pretty unreliable for their use case. Gitlab switched to IBM
Softlayer because of that experience. Read yourself:
[https://twitter.com/gitlabstatus](https://twitter.com/gitlabstatus) and
[https://gitlab.com/gitlab-
com/operations/issues/17](https://gitlab.com/gitlab-com/operations/issues/17)

~~~
sytse
Although we planned to switch to Softlayer we're still on Azure. It has given
us a hard time, but in the last few weeks things have gotten more stable. Our
availability is better (fingers crossed) but our speed is still unacceptably
slow [https://gitlab.com/gitlab-
com/operations/issues/42](https://gitlab.com/gitlab-com/operations/issues/42)

~~~
harel
From first hand experience, Softlayer has been nothing but fantastic to us
over the last few years, and cost effective.

~~~
sytse
Thanks, so far we're really happy about Softlayer.

------
nhumrich
I love gitlab and its features, and will commit to actually using it once
dockerhub has gitlab integration. I agree though that is more of a limitation
on dockerhub.

------
jhasse
Has anyone any experience with Gogs? How does it compare to GitLab?

[https://gogs.io/](https://gogs.io/)

------
giancarlostoro
Thank you GitLab for being yet another option, and for at least maintaining
one Open Source version of your software at the very least.

~~~
sytse
You're very welcome!

------
caiowilsonb
I love that this thread main comments have become a sale negotiation. lol

------
Entalpi
ll

------
imonabout
I don't think the fact that GitLab is free for basic users is very
discoverable from the site. You've got the "features" tab, which leads to what
seems to be the option of downloading a community edition, which makes it look
like GitLab is only offering the code itself but not hosting from their, and
the enterprise edition for some licensing fee (I suppose). Then you've got
"sign in", but no "sign up", which leads me to ask "but then how do I sign
up", which most naturally (for me) leads me to the "pricing" tab. Now this
page only shows "trial" and the different priced tiers.

But if I press "sign in", I am able to sign up, with no notice about it being
just a limited (45 day) trial. So so far I'm assuming that this is a
perpetually free account, though I'm not completely sure yet...

~~~
dingo_bat
Visiting www.gitlab.com redirects me to
[https://about.gitlab.com/](https://about.gitlab.com/). There are three big
options:

1\. Community edition 2\. Enterprise edition 3\. On our server

The 3rd option has this text: Free hosting for private repos? Sign up to get
unlimited repos and collaborators.

Clicking on Sign up takes me to
[https://gitlab.com/users/sign_in](https://gitlab.com/users/sign_in) which has
clear options to sign in or sign up. It also has the text: GitLab.com offers
free unlimited (private) repositories and unlimited collaborators, please sign
up or in on the right.

In lesser words, it seems pretty clear-cut to me. They offer unlimited free
hosting for your repos. I did not see any trial period anywhere. Maybe you
went to the Enterprise option?

~~~
imonabout
I'm sorry.

------
beshrkayali
Nice ride, Gitlab!

------
bigbugbag
The "crippled community edition vs paid enterprise edition" business model
raises red flags. It's not that different from the free crippled demo version
or outdated by 2+ major versions freeware model.

Who gets to decide that features are enterprise only ? How are these
enterprise only features: "Hosting static pages straight from GitLab", "git-
annex", "git hooks", etc. ?

Get a crippled version that doesn't fit the reasonable expectations or pay for
enterprise edition coming with a big bag of features I have no use for just to
get the missing features that I can have on github for free (And I'm not a big
fan of github)?

As such gitlab community is not very useful to me and does not seem to have a
future because its chosen business model goes against its usefulness to
people.

~~~
DouweM
GitLab CE is not crippled in any way, it is used every single day by hundreds
of thousands of companies and millions upon millions of developers. It is and
has always been our (GitLab, the company) main focus, we only decide to make
new features EE-only when we think that they are mostly interesting to
companies with 100+ employees. Besides the company's efforts, contributions
from the 1000+ community contributors always go into CE, unless the
contributor submits it to the EE repository specifically.

As evidence, just look at our Direction page:
[https://about.gitlab.com/direction/](https://about.gitlab.com/direction/), or
compare the CE and EE changelogs: [https://gitlab.com/gitlab-org/gitlab-
ce/blob/master/CHANGELO...](https://gitlab.com/gitlab-org/gitlab-
ce/blob/master/CHANGELOG) vs [https://gitlab.com/gitlab-org/gitlab-
ee/blob/master/CHANGELO...](https://gitlab.com/gitlab-org/gitlab-
ee/blob/master/CHANGELOG-EE).

Note that our free, hosted GitLab.com runs EE, which means that EE features
like GitLab Pages ("Hosting static pages straight from GitLab") are available
to everyone.

~~~
drewcrawford
Just yesterday I ended up implementing my own mirroring of GitHub
repositories. GitLab supports this in EE (new in 8.3), but not CE.

That's not a feature that only large enterprises use–I run an open source
GitHub organization and wanted to use GitLab as CI. It works! But I needed to
reimplement an EE feature to do it.

To be clear, I don't think there is anything sinister about keeping features
behind a paid firewall. That is how software developers have paid their rent
for decades. I'm just saying that the EE features are _not_ all "mostly
interesting to companies with 100+ employees." Several of them are things I
needed as a single open-source developer.

I've debated about buying EE to fill in the gaps, but you sell licenses in
packs of 10, and I only need 2 :-)

~~~
DouweM
> I run an open source GitHub organization and wanted to use GitLab as CI. It
> works! But I needed to reimplement an EE feature to do it.

Is there a reason why you didn't use GitLab.com, which runs EE and thus has
Repository Mirroring?

> I'm just saying that the EE features are not all "mostly interesting to
> companies with 100+ employees." Several of them are things I needed as a
> single open-source developer.

Fair enough, I'm not saying our judgment of what is and what isn't interesting
to smaller/single-person teams is perfect. If the general feedback of the
community is that a certain piece of functionality belongs in CE rather than
EE, we will consider bringing it to CE. We have done this in the past.

~~~
drewcrawford
> Is there a reason why you didn't use GitLab.com, which runs EE and thus has
> Repository Mirroring?

1\. My hosting is way more reliable than yours :-)

2\. I need to host the CI runners myself anyway, because you don't have the
right config

3\. I already have a private GitLab install, so it's no extra trouble

4\. My repository mirroring is quite a lot better than yours, as it's instant,
not hourly

5\. I prefer to have a commercial relationship with important tools. You seem
like nice people, let's see what happens when you get acquired. As long as you
can't be bothered to sell to 2-person teams, I'll just run CE and have my
commercial relationship with AWS instead.

~~~
DouweM
> 1\. My hosting is way more reliable than yours :-)

You've got me there :) I'm sure your aware of our intention to greatly improve
GitLab.com reliability and performance in Q1 2016: [https://gitlab.com/gitlab-
com/operations/issues](https://gitlab.com/gitlab-com/operations/issues)

> 4\. My repository mirroring is quite a lot better than yours, as it's
> instant, not hourly

Heh, care to share? :) Maybe we can take some pointers from your
implementation. How does your repository mirroring know that the upstream repo
was updated? Do you use webhooks on GitHub? That would actually be pretty easy
to implement, an `update_mirror` GitLab API endpoint that GitHub could call
to, hmm...

> 5\. I prefer to have a commercial relationship with important tools. You
> seem like nice people, let's see what happens when you get acquired.

What are you afraid of?

> As long as you can't be bothered to sell to 2-person teams, I'll just run CE
> and have my commercial relationship with AWS instead.

Fair enough!

~~~
drewcrawford
> Do you use webhooks on GitHub? That would actually be pretty easy to
> implement,

Bingo. Full implementation, in Bash:
[http://faq.sealedabstract.com/gitlab_mirror/](http://faq.sealedabstract.com/gitlab_mirror/)

> What are you afraid of?

Mostly, that you'll get bought by the likes of Oracle. In spite of my quibbles
about CE features, I think you're doing a (mostly) fine job of CE right now.
But your acquirer will see CE as a cost center (there's no revenue) and will
want to "streamline" by focusing on enterprise (where your balance sheet is).
GitLab.com will also look like a cost center, and will either shut down, turn
into a datamining opportunity, or go through the bad PR of no longer being
free. I fully anticipate, in 5-10 years time, that I will be running a CE fork
to get out from under your acquirer, just like StarOffice, MySQL, Hudson, etc.

Contrast with GitHub, who makes a silly amount of money from people like me.
Their acquirer would be mad to screw up a winning formula.

The good news is, GitLab is such a good product that I still hugely prefer it
even after "pricing in" the risk (cough, _certainty_ ) that my days are
numbered. It is an amazing tool, it really shows that you care about it. For
now.

~~~
DouweM
All right, I see where you're coming from. I think any eventual GitLab
acquirer would be mad to screw up _our_ winning open core formula, but I'm not
in a position to tell the future or make any promises.

I've asked our CEO Sid (you know, the "GitLab CEO here" guy) to chime in.

~~~
drewcrawford
> I think any eventual GitLab acquirer would be mad to screw up _our_ winning
> open core formula

Understand, I _want_ to believe. I _want_ to live in a world where open core
works at VC scale and over long timeframes. I'd love to run all my own
projects that way, if it was possible. And who knows, maybe you will be the
people to do it where everybody else failed.

It's just the available evidence suggests I don't live in that world. In my
world, you have to pay money for things if you want them to last. I'd like to
pay you money, but you don't want it, and that's weird.

Look at it from my POV. GitLab isn't "just" another tool for me, it's my
homepage. I'm in there hours every day. I trust it to store my life's work.
That's amazing! People literally kill to get that deeply embedded into their
customers lives. But it's also a huge responsibility. You and I are in the
honeymoon period right now, but when times get tough and we have 3 kids and a
mortgage, it's going to get real.

You may not be in a position to speculate that far out, but I _have_ to. I'm
still going to need this product in five years. You might not need me.

------
arihant
> _" Right now GitLab.com is really slow and frequently down. This is because
> of fast growth in 2015. We are working to improve it in the first quarter in
> 2016. For now please consider downloading GitLab and using it on-premise for
> a fast experience."_

Is this a joke? I mean for people looking for free private Git hosting, there
is Bitbucket. This statement is like saying "free, but not really, really."
The fact is if I want hosted Git hosting from Gitlab, I cannot reliably get it
without paying at least $390 upfront for their EE plan. Too much smokescreen,
too less actually on offer.

~~~
levlaz
Have you tried using BitBucket?

~~~
pmontra
I did. Some customers of mine use it (free tier if possible) for their private
projects. My assesment:

* issue management is better than GitHub's one but for very simple needs (90% of the repositories?) GitHub is enough and BitBucket is needlessly complicated (don't even talk about Jira).

* repository navigation is worse (finding the repositories themselves can be difficult if you land on the wrong page)

* wiki/pages are probably the same

* access control and general management is better

* pull request... I don't know. Our teams are small and normal communication plus git merge are enough.

