Luc @framasky
.@gitlab Would it be possible to have gitlab-pages in the community edition in the future? We, @framasoft, a non-profit organisization 1/2
As detailed in https://about.gitlab.com/about/#stewardship our policy is: "When we make new features we ask ourselves, is this feature much more relevant for organizations that have more than 100 developers? If the answer is yes the feature is likely to be exclusive to EE.". The extent of their organization seems to confirm that this is a feature like this.
I hope it is an option for them to use GitLab.com. If not we should maybe consider having a discounted EE license for not-for-profits if they are interested in that.
Well, I think it's a feature that can be useful for a lot of small (less than 100 devs, even for personal instance) gitlab instances: I developped a few softwares, and it's a pain to make a website for presenting them (such a pain that I did that only for one of them). If I had a personal gitlab instance (I don't: since I'm the sysadmin of Framasoft, I eat my dog's food and use Framasoft's services), I would be happy to have gl-pages to easyly make my presentations sites in one place. I think I'm not the only one.
Also, Gitlab-pages does not need to be a Jekyll based static website compiler. All it needs it to be able to serve static files from a specific branch.
I also would love to see this, we are a small shop (3 people) and hosting our repo's outside is not an option, but I understand/respect it is a business decision.
I host my blog on GitHub Pages because it's super convenient to have a local copy and be able to publish in one command.
Having GitLab Pages on Framagit (i.e. in GitLab CE) would really make me consider moving my blog and other repositories here.
One evidence for this feature being much less relevant for organizations that have more than 100 developers is that I wrote this for ourselves who are urgent about serving pages: https://github.com/YuMS/gitlab-ce-pages. It's unofficial. Please rule it out by smashing it with the official shiny Pages support.
Maybe there is also a problem with pricing. It looks that Gitlab considers only two sides : large organizations, and everybody else. But there are also small organizations, and non-profit ones, as we can see.
I am part of a very small company (actually, we are 2 people) and $40/user/year is not something we can afford. Our clients have averagely several accounts, so they can report bugs. It would quickly make the EE price expensive. Yet, gl-pages is a feature we would love to use.
Why not consider:
a "small enterprise edition", with a restricted number of users/projects, but a constant price.
I was recently thinking of setting up a small static blog, and I wanted to use Gitlab pages instead of Github pages as I prefer running on free software. I was then pointed at the fact that Gitlab pages is actually not free software, and I must say that it hurts a bit. I wouldn't mind paying a small fee to have my blog on the central gitlab.com servers, but I am not very enthusiastic about having to use EE features.
A "plus one" here. We're a tiny 2 person start up with quite literally no money (if we had it, we'd pay for EE without a doubt). Pages would help us immensely with keeping our internal docs and notes organised. The Wiki system in Gitlab isn't able to do this due to it's lack of a navigation/paging system or structuring data.
Pages is not a "only used by big companies" feature in my experience.
For those who want some way to publish pages from a gitlab server, I just released something to do that: FsPages https://framagit.org/luc/fs-pages (I was tired to wait that this issue to be fixed). No static pages generation, you'll need to do it before pushing to your repo, but that's better than nothing (and made the development easier).
It's quite easy to install and configure. And fast to publish: it basically clone the dedicated branch and copy the files in a directory served by Nginx. You can read the user documentation on the Framasoft instance (and the admin documentation on the repository).
Anarchy Tools (~3 contributors) currently uses GitHub pages to host http://anarchytools.org. We can't use GitLab.com due to various strange CI requirements forcing us to self-host, and hosting pages on our existing self-hosted CE would have been a natural fit. Unfortunately we can't use CE for pages, and mirroring to GitLab.com from CE would be annoying, so we went with GitHub, as it's the devil people know.
This week I am tooling up to create static documentation for ~10 projects that I personally self-host on CE. EE is not really viable, there is a slight cost issue (e.g. paying for licenses for random drive-by contributors feels weird) but really what is drives the bus is the free-as-in-freedom thing. It's not worth doing a (one-way?) upgrade of every personal project I have just to host some documentation for a few. Easier to just create a builder that pushes the websites to S3 and not have to worry about lockin of my issue database now having a weight column or whatever it is that EE does.
Obviously I don't begrudge anyone for keeping features behind the firewall, but I do think this is a pretty clear case where lots of open-source projects use GH pages with a page or two about their project, and making them choose between two proprietary solutions to that problem will likely result in them using the popular one. IMO GitLab is not served by that state of affairs.
I think you should reconsider the conclusion that Pages is a feature that would be more relevant to organizations with over 100 developers. A gitlab-integrated, static website is much more relevant to open source projects, and equally relevant for small teams as it is for large teams.
Consider the use cases for a repository-integrated static site:
Hosting project documentation. This would be incredibly useful for us, as we use an SSG (Slate) to create much nicer documentation for our public REST API.
Blogs
Presentations & Installation Instructions
Public list of software builds / nightlies? Distributing binaries?
Consider the name, Community Edition, and then think: Of the use cases for GitLab Pages, which are more relevant to organizations with 100+ developers? What about community-oriented / open-source projects?
I think organizations with 100+ developers would seek a more organized solution for these things: Either Confluence or SharePoint or something similar; Certainly not a static site generator.
If not GitLab then someone else will release free open source extension to GitLab for that. This feature is also important for single developer building his release cycle. Maybe this feature could be community funded? @sytses
As per Sid's comment, we're currently not planning on bringing GitLab Pages to Community Edition. With that decision I'm closing this issue, to signal the status of this. You're more than welcome to continue commenting here, as are we to -at a point in the future- reopen this issue and/or reconsider our decision.
I'd like to point everyone again to our Open Source Stewardship for the reasons for this decision. From our perspective, it would be great for everyone to bring every feature of EE to CE, but it wouldn't make sense for us as a business. This is why we created the guidelines as detailed in our stewardship document.
This is a two-sided coin and the inverse has happened with a feature that we were planning on making exclusive to EE edition, for instance in the cycle analytics issue.
With every feature the choice of leaving it exclusive to EE or bringing it to CE is very tough. For GitLab Pages we see minimal effect for smaller installations, hence our decision to leave it exclusive for Enterprise Edition.
It's unfortunate that the decision doesn't seem to engage with the specific counterarguments. I am well aware that Gitlab believes that Pages is less relevant for small organizations. What is much less clear is the basis for that belief, and how it was reconciled with the specific examples of small organizations that were put forward in this thread.
I and others have made specific arguments on principle 4 and the "more relevant for organizations that have more than 100 users" test. Maybe they were bad arguments. But IMO "here is a link to our principles" is not responsive to those arguments, and does not explain how the principles were applied to reach a conclusion when others used the same principles to reach a different conclusion.
I've been watching this thread for a while, and finally decided to use GitLab-CI as my solution; it's not hard to set up and is reliable and simple. Best of luck to y'all.
In this case, I'm using Jekyll to build my site, and then a simple rsync command sends it off to a directory served by a VirtualHost on my (local) web server. Obviously you can modify this to work in your environment. It only runs after a change on master, so you can use branches to draft your content and then merge them when you want them to get deployed. Here's the relevant part of my .gitlab-ci.yml file:
pages: stage: deploy environment: Production script: - bundle - jekyll build -d public - rsync -r --delete public/* /var/www/blog artifacts: paths: - public only: - master
@dopesong Just a few pointers, https://gitlab.com/gitlab-com/www-gitlab-com doesn't use Pages, instead it set up a runner to be used only for deploys on the production server. When you trigger a deploy job, only think left to do is rsync your files to the right location.
Perhaps it's worth pointing out again that if your small company just wants to host your static sites, including custom domains, you can use GitLab.com for free. There's no need to have this in your local installation at all.
You can also use GitHub for free :-) In fact a lot of my projects are locked in there, and migrating those projects to another proprietary SaaS gains me nothing and costs me my time.
There are supposed to be principles that are used to decide what goes in CE and what goes in EE. As far as I am aware, "you can use EE for free so it doesn't matter" is not one of those principles.
Free-as-in-beer and free-as-in-freedom are two different motivations that require two different solutions, and the fact that something is free-as-in-beer is not compelling for problems like mine. I would be very happy to pay $ for Pages; I already spend more than that on hosting etc. and quite frankly paying GL for Pages would be way cheaper than the time to roll my own site hosting, like 1-2 orders of magnitude cheaper.
But it would lock the FOSS projects I host into what is effectively a proprietary documentation vendor. It's 2016 and there's no reason to depend on proprietary software for webhosting when FOSS web servers and static site generators have been a solved problem for many decades now.
I would be very happy to pay for EE. I just don't want to actually run it; especially for a simple thing like hosting a website.
If GL wants to run a hosting service along those lines it's their right, but I am a controversial person who publishes controversial things and I can't depend on a proprietary software vendor for publishing web pages in 2016, neither for hosting, nor for licensing. I need a utility that takes my money and stays in their lane. When GL declines to do that it means I can't use Pages, and I must cobble my own solution with FOSS and traditional hosting.
Having Pages in CE means that a lot of developer will use gitlab as their blog hosting which means more adoption, more developer using Gitlab, there will be more people comfortable with using and more people talking about it which means more organization will use it, and more paid customers down the track. Please reconsider this issue.
From my point of view, GitLab Pages has a great potential for academic research and teaching. Academic labs and teaching departments cannot afford a gitlab EE instance based on a per user rate because of their limited financial resources and the unlimited number of internal and external contributors. Due to confidentiality or public visibility issues (see CNRS' data policy in France), it may be important for us to run a private GitLab instance and not to rely on GitLab.com.
@boileaum We actually offer educational pricing for EE in case you were wondering.
Is there educational pricing?
GitLab's Educational pricing is that for educational institutions, students do not count towards the user count. The purchase of at least one subscription is required.
https://about.gitlab.com/products/
Does not solve the problem described by @omeid or even worse if you use the gitlab instance for research like we do with over 150 users where just 50 or so are students ...
I'm not convinced by the claim that a research institution with 150 non-student workers cannot afford to pay for a Gitlab EE instance if they want to. It's like $39/user self-hosted, $35/user hosted, per year. That sounds extremely small in relation to the salary of all these people, or the money they spend on conference travel for example.
Depends ... public sponsoring e.g. by the EU allows quite some money for salaries but nearly no hardware or software invest ... as IT personal this is pretty hard to understand ... for me too
I'm also working on some opensource TYPO3 / Flowframework stuff, where using pages could save some time, as said, there is a simple nginx based solution (rsync to folder + rewrite rules).
In order to get something sponsored by a PI, you need to make a very strong case that it is required for your research and that you can't get it done yourself. I wouldn't be able to justify GitLab EE licenses for 5 people just to have GitLab pages, since it's not that hard to set up a local VM with NGINX to serve those pages. But then it's a bit silly for everyone to have to do this, if the code for GitLab pages already exists.
Let's put this another way: I think there are strong arguments for why making Gitlab Pages free software is a good decision for Gitlab to make. @omeid above for example said:
Having Pages in CE means that a lot of developer will use gitlab as their blog hosting which means more adoption, more developer using Gitlab, there will be more people comfortable with using and more people talking about it which means more organization will use it, and more paid customers down the track. Please reconsider this issue.
This is an excellent argumentation. People with blogs use nickname.github.io super often right now, and if there was a free-software-powered alternative it would be a no-brainer to use that instead for many. (You can argue that gitlab.com and Gitlab EE in general is already powered by free software in part, but then Github already is (some parts of the codebase are free software), it's a difficult distinction to make.)
That sounds like a much more convincing argument to me than saying "this category of users is for this and this not-so-convincing reason unable to pay for your offering so you should give it to them for free". I also happen to be a researcher and I know that while funding flows can be tricky to manage, a research institute with 150 workers can be convinced to spend $6K a year on technology if there is a strong argument for it. Now you may say "they will self-host Gitlab CE for free instead because they don't really need the EE features but we would really like to have Gitlab Pages please", but then it becomes apparent that this particular question would be about getting stuff for free instead of paying, which is not a particularly good way to convince people selling their product to make a decision.
My personal GL install is open to the general public so that they can report bugs and/or whine about my open-source software, much like many of us are doing here. As a result I added about 50 new "users" last month, all of which were drive-by-sign-in-with-github types.
Shelling out for 50 new EE licenses each month is never going to happen regardless of how many features are in EE and how great they are. 10 licenses/year on the other hand could easily happen, but "after which you can use a proprietary static webhost" is really the opposite of a compelling upgrade reason.
I don't know who benefits from the existing segmentation scheme or how it was arrived at. But I do know that it actively pushes my wallet off the table in a way that seems weirdly inefficient. Maybe my segment is just too small to be relevant, but that is weird too – a free lunch always ends at some point.
I'm happy to see everyone to passionate and excited about GitLab Pages. I've already outlined our decision making in why we've made it exclusive to EE.
That said, potentially our assumptions about this feature were wrong. Using Pages as a marketing site is definitely an interesting use case; inversely using it for an internal wiki seems overkill for small teams (i.e. you're working as a bigger team).
I can't take this decision on the spot. I'm going to look into the data we have on page usage to either confirm or falsify my hypothesis (Pages is mostly interesting for larger organisations) and come back here with a decision. Of course, this is also a business decision for GitLab Inc, so I hope I can have your patience in the matter. I expect that we'll be able to decide something before the end of the week.
@JobV@gitlab It means a lot that you let the discussion open and ended up reconsidering your decision.
I was worried because your are a VC-backed company with an open core model and you are proving me wrong :-D
Seriously, consider crowdfunding (one time for a feature or even recurring funding) to let the community have more weigh in the economic balance. That way, your could move the line between CE and EE more in favor of CE.
Your biggest strength is that you are doing libre/open source software and a part of GitLab users came from GitHub precisely to use libre/open source software. These users don't fit in your current business model but I think they would love to ;-)
Crowdfunding is good. I would also be willing to pay a sum each month (eg. $5/month or $10/month), with the understanding that the money obtained from those subscriptions would only be used to develop and improve CE features. This is what the new Qubes OS Community Funding approach guarantees, and I think it is a very good idea.
(One issue of course is that there is a tension between funding CE developments and keeping EE worth the extra money for clients.)
(One issue of course is that there is a tension between funding CE developments and keeping EE worth the extra money for clients.)
This tension already exists. Letting the community throw money at GitLab would only help solving dilemmas in favor of the community without taking a financial risk.
Actually I love that this is happening.
I also think that this has a nice followup ticket.
Bring Letsencrypt Support for GitLab Pages, I guess a lot of small Customers will profit from that, so that a new page get's it's cert automatically.
@nick.thomas What do you want to do here? (Meaning, you're the maintainer of GitLab Pages; do you have time to do this in 8.16? How do you want to proceed?)