Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dear open-source maintainers, a letter from GitLab

about.gitlab.com

Post reply on HN
Print view View original

301–310 of 325 posts

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

#301

Post by imonabout »

timv wrote: post #247
DouweM wrote: post #80

Earlier quoted context omitted.

Hmm, the front page ( https://about.gitlab.com/ ) lists "GitLab.com — On Our Server — Free hosting for private repos? Sign up to get unlimited repos and collaborators. — Sign Up", but I get that it's a bit confusing that the features and pricing pages don't mention anything about it. To clear things up: GitLab.com is completely free, with unlimited projects and collaborators. GitLab CE is open source and completely f…

I definitely think there's a discoverability issue there. 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 ho…

I think you've described better than me why one might overlook certain things. I was far from clear on that when I originally wrote my post.

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

#302

Post by sytse »

cyphar wrote: post #275

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

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

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

#303

Post by deanpcmad »

mdw wrote: post #183

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…

Just bought it thanks to recommendations on here. Looks like a great app. Thanks!

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

#304

Post by sytse »

merb wrote: post #288

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.

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

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

#305

Post by merb »

sytse wrote: post #304
merb wrote: post #288

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.

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 that uses our new build status API, so I think this is doable al…

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.

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

#306

Post by hobarrera »

sytse wrote: post #297
sytse wrote: post #292

Earlier quoted context omitted.

Makes sense, this was also requested by the VideoLAN people in https://news.ycombinator.com/item?id=10923688 I've made https://gitlab.com/gitlab-org/gitlab-ce/issues/11489 to discuss.

Our CTO and CRO gave their approval, we'll open source the branded login page.

It's great to see such a fast, and positive response. It's a whole league away from companies that don't even give any transparency or feedback! <3

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

#307

Post by scrupulusalbion »

sytse wrote: post #290
masida wrote: post #186

Earlier quoted context omitted.

This is really a problem I think. Maybe GitLab could reconsider to adopt a licensing model[1] for the Enterprise Edition that would make it more Free Software friendly? [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.

When we introduced the Enterprise Edition we had it under MIT license. This caused much confusion with our customers. Maybe the situation is better now with companies like Hortonworks educating the market. But unlike others we want to make our open source edition as simple to install and maintain as the paid version. Anyway, maybe you could be a bit more specific about the problem you see with our model, I would love…

My understanding from taking a Red Hat sysadmin course is that what you get from a RHEL subscription is firstly access to their repos from which to download updates and additional packages. The other, perhaps bigger, portion of a RHEL subscription is the support; I think they will answer the phone and provide you fixes for any bugs in RHEL-provided software relatively quickly. This is nice for companies, for whom uptime and stability are often superior to most other concerns, like staying close in feature parity to upstream.

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

#308

Post by bovermyer »

dham wrote: post #105
xena wrote: post #84

Earlier quoted context omitted.

Go is easier to deploy than Rubby on Fails.

Does that even matter in the world of Docker?

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

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

#309

Post by sytse »

hobarrera wrote: post #306
sytse wrote: post #297

Earlier quoted context omitted.

Our CTO and CRO gave their approval, we'll open source the branded login page.

It's great to see such a fast, and positive response. It's a whole league away from companies that don't even give any transparency or feedback! <3

You're very welcome.

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

#310

Post by sytse »

scrupulusalbion wrote: post #307
sytse wrote: post #290

Earlier quoted context omitted.

When we introduced the Enterprise Edition we had it under MIT license. This caused much confusion with our customers. Maybe the situation is better now with companies like Hortonworks educating the market. But unlike others we want to make our open source edition as simple to install and maintain as the paid version. Anyway, maybe you could be a bit more specific about the problem you see with our model, I would love…

My understanding from taking a Red Hat sysadmin course is that what you get from a RHEL subscription is firstly access to their repos from which to download updates and additional packages. The other, perhaps bigger, portion of a RHEL subscription is the support; I think they will answer the phone and provide you fixes for any bugs in RHEL-provided software relatively quickly. This is nice for companies, for whom upt…

We want to give people using GitLab CE an awesome upgrade experience too https://twitter.com/J_Salamin/status/687884326629937152 so limiting our packages server to just EE is not an option.

We tried charging only for support but now that we have the Omnibus packages it is rare for users to need support (and we like it that way).

Post reply on HN