I am hosting this from my home, I am not a business just learning and playing, is there a charge for this application, the search I performed was for open source
GitLab comes in two editions, community (CE) and enterprise (EE). You can freely use CE in your environment, self hosted and at your maintenance level. If you need specific features only available in EE, you’ll need to buy a license.
Here’s an introduction into both: https://about.gitlab.com/install/ce-or-ee/
@dnsmichi is completely correct, but only addresses the parenthesised part of the question. There’s more to being open source than being free of charge.
That does technically make GitLab CE open source, and that part is developed with contributions being accepted.
I find that more employee activity on this forum, and more listening to the community is needed before I would really consider it open source.
Agreed, I did not move into the open source components here. In terms of building open source communities, this really is a tough topic. I’ve been helping to build the Icinga community in the past 10 years, with my day job as backend developer, sometimes hard to keep both sides on the same level. With GitLab, I didn’t know where to start contributing in the past years, the issue tracker is overwhelming, and chiming into the forums with many different questions from a, pardon, feature monster is something which took me a while.
With attending GitLab Commit in London lately, and shifting my work resources to doing more GitLab trainings, workshop and consultancy, I’ve found a way for myself to get to contribute more. And to also provide feedback on the cases how exactly I’ve found it hard to get things going.
Learning more how this forum works, how engaged community members are, and how we can make it better is something I’ve started lately because I think it is worth it. Also, listening to users and moving the feedback along into issues to raise awareness for product and engineering. You may have seen responses from me where I didn’t know anything, read the docs a little, and tried to help out. The potential of pushing people to more engagement without the need of vendor employees is something I’ll always try.
@dplanella Is there a tracking issue or epic for this sorts of feedback where we can collect that? (just an idea)
The most accurate answer to @kdmiller45 ‘s question will depend on the definition of free.
Free as in free of charge :
There is no charge to use GitLab, either self-managed or GitLab.com. You will never have to pay to use GitLab-CE. The only cost associated with running
gitlab-ce is the cost of running the server.
Using GitLab-EE is also free of charge, and will behave exactly like CE if a license is not applied, which is equivalent to a GitLab EE “Core” license. The difference is that EE contains the
/ee subdirectory with code that will only be used if a license is applied to a self-managed instance.
GitLab.com offers unlimited free private and public repositories, with no limit to the number of collaborators.
We offer paid subscriptions and licenses that offer additional features and Premium Support. We also offer free-trials including top-tier features to help users determine which features are most valuable and best meet their needs. If you don’t want or need premium features, using GitLab CE, EE, and GitLab.com are all free of charge.
For free as in freedom :
GitLab-EE is built from this repo, which contains one subdirectory (
/ee/ ) containing code not licensed under an open source license. (gitlab/ee/LICENSE). While most code is licensed under open source licences, and all of our code is source-available,
gitlab-ee does contain some proprietary code.
For “open source” in terms of community and community support:
I can confirm GitLab Support Team officially does not provide support for Core and Community Edition users. We’ve recently hired a number of new Community Advocates, who will devote part of their working time to monitoring on the Community forum, helping where they can, and escalating issues as needed. Having said that, myself and other GitLab team members do monitor and answer questions in the Community forum in our free time as a courtesy.
GitLab employs a docs-first methodology to ensure our documentation remain a complete, trusted, and valuable resource for our entire community - not just our paying customers. GitLab also enables and actively encourages our community users to create issues for any problems they run into - from a documentation fix to a feature request.
I recognize and agree that there is room for improvement, and this is actively being discussed. I encourage you to check out our GitLab Group Conversation live-streams, as today’s Community Advocacy Group conversation touched on how to build and maintain strong connections with our community.
Additionally, I have requested an internship with the Community Advocacy team starting in the new year, with one of my goals being to find ways Community Advocacy and Support Teams can collaborate to efficiently troubleshoot and communicate solutions for issues raised in the forum.
@dnsmichi there is not a tracking issue for this yet, but it’s a good idea. Would you be willing to create a public issue in our community-relations/community-building issue tracker to get this started?
Thanks for the detailed insights, much appreciated
I will create an issue in the next days, I just needed confirmation where to put it. And I’ll need some time to write everything down, I do have some ideas and experiences to share
NIce words, a shame they are not true. I have found documentation that didn’t match reality several times.
Some of them have resulted in issues, (generally so little happen, that I often can’t be bothered to waste my time creating an issue, preferring to spend it finding out how things do work) an example:
(I’m the one who made the referenced support issue)
Most lately a “Solutions Architect” (quoting from one of his emails) for GitLab, that I have been corresponding with after our account manager put us in contact, sent me a link to
unfortunately simple testing of the command used gave an answer far from the shown. (It might still be usable for the task discussed, it’s just an example of outdated documentation).
So, how can we improve the process of making users create issues or even merge requests to fix the documentation? Is this something which should be taken into account e.g. for community hackathons with not only adding features but doing a documentation “overhaul” in a guided way? I personally love writing documentation and am able to guide others in this regard if desired.
Holidays are refreshing, so I’ve collected everything we’ve talked about in the past weeks into a new issue. Everyone please join the conversation