Dear open-source maintainers, a letter from GitLab
about.gitlab.com
about.gitlab.com
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
1. Our EE version has the function share project with other groups http://doc.gitlab.com/ee/workflow/share_projects_with_other_... 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 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... 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... 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.
The whole idea of VideoLAN infrastructure migration from gitweb/trac/etc to gitlab and not to github was to use and promote free and open-source software.
Using closed-source software there is out of question, really.
[1] I.e. a licensing model based on GPL and selling services that Red Hat uses for RHEL, instead of a licensing model like they, and a minority of the "open source" companies, use.
"This software and associated documentation files (the "Software") may only be used if you (and any entity that you represent) have agreed to, and are in compliance with, the GitLab Subscription Terms of Service, available at https://about.gitlab.com/terms/#subscription (the “EE Terms”), and otherwise have a valid GitLab Enterprise Edition subscription for the correct number of user seats."
1. Thanks, but see above :)
2. As I said, custom labels are way too limited, as people on the open-letter-to-github said, so I will comment on the issue.
3. Will do.
4. same as 1 :) But thanks a lot.
I will contact you :)
So thanks for the offer, but no thanks.
While I get the sentiment, I don't think this helps. If you want to help the Open Source community, give us what we need in the form of open source. If I don't care about vendor lock-in I can go ahead and use GitHub. GitLab counts because its open source, and its open source version is the only thing the open source community should care about.
I have seen the feature of being able to customize the login screen come up in discussions about gitlab come up so many times, in so many places, and I usually see it met with "EE feature" or a community member saying something like "gitlab is open source just change the files on your server".
This seems like such a basic thing for an open source software like gitlab to just provide out of the box, i can't believe it isn't listed under your " ... an EE feature that is would come up frequently in these conversations ... " that you "would not hesitate to open source". Especially since at least several of the people you're replying to in this thread have mentioned it specifically.
Is gitlab really making enough income from enterprises who decide that this is the killer feature that they need to pay for EE to get?
It seems like a simple matter of moving the gitlab branding on the login page to the footer with a "powered by gitlab" type of thing and a logo.
Please don't take my meaning as a hateful rant, I love gitlab and personally manage 2 seperate deployments of gitlab CE, but i am not ashamed of saying that this is something of a frusteration to me, and I have a hard time taking this
>If there is an EE feature that is would come up frequently in these conversations we would not hesitate to open source it
statement seriously in light of how many times I have seen this seemingly harmless feature shot down for essentially no real reason.
I've made https://gitlab.com/gitlab-org/gitlab-ce/issues/11489 to discuss.
On a technical level that seems an impossible distinction to make. Someone wanting to host a new project could just fork yours, then make a a commit that deletes everything currently in there, then start their new project.
Having a fork that delete everything and start a new projet is easy to detect and label as spam. (there will always be abuses, but it's okay as long as you can mitigate/moderate)
We're planning to add cross-server merge requests in the future, which would make it that you don't have to host the forks yourself [0].
Sure, but at least it would be clear what is 'allowed'.
redmine, gitlab, bitbucket, github are what I am using for various things.
I wonder if this could be solved by making it really easy to fork your repos, but when that happens the fork ends up (with tight integration) back on the/a public GitLab instance.
Isn't this use-case covered by Gitlab's issue labels?
http://trac.edgewall.org/wiki/TracReports
http://trac.edgewall.org/wiki/TracQuery
http://trac.edgewall.org/ticket/1735
Add in:
http://trac.edgewall.org/wiki/TracTicketsCustomFields
And there's a lot of things available before adding custom plugins.
I'd be interested to hear what limits vlc hit in trac (and why they'd rather move than improve trac. Nothing wrong with that - but I confess I have a soft spot for trac and the team's ethos of "try it as a plugin before making it a core feature").
Also curious if anyone know what, if anything happened with the Apache Bloodhound fork/distribution?
I always hoped it held the promise of being a simple to install, opinionated trac for multiple (lean?) projects. But as far as I can tell it was pretty much abandoned.
While part of it might be rails-angst and fear of precious stones - I always felt gitlab was a bit of a heavy hammer in terms of install/dependencies/cloc for "just" project management.
In practice the bundled distribution alleviates that - but I still feel taking the "best of trac" and writing a new system a little more opinionated (and probably with a clearer data model) would be worthwhile. Just another project on the todo-heap :)
We want for every bug, that a few custom fields are always defined, to do a partition of the bugs, and to be able to query on those. Moreover, to change the priority or the platform, it's quite complex to do and will break often. Many bugs won't have it filled, for example. Labels do not guarantee that consistency.
As you can see, it's already what people want in the github open letter.
Maybe having some set of mandatory labels? I.e. at least one label from platform list, at least one label from priority list, etc...
type-label
Types:
b - bug
f - feature
p - priority
t - team
Once there is a method to the madness, it's not bad, and it's more flexible on Gitlab's part I'm sure, to have people tag instead of supporting custom drop-down attributes.
If you have Java
just type download gitbucket.war
> java -jar gitbucket.war
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.
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
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.
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).
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.
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.
Maintaining the 10x SaaS services you use in a similar vein suddenly starts eating up close to whole days.
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.
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.
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)
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 seems just about everything is being re-written in Go these days...
You could have said that without cheapening the level of discourse.
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
https://confluence.atlassian.com/bitbucket/enable-an-issue-t...
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.
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...
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!
Custom templates: https://secure.phabricator.com/book/phabricator/article/form...
Votes: 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 for an (incomplete) list of open source projects using it.
Also, do they pride themselves for writing this in PHP? I consider this an anti-feature, but this might be highly opinionated.
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)
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/
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 :-).
I'd prefer it to be written in something else, too, but - the Phacility team are ex-Facebook developers. If anyone knows how to use PHP, it's them. They built their own, extensive web application framework on top of it (which is a remarkable achievement for itself). Phabricator is one of those rare examples that you can, in fact, write excellent code in PHP.
On top of that, they're running a bug bounty with generous payouts: https://hackerone.com/phabricator
Really the place that PHP is lacking is on the tooling/ops side of the projects built on top of it. A lot of what I have to work with still seems to be 15 years old. That said, it's getting better and other peoples' preferred tools have their share of problems as well.
Like what?
Management panels of hosting companies.
UltraDNS's website.
Salesforce.
I think GitHub is prettier, but having tasks separate from repos and having tasks be as sophisticated as they are in Phabricator and having such a better pull requests system, it doesn't matter? GitHub has to dumb down the user interface on their product to appeal to the least common denominator and maintain their growth. Phabricator is for projects where people care enough about their projects to learn the UI so they can get things done.
> Also, do they pride themselves for writing this in PHP?
As a user I doubt you're going to find your self caring about how it's written.
Not everyone can afford to be completely blase about their source control system going down or getting defaced.
Gitlab had its fair share of vulnerabilities, too, despite being written in Ruby. It's about the developers, not the language.
Have a look at their bug bounty program: https://hackerone.com/phabricator
That being said, just like any other fairly complete solution, it's quite opinionated about the right way to do things, and it's very different from github or gitlab. In particular, since it is not tied to git, it duplicates some of git's functionality in its own tools. In many ways I find those tools to be better than what git uses (arcanist just seems more well thought-out from a UI perspective), but it is a learning curve.
If you are happy with svn or hg, and don't want to have to switch to git, Phabricator is a no-brainer. If your team is a bunch of super-advanced git users, they may not like having to learn a different way of doing things.
1. Supports Mercurial - our repositories are currently in mercurial, and using any other tool would require switching to git (which we seriously considered while looking at tools).
2. Simple to maintain - if you have experience setting up other web applications based around LAMP, this is essentially very similar. The web interface even indicates setup issues to admins, from things which can cause issues to performance configurations in things such as MySQL and PHP.
3. The code review interface was more intuitive for myself and other engineers. From the command-line tool (Arcanist) to how it's conveyed to the user in the web interface. It did take a little time to fully comprehend and implement the process for using, but since implementing in Feb. of last year, after around 4 months we had near 100% adoption by the engineering department. The GitLab/GitHub interfaces I've found to not be organized intuitively -- the lifetime of an issue/changes seems (seemed?) more social-based and intermized where in Phabricator an Issue/Task is almost separate from the changes which can go into it, though they reference eachother easily.
>Also, do they pride themselves for writing this in PHP? I consider this an anti-feature, but this might be highly opinionated.
I had the same reaction at first (thought I wouldn't say it's pride?). In fact the first time I looked at Phabricator (~2012) I totally dismissed it for three reasons:
1. Written in PHP
2. Mentions pokemon on the front page
3. Marketed as "collection of open source web applications"
These led me to believe that it was at most some PHP glue some students hacked together to get different unrelated applications to play together. This conclusion is entirely wrong. I've since changed my mind about PHP - biased from earlier experiences there's no reason to think a reliable/stable application couldn't be built on it. Phabricator (I believe) started as an internal application at Facebook which has since become its own company. The code is very well organized (I've contributed some small changes), and there are some very bright people working on the project - I get the vibe that they genuinely want to solve the right problems rather than checking features off a list. There are very few dependencies on other libraries unless you specifically decide to enable extra features, and even then there's some support/documentation there to assist. Despite the light-hearted humor (see pokemon) that is a staple of the software (unless you enabled serious-business mode), the project is designed and developed by highly capable, quality professionals.
I couldn't have been happier going with Phabricator over GitLab.
Fortunately (for my team at the time, which was very resource constrained) those who hated it eventually won, but I, being kind of on the fence regarding it (wasn't keen on the UX, but liked the features), sort of wondered what would happen if someone improved the UX beyond the tipping point.
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!
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.
Monopoly. Github enforces their CoC which has nothing do to with good coding practices or technological progress, they ban repositories and people based on their views expressed in comments.
I'm curious as to how people tend to go about doing this. Any recommendations?
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.
At GitLab we are honest about issues, and transparent about what we're working on. HTH!
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.
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.
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.
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, 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.
I had to do an upgrade from Gitlab 6.9 (source-based on ubuntu 12.04) to 8.3 (omnibus rpm on rhel7, managed via puppet) recently, and it was surprisingly smooth.
The package-based installer bundles all the needed software, which is quite okay for software like gitlab that often depends on specific versions of auxiliary software. It uses a built-in chef to configure its components.
I performed the upgrade in two steps, first to 7.14 (on the source-based install), then did a backup/restore to the new server with omnibus and upgraded it to 8.3.3 with yum.
Gitlab migrated the database mostly correctly (there were some issues with the LDAP provider; some users had the wrong provider in the database, but that was easy to fix manually. I'm not sure what caused it) which was quite a surprise considering I went up 2 major versions in two steps. Even upgrading the source-based installation went very smoothly even though it had to download a couple dozen ruby gems from the internet.
The upgrade also affected CI functionality for one of our users but I think that was because it relied on pre 8.0 non-builtin CI, and simply needed reconfiguration for the new system.
Afterwards, a point-release upgrade took a whopping 5 minutes (most of which was downloading and extracting the new RPM).
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
3. What features of EE belong in CE in your opinion?
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.
1. Shibboleth is now supported in the Omnibus packages https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/inte...
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.
> What features of EE belong in CE in your opinion?
which means rcarmo knows they're in EE, but thinks they belong in CE.
Gitlab allowed us to do that without any hassle, even running inside an LXC container.
Did you mean Gitlab?
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 :)
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.
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.
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.
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.
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.
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.
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.
Since we are a remote company we have the luxury to be able to hire amazing engineers from all over the world. Paying 1 Dev salary in the Bay Area is almost the same as paying 2 salaries in Europe, or even 5 in Latin America. Talented people can be found everywhere, not just the bay area.
And having a global workforce also allows us to have the best people with a vast variety of backgrounds, which also contributes to our culture.
Once their performance increases, maybe we'll see the momentum shift from Github.
Github OTOH has an extremely usable mobile UI.
Screenshot - https://twitter.com/gitlab/status/688103614556995584
udaiso03: https://archive.is/jZFbR NSFW!
bamwar10: https://archive.is/HeWvt
opmania35: https://archive.is/jNEr2 NSFW!
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).
Regarding choosing features for EE, I recently updated the text on 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
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 and the Omnibus Packaging https://gitlab.com/gitlab-org/omnibus-gitlab/ to ensure that people can easily generate and alternative distribution.
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.
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)
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
1. Nested groups should solve that in the future 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.
How does GitLab compare to Phabricator?
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
[1]: https://gitlab.com/gitlab-com/www-gitlab-com/issues/514
I'd be happy to be proven wrong.
RhodeCode actually supports Git, Mercurial, and Subversion.
There's a big difference between Kallithea and RhodeCode. Kallithea development is stale, and there's not a lot of things going on in this project.
RhodeCode is adding new features constantly, and the project is really active.
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).
Github grew popular because it was popular. Maybe thats worth something but long term they must adapt just like Gitlab
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.
> This attempt by the Gitlab folks to ride the Github dissatisfaction
> wave seems a little low-brow.
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.
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.
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.
That's basically what they did. They said "hey, you have these issues with GitHub, we're covering them, AND we listen to the community".
I think it's great that they responded to it, since it proves they actually listen and care about what their audience thinks.
I can hardly imagine a better outcome. Now both GitHub and the developers have a choice to make; GitHub can either ignore the complaints or take them into account, and people can either continue using GitHub or start using GitLab (or something else). Nothing better than informing people in a kind, respectful manner.
> I think Gitlab has improved tremendously in the last 18 months.
I agree, IMO it's already better then github - I know people will disagree on that, but I find the UI way better - Easier to find things and navigate for someone who doesn't work in github very often (milestones for instance).
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.
Please open an issue with what you tried exactly.
I think the spammer is trying to make a point! For starters, there seems to be no rate limit applied.
These are pretty essential.
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 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?
> 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.
I use a command line for everything else in life; but with Git I'm hopeless.
What does this have to do with anything? Are you suggesting that service run on Microsoft Azure are not stable?
The downtime of GitLab.com is something the team are committed (see https://about.gitlab.com/gitlab-com/ - 'Disadvantages') to improve this year.
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...
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 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?
To clear things up: GitLab.com is completely free, with unlimited projects and collaborators. GitLab CE is open source and completely free. GitLab EE costs money and has a 45-day trial.
1. The Hosted CTA is the right-most one. People don't read that one. Eyes naturally go to the first CTA, and then compare it to the 2nd one. Based on the first 2, I expect the 3rd one to be another downloadable package, not a hosted option, so I don't read it.
2. The top nav-link is "gitlab.com" not "hosted service". If I don't know that gitlab.com is a git hosting service, I'll never look there.
3. As mentioned, features + pricing don't mention gitlab.com, so once you get off the front page, you lose any hints of a hosted option unless you know what the "gitlab.com" link is for.
4. The first headline that my eyes go to below the fold is:
Self-hosted, scalable and updated monthly
Right now, since you're advising people to go self-hosted rather than gitlab.com, that might all be working in your favour. But when you get the performance + reliability of gitlab.com sorted out, I'd strongly advise you to make the SaaS option a lot clearer.
(I realise that I could submit a patch to index.html, but I don't think my 10 minutes of hacking is going to get you to the best outcome)
The 45 day trial is for the case when you want to host gitlab-ee yourself on your own server.
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.
As evidence, just look at our Direction page: https://about.gitlab.com/direction/, or compare the CE and EE changelogs: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELO... vs https://gitlab.com/gitlab-org/gitlab-ee/blob/master/CHANGELO....
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.
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 :-)
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.
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.
You might even get the community to develop EE features for you to sell :)
We've been using GitLab CE for a while internally and it's fantastic. Don't dismiss it because of some narrow-minded ideology.
The EE edition features make a lot of sense for much larger organizations I suppose.
Working with a on-premise GitLab CE has been just fine in a company with 20 developers, using Jenkins and later Go[1] for CI.
[1]: https://www.go.cd/
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.
Meanwhile at Github, $7 gives me hosted private repos. It's free on Bitbucket if I limit collaborators.
The biggest selling point of these services is peace of mind and knowing someone is taking care of the code when I sleep. Otherwise, Git has always been a FOSS.
Definitely. There's not much you can do with self-hosted GitLab that you can't do with pure git. GitLab just makes it easier, IMO. The main reason my company uses it is to restrict the master branch to certain people - doable with pure git, less effort with GitLab.
There's no reason we couldn't use GitHub for this (wouldn't cost much for a team our size), but my company prefers on-prem whenever practical for various reasons.
Self-hosted GitLab doesn't fit all the same uses as GitHub (I wouldn't use it for personal projects), but when it does fit it's great to have.
The point I was making in the original comment was that Gitlab has absolutely no options without heavy onboarding that is hosted as well as reliable. I wasn't really undercutting their on-prem, just pointing out that comparisons with Github are heavily misplaced.
Setting up your own instance is not hard [1], but we're also offering managed hosted instances on GitHost.io nowadays.
If you're still in the middle, you could use the one-click deploy options from providers such as Digital Ocean, Cloud 66 and AWS images [2].
[0]: https://gitlab.com/gitlab-com/operations/issues/42
1. Hosted Git. 2. Reliability.
There is none. I don't know why you seem to be trying to deny it. Your business obviously works with Enterprise. If I was a big corp, I'd be all over you. I'm not sure with Gitlab's compulsion with trying to make everyone happy. Even when they don't have a product that fit a nominal need in market (the 2 points above), they constantly try to insist that they do.
And we're working hard to make GitLab.com reliable, fast and free too.
In my opinion its nice to have the ability to host it yourself and it was the primary feature attracting me to GL, followed by it looking user friendly for a few people I am working with who are not shell people, and what finally sold me is they clearly have a team which is focused on making the product better.
* 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.
The mercurial support is great because of legacy code (I finally have come to admit that Git is superior for most purposes). The unlimited private repositories is great because we make loads of projects. I came from so many companies that would have this giant monolithic tree of tangled dependencies because they would check everything into one project. I fear this with GitHub's pricing model.
I find BitBucket's dashboard useless. It used to be decent but they changed it some years back. BitBucket's security was sort of disturbing as well but I believe they have added 2 factor authentication.
I will say that Atlassian's Jira used to be the best bug tracking but I have found that in the last couple of years it has become a complete bloated pig that is overly complex and slow. The hosted Jira is so awful that we contemplated just using BitBucket for bugs. We eventually switched to Youtrack and are loving it.
That said, I've also used it in a paid, hosted environment supporting a team of 10. Again, our needs weren't overly complex and the integration with team software like Jira and Confluence were great (as can be I suppose, given the complexity of both tools).
I'm actually surprised there isn't more of a discussion around bitbucket and the cost of hosting smaller, private repos. Do most just dislike bitbucket or are you hosting bigger projects with multiple contributors which requires Github / gitlab services?