Dear open-source maintainers, a letter from GitLab • Hacker News Board

Re: Dear open-source maintainers, a letter from GitLab

#141

Post by sytse » Mon, Jan 18, 2016, 2:38 PM UTC

DouweM wrote: post #98

drewcrawford wrote: post #86

Earlier quoted context omitted.

> 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/ > 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 wi…

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.

We can't promise we'll never be acquired but we when we raised financing we tried to ensure that we're as much in control of our destiny as you can be as a VC founded start up. For example last month we were cash flow neutral.

GitLab CE is MIT licensed and will not go away in case we get acquired. Some companies (including Oracle themselves) are using GitLab CE with thousands of users (they rebranded it as Orahub, don't ask).

For our promises regarding being a good steward of CE please see https://about.gitlab.com/about/#stewardship

Re: Dear open-source maintainers, a letter from GitLab

#142

Post by digitalsushi » Mon, Jan 18, 2016, 2:39 PM UTC

pekk wrote: post #116

mahouse wrote: post #58

Earlier quoted context omitted.

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.

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

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

Re: Dear open-source maintainers, a letter from GitLab

#143

Post by sytse » Mon, Jan 18, 2016, 2:42 PM UTC

Rafert wrote: post #68

bigbugbag wrote: post #21

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 r…

git-annex is EE-only, but they're giving you git-lfs for free in CE. I expect the latter getting way more traction due to GitHub's backing. 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/

We think that Git LFS has more traction too. Any reason why you're using Go instead of GitLab CI?

Re: Dear open-source maintainers, a letter from GitLab

#144

Post by sytse » Mon, Jan 18, 2016, 2:42 PM UTC

skrebbel wrote: post #64

DouweM wrote: post #46

Earlier quoted context omitted.

> 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 eno…

Honest question, did you ever consider making self-hosted GitLab EE free under a GPL-like license, but only for installations that only host open source and are reachable from the internet? You might even get the community to develop EE features for you to sell :)

I don't think that limiting it to only-open-source is compatible with the GPL license. But in the HN thread I did make an offer for free EE licenses for open source projects https://news.ycombinator.com/item?id=10924406

Re: Dear open-source maintainers, a letter from GitLab

#145

Post by sytse » Mon, Jan 18, 2016, 2:43 PM UTC

levlaz wrote: post #35

bigbugbag wrote: post #21

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 r…

I think called the community edition crippled is a stretch. I have a small team (4-5 devs) that has been using the CE for a few years now and we have been more than happy with it for all of our needs. The EE edition features make a lot of sense for much larger organizations I suppose.

Glad to hear that in your case we made the CE/EE feature tradeoff correctly!

Re: Dear open-source maintainers, a letter from GitLab

#146

Post by quaunaut » Mon, Jan 18, 2016, 2:44 PM UTC

georgefrick wrote: post #117

vincentkriek wrote: post #38

Earlier quoted context omitted.

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 aspe…

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

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

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

Re: Dear open-source maintainers, a letter from GitLab

#147

Post by sytse » Mon, Jan 18, 2016, 2:45 PM UTC

jbk wrote: post #136

sytse wrote: post #111

Earlier quoted context omitted.

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_... 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…

Thanks a lot for the answer and the proposal. But we do not want to have anything critical that is not open source. We try to promote OpenSource, so using non-open-source software is hard to do. 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 :)

Thanks, I get that you don't want to be on proprietary code. I'm look forward to your email. And we're open to discussing open sourcing features if that is needed.

Re: Dear open-source maintainers, a letter from GitLab

#148

Post by fweespeech » Mon, Jan 18, 2016, 2:48 PM UTC

georgefrick wrote: post #117

vincentkriek wrote: post #38

Earlier quoted context omitted.

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 aspe…

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?

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

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

Re: Dear open-source maintainers, a letter from GitLab

#149

Post by ausjke » Mon, Jan 18, 2016, 2:58 PM UTC

techdragon wrote: post #95

jbk wrote: post #9

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 th…

Did you guys evaluate Phabricator? I wish more people knew it existed and wouldn't pick such "sideways" moves like GitHub to GitLab in an effort to be more "open source" philosophically speaking.

Phabricator has so many "strange" naming and after some basic reading I never found it's interesting/easy enough for me to get started, sigh.

redmine, gitlab, bitbucket, github are what I am using for various things.

Re: Dear open-source maintainers, a letter from GitLab

#150

Post by unethical_ban » Mon, Jan 18, 2016, 3:00 PM UTC

masklinn wrote: post #53

technomancy wrote: post #31

Earlier quoted context omitted.

If you have to create a label for every platform you support and every existing priority and module, the labels list will become really cluttered, making it hard to find things.

It becomes very long, but it doesn't seem overly cluttered, and it avoids the risk of overly restrictive either/or classification. Rust makes extensive uses of labels on github, they're up to 120 at this point[0] and it seems to work reasonably well even with old issues with a fair number of labels[1] [0] https://github.com/rust-lang/rust/labels [1] https://github.com/rust-lang/rust/issues/5016

FWIW, at my office for the small projects we have tracked, we use a similar method.

type-label

    Types:
    b - bug
    f - feature
    p - priority
    t - team

So we might have issues tagged "p-med b-confirmed t-group1"

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.