Github, accounts, and ease of contribution

March 23, 2016

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)

 

23 Responses to “Github, accounts, and ease of contribution”

  1. jononor Says:

    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.

  2. Mark Wielaard Says:

    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.

      • wielaard Says:

        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.

  3. Debarshi Ray Says:

    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.

  4. Rajeesh Says:

    Is gitlab an option? It has all the pros of github sans the cons.

    • sils1297 Says:

      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.

      • Simon Says:

        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.


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

      • tomeuv Says:

        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.

  6. Kevin Kofler Says:

    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.

  7. someone Says:

    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.


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

  9. knocte Says:

    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.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: