I want to say: I don’t necessarily think we should switch from anything. It’s clear GitHub has outgrown us in certain ways, but any switch will irritate people, and we shouldn’t let some kind of haste around this acquisition rush us into something. In fact it has not even happened yet; it will actually happen later this year, and we likely aren’t going to see any real manifest changes in the mean time or well-after, anyway.
It’s pretty OK to be concerned about this if you are, and also pretty OK to want to wait-and-see. IMO those are both OK. But I don’t think there’s a major rush, and any commitment is a long term one, so you shouldn’t just rush into it…
Here’s some bullet points I want to counter. The main thing is that if we move, we should seriously evaluate tools that will help us, not just jump around. Nixpkgs is a serious project with hundreds of active participants – we don’t need to shy away from this fact, and we should embrace it so we can maximize its longevity, and pick tools that emphasize that if we can.
Here’s what I mean. As a competitor, Phabricator has a far more complete and useful suite of tools for scenarios like the ones we want for Nixpkgs, IMO (speaking out of my experience working on GHC), at least as an issue tracker:
-
It has first class concepts of projects, user groups, related issues and issue dependencies (i.e. “123 must be fixed before 345”), even across repositories in an instance. Kanban workboards are customizable “per project”, for example there can be different tasks grouped for PostgreSQL, Nixpkgs maintainers, etc etc. Customizable issue statuses; for example “Open, Closed, WONTFIX, Invalid, In Progress, Merge to -STABLE”, etc. Per-group and per-user UX customizations and dashboards – For example, Darwin maintainers may want to have their own dashboard/homepage by default where they can see related issues.
-
It has very customizable form control that allows granular display of different fields, based on user tiers or roles. For example, you can have 3 different forms such as “Bug Report”, “Feature Request”, and “RFC”. Nixpkgs maintainers may have access to the “Full versions” of these forms which allow unrestricted input. Ordinary users, until ‘promoted’ may be required to fill out certain forms. For example, a user may be required to specify A) is this a NixOS issue or a Nixpkgs issue, B) the name of the module or package. They may have to list a set of exact reproduction steps, and have a separate form for expected results (GitHub currently only has one text box for the template; these are actual customizable forms with boilerplate, etc).
-
It has tools to automatically execute actions like “Add me as CC’d on this issue” given certain criteria are met. For example, “CC me on this ticket if the user submits a Bug Report for package ‘foo’”. This can be combined with things like custom forms, so users are for example forced to specify the package name – in turn, forcing the maintainer to get notified instantly.
-
It has a first class notion of email input (e.g. email to send a bug) as well as actual authorization and audit controls. This means you can, for example, automatically put all security issues into a private queue by default which will need to be immediately reviewed by a security team, or this security issue could come from an email to
security@nixos.org. Members of the security group can promote/fix/kick out the issue as needed. -
It has various other useful features, for example built-in voting tools (for example, allow all Nixpkgs maintainers to do multi-choice voting on a set of features), simple, mini blogging tools (for example, different teams or projects responsible for things could announce upcoming changes that users can see or be syndicated – “Moving NixOS to PostgreSQL 11”, or “Upgrading to GNOME 3.28”), tools for UX/UI mockups (useful when people want to do actual review on visual design changes, e.g. to the homepage), a built-in pastebin (so we wouldn’t have to use 3rd party services), calendars for events like hackathons or meetups or when core devs are available, and even a built-in tool to do URL shortening, stuff like that.
You can see a lot of this on The WikiMedia Phabricator instance. They use Gerrit for code review still, and have some tweaks to integrate it with Phabricator, but otherwise use it for all issue tracking, UX/design stuff, announcing changes.
Note that Phabricator is a pretty serious tool that requires commitment to use, and it is designed to offer maximum utility as a cohesive unit, as opposed to being simplistic or easy-to-get-started. It’s meant for teams that scale up from 50 people and beyond, who will use it every single day and want to maximize productivity (well beyond where Nixpkgs is – think “it should scale for Debian”). This design philosophy obviously influences a variety of features like the above and it means it strives for very particular workflows – the same way it would work inside a company, for example.
For example, it follows a workflow similar to a patch-based model, as opposed to a “branch based pull-request model” that people are used to from GitHub. (They believe the GitHub PR model is basically a misfeature at larger scale). Many Nix committers may not like this; on the other hand, sticking-to-the-workflow it wants makes it very effective. Not everyone likes that tradeoff – several Phabricator users for example have alternative patch submission methods, or simply use a different code review tool out of legacy needs.
Furthermore, if we do something like this, I admit, it would be irritating to go with GitLab for two reasons to me:
-
I don’t think it’s much better than GitHub, all things considered. Having a lot of features and listing all the things they have on their Features page is one thing, it’s another whether any of those are actually useful to us… Saying “They have burndown charts, we might use burndown charts” for example isn’t very convincing if we don’t think we have a need for it. Sure, we might want it – but it’s entirely hypothetical, and as far as we know, the concern around rushing to move somewhere else is just as hypothetical. If the primary critera is self-ownership – i.e. where the Nix community will own the infrastructure – then I suppose being only marginally better is fine, but it doesn’t solve real issues we face day-in, day-out, either.
In short, if we’re going to move to something so we can own it, we might as well at least maximize the utility, based on what our current pain points are. Phabricator for example simply has far better tools for a project of our size I’d argue, regardless of if it has flashy metrics charts we can view every once in a while.
-
GitLab is still a for-profit entity, who is not aligned with us – regardless of “open core, self hosting”, it can be changed, and its tiering situation is at least worrying in some respects. For example, I’d be sad if we used a proprietary GitLab variant for Nixpkgs, and I don’t think I would be alone. At the same time, they gate tons of useful features like “Squash and Merge” behind Gold edition! It’s unclear to me by offering a “carrot” – a free version of their product for FOSS projects – if they still have any impetus to add useful features to the free edition. In other words: if we chose the open core version, and their direction ends up with them gating useful features to Gold/Ultimate (partially, because FOSS projects can qualify, so many will not feel the burden if they opt in), what motivation do they have to give them to us?
This basically forces our hand, more or less, to choose the proprietary version! It’s a kind of dilution and separation of the free software sphere, where people who choose on principle are forced out. This kind of tactic, in effect, reduces the collective bargaining power we users could otherwise exert.
As another counterpoint, Phabricator runs on the same “Paid Support by developers, free user-supplied community help” model as GitLab and GitHub, etc – but is otherwise 100% open source and has no tiering, and is completely Apache 2.0. Phacility, the hosting service, does not add proprietary features. You get everything you’d get from the hosted or “paid” version. (In my experience, users of Phabricator also consider this a plus since it lends to no-nonsense extensions and customization, and many installs want bespoke features). At least if Phacility bails, we won’t be on the hook for features we can never get… We might be on the hook for maintenance, but we’re at least on our own and run our own tools and own them.
If we move to something else we want to control out of these worries, I don’t see how GitLab actually is materially better other than they have a literal free version, but that does not mean their interests align with ours. GitHub was literally free too. People, I think, are not scared by this decision because of a technicality, or even necessarily because of Microsoft – they are scared by it because it is a decision about who has control.
Also, frankly, things like auto-migration are not as pertinent to me. Any actual migration will be a long, drawn out process that will need a steward. It will need maintenance and it will need downtime and coordination, and it will need to be seen through and It Will Be a Lot Of Work No Matter What You Might Think Right Now. Rushing it is a recipie for making your life infinitely more miserable when you overlook something. If we didn’t have auto migration tools, we’d write them – but that’s just an overall part of the process. It’s not 90% of the work. Any “Let’s hit auto-import on Friday and come back Monday to the New Office” strategy is doomed to disaster.
Anyway, I’m not saying we should move to Phabricator, or !GitLab, or anything else. But if we’re going to take this as a serious concern, we should not just hastily move to a system that doesn’t even solve problems we actually face, based on one that’s basically not even a done-deal yet.
I’d be disappointed if we missed this chance to actually fix big problems, because it was rushed out of a fear we didn’t fully grasp yet.