GitHub was purchased by Microsoft

#22

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:

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

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

12 Likes

#23

Just a quick note about the issues issue: It might be worth to look at Decentralized Issue Tracking for git.

0 Likes

#24

Serverless Information Tracker and its Issue Tracking module are also interesting. Both of these seem to be in alpha.

0 Likes

#25

Well said. I see this mainly as an opportunity for discussion than a thing that we need to do straight away.

Phabricator looks quite compelling and is being used by the GHC team quite successfully I think. I like that it’s not just a github clone but that they actually thought about ways to improve the workflow. Obviously the biggest downside is that it makes contributions more difficult. Sending change requests is a much more involved process where you need to install a CLI, configure it and go through a number of steps that are not familiar to GitHub users.

1 Like

#26

Yes, number of projects and companies had switched to Phabricator. That was a wave 7-5 years ago.
I had not heard any major community switching there in a recent time.

And meanwhile, Phabricator development (https://www.openhub.net/p/phabricator) is dead.
And those projects migrated to Phabricator locked to that platform.

It can be not an argument, if the Phabricator is fully ideal already for us, and if community wants to live and only use currently available features. Or learn and program PHP.

Now everyone going to GitLab: GNOME, Free Desktop, Xorg, Mesa from the top of my head.

GitLab would only get much more evolution oomph: https://www.openhub.net/p/GitLab

Facebook made a dump of Phabricator and left it pretty much at that.

GitLab is a main product of the company named GitLab. They make a living from developing and supporting it.

0 Likes

#27

The thing about GitLab is, that they’ve also taken lots (about $45.5 million) of investor money, and therefore are looking for a similar exit as GitHub, either a highly valued IPO, or being acquired by some bigger player.

So to me it seems just a matter of time until there’s the next mass exodus because they get bought.

0 Likes

#28

Hi,

Please notice: I’m replying via mailinglist mode. I’m currently on a
sabatical and mostly “off the grid”, so I was not able to read the
whole thread just yet, and have no time to do so right now.

This mail/reply was typed in the last few days. I just noticed there’s
a thread here, so I won’t send this to the ML but post it here.

Please keep that in mind when reading this.

— snip —

I just read that github was aquired by Microsoft. Let us move the
organization to a gitlab instance or a gitolite setup we can control
now!

Microsoft is a company that removes freedom and locks in users. We are
already rather locked in with github, but now it will get worse,
mark my words!

Lets move now, before it is too late!

And while we’re at it, we could move to a proper workflow as well, not
a “everybody pushes to master”-workflow but something which acutally
scales!

I suggested it before and I do it again here: Let’s migrate to a
kernel-workflow with mailinglist and gitolite! The workflow as way
more scaleable, responsibilities can be organized and development can
be way faster, as commits to master (which can break the build,
potentially) are not possible anymore (if done right).

Just to back-up my statement from above: I wrote the following
paragraph in a blog post I’m about to publish in a few days (or weeks,
don’t know):

0 Likes

#29

Hi,

I’m co-author of git-dit, just for context.

Serverless Information Tracker and its Issue Tracking module are also interesting. Both of these seem to be in alpha.

The difference between git-dit and sit is (as far as I can tell) that
sit wants to commit things as files into your repository, while
git-dit does not do that at all. git-dit gives you the opportunity to
have several issue repositories, leave issues outside of the code
repository, etc etc.

git-dit is not in alpha, IMO. I’m planning on converting my personal
project imag to it, actually
(see: https://imag-pim.org/blog/2018/06/10/off-of-github/).
But I don’t know how it scales for a community as big as nixpkgs, TBH.

Either way, git-dit might lack some features and “conveniences” for
“normal” users. For example, there’s only an experimental web viewer
right now.

Overall: I wouldn’t vote for git-dit. From reading this thread, I
would vote for phabricator if it would come to a vote. Something that
is actually proven to be working for huge workloads.

Still: Thank you for mentioning git-dit, aszlig!

0 Likes

#30

My email-workflow with discourse has still to improve. Here’s the rest
of my mail. Sorry for the hassle!

[…]

Just to back-up my statement from above: I wrote the following
paragraph in a blog post I’m about to publish in a few days (or weeks,
don’t know):

In fact, in the last year (as of d72710880c915ad9cb08eae2709433bbf6614b39,
[…]), the nixpkgs repository had 56971 non-merge patches to master and 46082
merge-commits on master […].
That is 55% of the commits that landed on master could have broken the build.
What a hell!

0 Likes

#31

@manveru Hello, nice to see you.

TL;DR

  1. GitLab CE is MIT license. https://gitlab.com/gitlab-org/gitlab-ce/blob/master/LICENSE

End of the point

0 Likes

#32

General argument in general Free Software case:

  1. Here is a strong counter argument. If Free Software product happens to be developed by a company, it does not matter. Free Software has hands-off approach to code usage, development and ownership. In GPL, if you fork - the only restriction - you need to send all patches upstream all the time. Otherwise - they do not have any other power over fork.

The list of cool Free Software projects developed by companies we do use. From the top of my head:

Ubuntu. Canonical largely sponsored in part by Shuttleworth income, heavily company goes IPO on next year.

CentOS (Red Hat Enterprise), OpenShift, oVirt, Kernel development, Ansible. Red Hat is a company.
SaltStack - SaltStack.

Docker, Moby, Swarm. Docker is a company.

Bacula. Privately owned.

OwnCloud, NextCloud (GmbH) are companies.

OpenVZ - Parallels(/Virtuozzo). Also largely influenced Ruby on Rails.

K8S, algorithms, TensorFlow, VP8, VP9… Google
AV1 - multi-company effort.
OPUS - multi-company effort.

WebKit, Chromium, Firefox, Brave browser.

GitLab - GitLab.
ZSTD, Phabricator - Facebook.
BTRFS - multi-company effort.
ZFS, Java - former Sun Microsystems.

Electron, Atom - former GitHub.
VsCode, TypeScript, .Net - Microsoft.
Nginx - Nginx.

So that company develops Free Sofware does not matter much for Free Sofware. Maybe there is some business insight understanding I am not aware of.

GitLab CE is MIT license.
So no-one has a reason to run, even if Alphabet, Microsoft, Amazon, Apple, Oracle, IBM, NSA, CIA, FSB, North Korea and collaborative Freemasonry holding acquires GitLab.

That is why Free Software is so cool.

  1. If Microsoft tomorrow decides to brake/close API for export of projects in closed-source GitHub - no one can do anything about it. And it is lock-in.

GitLab CE code is owned by people, if the company does something - you always can rebase to any commit in current history. And since many have self-hosted versions, and since code is open - GitLab can not do that due to the laws, branding, prestige and self-preservation.

0 Likes

#33

Phabricator is not managed by Facebook. It is owned by Phacility and still actively developed.

0 Likes

#34

To address an underlying current in this thread, I don’t think that it’s necessary to be anxious about the future. There are a lot of git hosting and issue tracking options available. The reason we chose GitHub is because that is where most of the developers are. If that changes then we’ll move.

We might lose some data in the process and that’s not necessarily a bad thing. All those open issues for example are just signals that brought us where we are now. Most of them could be lost and it wouldn’t make a difference. It could even be a trigger to re-visit some of the long-standing issues with a fresh point of view.

2 Likes

#35

Most of them could be lost and it wouldn’t make a difference.

Right, let’s also create a new nixpkgs distro and start completely from scratch, it wouldn’t make a difference.

If you don’t read nixpkgs issues doesn’t mean there’s nothing of value there.

1 Like

#36

“most” is probably not the right qualifier. There are some sarcastic messages that I would certainly not miss :slight_smile:

0 Likes

#37

I use Gitlab for all my personal stuff. With that said, I prefer that nixpkgs stick with Github for now because…

Github is good for the visibility and community growth of the project - it has that whole network effect happening.

Also, it seems worthwhile to wait and see how Microsoft handles Github. They might open-source it. Regardless, their development speed is likely to be fast and they’re probably going to be working extra hard to convince everyone to stick around. I expect that they will implement https://github.com/isaacs/github/issues/6 snd start plucking off some of the top requests.

I’m most interested in seeing nixpkgs grow and improve as quickly as possible. Once world domination is secure, nix can host wherever and it won’t matter.

2 Likes

#38

Hi,

I’ve been using Nixos as my main desktop for a little while, lurking around the different places where nix* is being discussed. I didn’t participate much in discussions as I don’t feel like a power user but i’ll try to bring something at the table this time.
I’m not interested in deciding what is the best tool, and I don’t think the GitHub/Microsoft stuff is really the question here but there has been quite a few topics/issues popping on github/nix-devel/here about leaving github during the past year at least. It seems to often end like this = there are pros and cons, obviously, very long replies but no real answers. I think this is mainly because the questions are not really defined so I made a little sketch here: https://sketchboard.me/pA5uWdMSPyiO#/
I might help or not, I don’t know. But anyway, these threads are always full of information, clarifying a little might not hurt. Feel free to edit, it’s not even objective or complete. (I tried to add what I’ve read around but there is a lot missing) I think it’s collaborative.

If of any interest, my personal opinion is that contributing and the overall “newbie” experience in the community could be improved. And from what i’ve read it’s not that easy on the other end either. I feel like project wide (in opposition to features) decisions seem to be complicated. So maybe we need tools (in opposition to people). Moving away from github might be too much of a hassle, but there are halfway solutions, I think.
I don’t know anything about it but reading about phabricator, I liked:

  • It can host a git repository or just link to github one (for the task management features). It allows to be flexible and even do a 2-step switch or just test some stuff.

  • The vote feature might be a nice way, if not to make decisions, to get the way people feel about stuff without expecting them to write an essay ( :wink: ). Involving a little bit more the community etc.

(Take this as a plead for the features, not phabricator itself)

Edit: Added som stuff on the sketch. Trying to gather stuff form the different threads and what people proposed. Also tried to make sense out of it but maybe i misunderstood some stuff.

Anyway,
Have a nice day,

1 Like

#39

Hi,

I think this is mainly because the questions are not really defined so
I made a little sketch here: https://sketchboard.me/pA5uWdMSPyiO#/

For me (that on NixOS I’m a still non-contributing newbie) git repos +
ml are the BEST option because an ml can be hosted by anyone and change
hoster does not change nothing more than few URLs and git is a FOSS
software anyone can grab and use, also well integrate di both Vim and
Emacs (witch already have very good MUAs integrable in a snap with
git&other SCM) and many other editors and IDEs. Also using such
solutions force users to know FOSS software instead of using and know
proprietary or semi-proprietary platforms.

It scale well since not-exactly-small project like Linux kernel use it
since many years.

– Ingmar

0 Likes