GitHub monoculture

> Someone said to me, "I couldn't find coverage.py on Github." Right, because it's hosted on Bitbucket.

I was curious, so I went to bitbucket.org to try to find coverage.py. Experience was awkward to say the least:

1) Bitbucket homepage does not have a search bar, nor is there a link from the homepage to the search [1]

2) Guessing that the URL is /search puts you in the team profile for account `search`. finally you see what looks like a search bar at top [2]

3) Searching for coverage.py doesn't show `ned / coverage.py` in the first page! There are lesser-known forks of coverage.py that show up higher than the original project. [3]

I'm sure these will improve over time, but discoverability is still incredibly difficult on bitbucket.

[1] http://i.imgur.com/soRXB98.png [2] http://i.imgur.com/z5YmcL2.png [3] http://i.imgur.com/uhg8rbc.png

    pip home coverage

I go to GitHub to find a project first because that's where I hope it is. GitHub's UI and culture go a long way towards standardizing repo layout in such a way that I can more easily use it, plus if I find bugs or issues there's the Issues and Fork links right there.

In my admittedly anecdotal experience, GitHub projects are way more likely to have a clear overview with a link to a GitHub Pages site with real docs, they're more likely to define the rules/procedures for sending in contributions, and they're more likely to have an active community of contributors. I know I'm not going to have to hunt for the source link in a paragraph somewhere, because if I know the repo name and author I can clone the source.

If issue tracking could be distributed (yes I know about Fossil and others), and the players like github and bitbucket were compatible with such, then we would no longer have any dependence on any of these services.

The way I'd host my projects would be:

1. I have my own server where I have a git repo, the issues repo, and maybe a wiki repo.

2. My server would host semi-statically generated project browsers; source code browsers, issue browsers, etc. Unlike when I was running Trac, I'd have no need to allow people access to my server, no need to worry about spammers, pages would be low-latency/cachable so that I can allow crawlers as well even on a very small linode host.

3. all of my wiki/issues/git would mirror out to github, bitbucket, and whoever else wants to participate, and updates on those sites mirror back. I already do this now with my git repos using WSGI services and hooks.

4. when someone wants to post/update an issue, they link out to one of those services, or even run a local command line/GUI based issue system (wouldn't that be great??), and everything synchronizes back.

The only missing link is a decent distributed issue system everyone can get behind. Building out the glue to sync between services is not that hard of a task.

I totally agree with the author.

Worse is, when answering to the question what do you use for version control software, I hear quite often people saying "github" and not git, and not understanding the difference between the two.

Whenever Github goes down I always wish someone would invent a decentralized version control system.

Remember at work when Github goes down everyone is just sitting there twiddling their thumbs for hours. As in "yeah my commit is ready just waiting to push it" or "waiting for the issue to be close, then we can test".

It is ironic a bit isn't it. One of Git's major selling points was -- we are tired of one centralized version system, you shouldn't need a single point of failure or be tied to the network in order to develop. And then years later we have one giant global single point of failure across the world. There is some irony there.

(Yeah, yeah, I know I can commit locally. But at some point you'll need to update issues, and publish your changes. This is more a of a generalized point. It would be the same if bitbucket went down and so on. We never it seems have gotten to the mythical peer 2 peer internet of things -- it just doesn't work it seems).

One of the nice things about Github and Bitbucket is that they both use Git. You can push to both of them and enjoy the best of both worlds.

    git remote add bitbucket git@bitbucket.org:username/reponame.git
    git remote add github git@github.com:username/reponame.git

You could even add another Git repository you control fully as well.

So where it the 'apache' of Github? Presumably that would be Gitlab, but its not quite aligned with the Github experience.

One could imagine a package you install on your droplet, ec2, linode, what-have-you, which would create a 'site' for your project which included a Wiki, a user management package with role management, automated source code backup to Glacier, automated mirror management to choice of mirrors. Install, set up your various keys (aws, ssh to mirrors, etc) and then push to it your source and make it the origin master.

You make that and then people might start creating free floating git repos, except that it will cost them some small money (like $25/month) which would discourage many people.

This article captures just a little of what I've been feeling for some time.

There are a couple of other things about GitHub specifically, and the presumption in some quarters that everyone uses it, that put me off.

Firstly, they create their own world where lots of things aren't quite like normal Git. Some are simple terminology changes, like using "fork" instead of "clone". Some are more intrusive, like tying the pull request mechanism to the GitHub review tool.

Secondly, GitHub terms only let you have one unpaid account. If I want to maintain some personal repos, but also some with one of my professional hats on, it costs me money. If I want to keep my work on a major project separate to a few sidelines, it costs me money.

Thirdly, GitHub is an on-line service, and like anything else in the cloud, that means it comes with unknown security, privacy and reliability implications. For a big open source project, that might or might not be a problem, but I don't know why anyone would expect me to host my own projects there instead of, I don't know, in a Git repository on a server at home or at work, or something crazy like that.

So no, sorry, I won't fork you on GitHub. Nor will I contribute a patch via a pull request. Nor will I raise my helpful bug report on your project if you require me to submit it via GitHub. And I guess I'm lucky that I don't apply for jobs as an employee any more, because I am able to show approximately none of the best professional quality code I write without violating confidentiality agreements, and certainly none of it is in a GitHub repo for public inspection.

I am happy to support open source projects when I have a bit of time free, and I'm happy to demonstrate my credentials and abilities to prospective clients, but GitHub is a hoop that is rarely worth jumping through IME.

Mercurial is so much easier for day to day usage, I work with both and need to explain so much more when getting a new person up to speed with git. The "detached head" state is very difficult to explain.

I wouldn't mind -- strictly from a user standpoint -- if all code was in one place. It's easier to collaborate and contribute to other repositories when they're all in the same SCM and host. If someone has their source in another host (whether it's Git or some other SCM), I'm less likely to bother contributing -- and I would assume this is the case with many others.

