5 ms·
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-o
by jbk 11y ago
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 :)
- sytse 11y agoThanks, 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.
- lenovouser 11y agoI don't know if that would apply to GitLab too, but maybe consider switching from the CE / EE model to just one "product" and a free for non-commercial model? Like e.g. http://3t.io/mongochef/download/ http://3t.io/mongochef/download/ does it? I like that model way more than a feature-reduced version.
- sytse 11y agoWe considered that but we value having a completely open source version for all projects more. For more information about how we see the difference between CE and EE please see https://about.gitlab.com/about/#stewardship https://about.gitlab.com/about/#stewardship
- ymse 11y agoWhat about having a single product, and charging for a proprietary license + support? This may work better with GPL as many large orgs are allergic to it. With MIT license, many sites probably just implement the branding changes etc in the CE product on their own.
- sytse 11y agoWe want to give large orgs the option to run GitLab without having to pay us. We don't mind having people add features to CE, these are the same people that will send enahancements upstream and make GitLab better for everyone.
- JoshTriplett 11y agoHave you ever considered using the AGPLv3 for the Community Edition, rather than the all-permissive MIT license?