At the moment we’re making plans to move OSTree to Github (from GNOME), and while there are a few reasons for this, one thing I want to talk about is the “account problem” and specifically how it relates to free and open source software.
The “account problem” is simply that requiring users to create them is a barrier to contribution. It’s problematic to require people to have a Sourceforge account, a GNOME account, a Github account, an Apache Bugzilla account, a Fedora/CentOS account, etc. People who are committed to making a larger contribution can obviously easily overcome this, but for smaller contributions it hurts.
Particularly for projects like GNOME that have distinct accounts for bugzilla and commit. Having to create an account just to file a bug is bad. Yes, there’s OpenID, but still.
I’ll note at this point that software freedom is quite important to me, and the fact that Github is proprietary software is a problem. But – making it easy for people to contribute to Free Software is also a major benefit.
I wonder how things would have turned out if Sourceforge had been…well, let’s say “less crappy”. Anyways, now we have Github.
And when we move OSTree, I’d like to avoid becoming too dependent on it. Particularly for things that aren’t actually git, like the issue tracker. Hopefully if GNOME doesn’t disagree, we’ll maintain our mailing list and bugzilla there so that people who prefer that can use it.
But allowing people to create Github PRs easily is really critical in my mind. (On this topic, we are also planning to use the Homu bot, which I really like)
Colin Walters 
It is important to note that basically all contributors start in the small*. If barriers are too high initially, they may never become contributers at all, let alone contributing something big down the line..
* a somewhat common counter-example is perhaps when someone gets hired to work on a particular project.
Could you explain a bit more the reasons you see that make it necessary to migrate to a proprietary platform? You mention the account problem. But I don’t see a solution.
Requiring contributors to create yet a new account on a proprietary platform like github seems part of the problem (especially because you’ll lose contributors that won’t create accounts on such proprietary platforms). How do you see such a move as a solution?
I never used github PRs. Do they support an open protocol to create and consume them? Do you need to create an account at github to use them? Could you explain what qualities they have that cannot easily be mimicked on a free platform like the gnome infrastructure?
Thanks,
Mark
I’d still support people sending `git format-patch` emails to the list as well as filing bugs in the GNOME Bugzilla. So github isn’t *required*. That’s been in `CONTRIBUTING.md` from the start.
It’s more about *also* accepting PRs, and the majority of current maintainers like the workflow (over email/bugzilla).
I’m sure someone could improve GNOME Bugzilla, but honestly as far as FOSS goes, Gerrit is quite good. But again it’s not about the tools quite so much as it is about accepting PRs too.
But what is it about PRs workflow that makes it good or better? I looked at the github website PRs for some projects but found it mostly confusing. That probably just means I don’t understand the ideal workflow for them. I used to think gerrit was a pain, until I learned that you can do everything from the git command line and it was just an easier way of sharing working branches.
So PRs support an open protocol to create and consume them? Do you need to create an account at github to use them? Could you explain what qualities they have that cannot easily be mimicked on a free platform like the gnome infrastructure?
Gerrit is in many ways I think better than Github PRs – in particular its “interdiff” support is awesome.
But the point of this post was that it’s about *accounts* and the network effect – new contributors will tend to know how PRs work because it’s very likely one has contributed to a project on github before.
PRs are just sort of okay. Better than patches in Bugzilla for a patch series for sure. I am definitely happy enough with the combination of PRs + Homu.
I’ve wanted to contribute things to GNOME in the past, but as I have a full time job and already maintain open source software of my own I do not have the time to do the work and then figure out the correct process to submit it.
By allowing Github contributions you’re allowing us the chance to enter the community in a way that we are already familiar with.
To be very clear this is one project, and is not representative of any other project currently maintained in GNOME git.
I think Fedora and GNOME are sufficiently large umbrella projects that the trouble of getting an account does pay off a bit. Or you could say that I am not comfortable letting GitHub become the gatekeepers for an overwhelmingly large number of free software projects out there.
Secondly, one doesn’t really need a git.gnome.org account to start contributing. 🙂 One needs a bugzilla.gnome.org, which is easier to create. You only need a git.gnome.org account if you decide to make further contributions. In that sense there is still a slope to climb in order to contribute, but it is gradual.
Thirdly, for a good number of modules that are hosted on GNOME infrastructure, I think, getting started with jhbuild and everything is a far bigger obstacle than anything else. Hopefully this will soon change for the better. 🙂
For 10,000 open source repos you need one Github account but for 5 open source projects not hosted on Github you probably end up with 15 accounts.
However you try to frame Github it does solves a problem.
Not to mention Fedora, KDE, ownCloud, etc. will all have different ways to work with same bugzilla which also creates a hassle for small contributions.
Also as someone in Job market, employers can easily look up my open source contribution just by looking at my Github profile. They will never check or will have any idea how to check my contribution in KDE.
How to check non-GitHub contributions? Easy. Use Open Hub.
Is gitlab an option? It has all the pros of github sans the cons.
I really think you should consider GitLab
– there is a free software version.
– It’s simple to use as well.
– GitLab doesn’t enforce a specific workflow on you (with proper CI validation you’ll get a project with more merge commits than actual ones in GitHub)
– lots of really cool stuff coming every month
I have started a project which has nowadays quite a number of contributors on GitHub and I wish I would have started it on GitLab.
You will get locked in anyway due to the use of CI services, there’s no way around this if you want to properly automate your workflow.
You miss the point – GitLab isn’t an acceptable substitute, because it’s not GitHub. This isn’t about how good the tools are – it’s about using the tools which developers are already using.
For all its faults, GitHub is *extremely* popular among open-source developers – it certainly has far more users than Gnome does. This is about making Gnome more accessible to those developers.
One major plus for gitlab – it has an easy “sign in with Github” button.
It is kinda sad to see so many major F/OSS things move to a proprietary platform. There are plenty of F/OSS options that provide a pull request-style workflow; there’s Pagure and Phabricator, for instance (we use Phab for Fedora QA, I rather prefer its PR workflow to github’s because it doesn’t require you to juggle two remotes and force push things all the time).
See the discussion to Mark above – it’s *primarily* about the account issue (hence the title of the post), with “workflow familiarity” following that.
So having another project that clones the PR model but requires a non-Github account isn’t quite a solution.
I haven’t really looked into the details, but I’m pretty sure several of the F/OSS options have pretty flexible auth and could be configured to allow auth with one of the big evil closed identity brokers (Google, Facebook, github, whoever) if that’s what you want. All this auth stuff is pretty standard-y lately.
Regarding accounts, by using phabricator prospective contributors can not only reuse the GitHub account they may already have, but also a bunch of other authentication systems. See the ones that fdo’s support: https://phabricator.freedesktop.org/auth/start
Nice! I haven’t used phabricator enough to form an opinion on it, but it indeed does seem to have the “use external account” problem solved nicely.
By helping spread the GitHub virus, you become part of the problem, not the solution. I find it totally unacceptable that projects are migrating away from perfectly-fine established Free Software community project hosts such as freedesktop.org, KDE or GNOME to the proprietary GitHub monoculture.
I don’t have a github account and I don’t want to have to create yet another account!
How about switching to systems that don’t require accounts to work? debbugs for issues, git-remote-ipfs for git.
I agree with Colin here about the accounts problem, but I agree also with the people concerned about the decision.
The way to fix this problem and make everyone happy is not to switch to github, it’s to:
a) Fix bugzilla so that it can be logged-in with GoogleID/Twitter/Github
b) Have a Github mirror of OSTree in github, but still git.gnome.org be the official. People would be able to create PRs against the mirror, and a bot should convert them to patches in Bugzilla.
End of story.
I agree with Colin here about the accounts problem, but I agree also with the people concerned about the decision.
The way to fix this problem and make everyone happy is not to switch to github, it’s to:
a) Fix bugzilla so that it can be logged-in with GoogleID/Twitter/Github
b) Have a Github mirror of OSTree in github, but still git.gnome.org be the official. People would be able to create PRs against the mirror, and a bot should convert them to patches in Bugzilla.
End of story.
I’m willing to respect the hosting platform choice of the people who work on a project, even if I personally think using GitHub for FLOSS projects is a bit hypocritical. So I’ve tried creating a GitHub account once, to make my contribution as frictionless as possible to accept. IIRC the Terms of Service were about 24 screenfuls, Privacy Policy 14 screenfuls on the laptop I was using at the time. I quickly decided I’d better spend my time on the actual contributions, not on the legalese. I wonder what part of the GitHub fans actually analysed the agreement they enter. I can’t say there’s anything egregious in it as I quickly bailed out, but I don’t accept on-line agreements light-heartedly just as I don’t place my written signature anywhere. So I find it absurd that I have to enter into an agreement with a commercial third party entity to make a contribution to an open source project. And many people advocate this as the best way to collaborate on open source. Baffling.
I’m not a fan of having many accounts (OpenID isn’t as popular as I would like), but I’m willing to create multiple accounts for the systems hosted by the open source projects, where I don’t have to waste time on analysing legal documents and accept terms that don’t necessarily spark my enthusiasm.
Luckily, GitHub doesn’t prevent most of my contributions. When a piece of software hosted on GitHub is packaged for Debian – opening a bug report there is my first choice. Otherwise, I send the patch to authors by email, if possible.
GitHub is not the only way to contribute to OSTree as I understand it, so this is not a direct criticism. I’m putting my example as counterbalance – GitHub for me is an obstacle, not a convenience.