Of course, from an "all your eggs in one basket" or business monopolization standpoint, I agree with the author.

But selfishly speaking, I like Github and find that it adds more value to me the more it becomes a monoculture.

I wrote about something similar in in 2010 because these sites are walled gardens: http://kev009.com/wp/2010/10/stop-distributed-version-contro...

I was hoping for something like Diaspora (https://joindiaspora.com/) so we could use our choice of repo or self-hosting but still interact with a global community.

Github isn't the only choice, but I think it's the preferred choice for a code sharing community because they basically give their product for free for open-source projects on public repositories. And it's easy and good looking.

Bitbucket distinguishes itself from Github by making itself free for small teams only, but allowing you free private repositories. Seems like they are more interested in businesses and proprietary code.

So BitBucket and Gitorious and others will need to excel and beat GitHub at their game. Competition will eventually solve this the same way we aren't beholden to the same methods and sites we used 10 years ago. The next winner may not even exist yet and I expect that the barriers to entry here are not nearly as high as those in other markets that have been disrupted over the last few years.

I use Bitbucket too. Github doesn't provide free private repos last time I checked, needed for bootstrapped startup. The centralization vs. distribution+independent evolution debate is always an interesting one, though. I think you need high quality centralization at first then competition can be useful; Github set the bar, now lets see what everybody else can bring to the table

I would love it if Github built in a contributors license agreement into my repos so all issues and wiki content were licensed to the repo owner. This would give repo owners the ability to move from one version control service to another without getting locked in by copyright issues on issues and comments made by others.

This is a non-issue and I don't mean that in a small way.

Github has produced a near monopoly on hosting for popular open source projects because it is so liked (as OP himself admits). Soon enough something better will come along that makes Github look like SourceForge and then we will all migrate our projects over there.

Finding out a project is on Bitbucket or uses Mercurial has actually stopped me wanting to contribute. The additional hassle of remembering how Mercurial works, digging out my BitBucket credentials etc, is a pain in the backside.

I don't see why this is a bad thing.

There is inherently less cognitive overhead to use something you are already familiar with. Same reason why people wouldn't give Bing the time of day.

All things being equal, and you just had to choose a public place for a remote repo, Github should be your first choice unless you have a very good reason go use something else.

I'd rather not, nor expect consumers of my code, to have to learn a completely different UI than what they are used to in order to use or contribute to my public repo.

I recently started a storing a new project and its services on Bitbucket for a variety of reasons.

- I think it's healthy to always look at the different tools in the space to witness first hand if you're missing out on something

- There's some product integration in the works, so, it only makes sense to get curious about how existing users of the platform may feel once it is there.

So far it's going well, but it's early days.

It's interesting to see the progression of public source control hosting. SourceForge was the goto place for many years, but it's really only used for hosting large binaries at this point, and very few people host code there. Google Code started to steal some people away from SF, but again it was more focused on project hosting then just getting code to people.

Github is interesting is that the code is shown front-and-center whenever you visit a project page. Sure there is the Readme.md and wiki stuff you can do, but it makes browsing code and project discovery very easy. Github also made project creation and management super easy and lightweight. The number of questions you need to answer to setup a repo is so minimal. It gets out of your way when setting up a project.

I still feel like Google Code has some things going for it. The biggest being it's defect tracker compared to Github.

This basically reduces to two questions:

a) is github monoculture is bad?

I really disagree with author's view on the emphasize on public github project in job interview process is misplaced. Yes, it will not eval how good you are at your previous job, but the problem is it is very very hard to find how good you are at previous job. Doing open source project at spare time is a positive sign of interest in programming. If in the interview process you said I don't have a github account, but I put all my repo at abc.com, I am pretty sure it will work, too.

And I don't care the monoculture if its service is the best in this field. Why use the second best if the best is possble? I would like to be an earlier adoptor if there are better service, even if there are currently no user.

b) how to disrupt github?

That I have no idea. What github does not provide but is really needed? I do not know. Would love to hear ideas.

The one thing GitHub excels at where everyone else doesn't even come close is as a place to read the code. Big bucket, unfortunately, doesn't even come close in code reading.

GitHub is the only place where you can easily read, search, and immediately get the commit history for a file in one place extremely quickly.

Oddly what seems to have sparked this blog was someone failing to find Ned's own "coverage.py" on githubs search. Ned's response was interesting - there is clearly a monoculture - they should have searched on google.

my first though was - but Ned is caught in the far more worrying search monoculture.

And my second thought was the other monocultures to fear more - antibiotics, wheat and soya...

In the end, contributing to someone else's code is hard - it requires not merely coding skills but agreements on standards, willingness to compromise, and willingness never to do so, it requires humility and determination. Anything that makes that easier I welcome - I suspect githubs biggest issue is not having people start repos, it's having > 1 person work in the same repo.

They can solve that, more than happy to live with that monoculture

>they should be a choice, not the only choice.

They are a choice. The author even mentioned Bitbucket. The fact that Github has become the dominant player doesn't make it not a choice. There is no one preventing a competitor from emerging and working to compete with Github (the same way Git emerged and enabled Github to exist in the first place). Being frustrated that people default to Github doesn't mean the choice to use something else doesn't exist. It does, most people have just decided not to.

Most people can't be bothered to choose a domain, set up a web and e-mail servers for it (because if you're doing it, you gotta do it right) and then maintain it all. Even though it's on almost everyone's todo list, I'm sure.

Setting up a GitHub profile and posting a few quips on Twitter is almost effortless. So that's what we use. If someone comes a long and makes a competing product that is just as easy to use, people will switch. It won't be much of a problem.

I feel the same about the rise of Macbooks in the dev community. A proprietary platform becoming a standard and excluding people having different use-cases.

This is not a social problem, talking about it like one is just going to end in tears.

This is a technical problem.

There is no way to efficiently look for code across the various repository sites. Too often a search on google turns up nothing, while searching on github (or pypi or another repository of software libraries) finds exactly what you are looking for.

Until there is an effective way to search for code, people will be left no other choice than to search on a few sites (github is by far the largest, so most people will check there, and some may not check anywhere else!).

To the author: if this bothers you, fix it, but don't act like it's a behavioral issue. (Also, bitbucket has been dead for like 5 years, it's a backwater and it's not going to come back.)

Maybe all the other places to host code should just do their job better. Ever think of that?

There are a plethora of choices, and you can always use Google to find projects. However, it happens to be that GitHub is the best choice, it's a free choice, and there's really no reason NOT to use it other than some stupid prejudice that putting all your code in one place is a bad idea.

Keep backups, and of course make sure GitHub isn't the only place your code exists (since you're using Git, that's not the case). and I don't really see a problem here.

"The D in GitHub stands for Distributed"

It is a valid point of view and the same argument can be used to many other websites and services across the web.

I actually much prefer Unfuddle to GitHub, but everyone is on GitHub, so I use GitHub.

"we are asked to provide a Github username and a Twitter handle. I suggested that a homepage URL is a more powerful and flexible way for authors to invite the curious to learn more about them"

Your website demonstrates who you say you are. Github work demonstrates who you actually are.

I was hoping this had to do with monocles