Unable to attract as many contributors? The cold reality is that most open source projects aren't really TRYING to attract contributors. Small-time hobbyists often don't want to play with others in their personal project sandboxes, and big-time projects with high profile usually put up high barriers to contribution.

Unable to attract as many end-users, or as much public mindshare? Now this makes more sense. Many of the high-profile moves to GitHub are really about P.R., and signaling friendless to the developer community (e.g. Microsoft's recent image re-branding efforts). Not having a GitHub presence DOES make you less visible and more isolated from developers today.

Either way, I would argue that GitHub is really just a sort of Facebook or Twitter-like presence for software organizations. A way to draw attention, publicity, or mindshare from the public... but often merely a hosting mirror, and not even the primary toolset through which the software is actually developed.

This being the case, who cares if GitHub is dominant? Or SourceForge ten years ago, or whatever the next popular thing might be ten years from now? In most cases, it's effectively about as consequential as having to shift your focus from MySpace to Facebook when the audience moves.

This is an interesting expression by the grandparent. I've never heard this term before, but I've definitely felt like I've been "punished socially" in some way on the Internet by not having Facebook. The most common example are the large number of apps that I can't use because they require a Facebook account to get started. (I had an FB account in the early days when it was still edu only, but ended it a few years back)

Git being distributed means that you can host your project on as many different places as you want. And making the workflow to accept pull requests for Github, Gitlab, or other providers really isn't very difficult. They are all just remotes.

News flash: the number of people using the "D" in "DVCS" is so tiny that it might as well not be there. Central server with central authoritative repository, where all developers push and pull and synchronize, is how people use git in the real world, and it's time to stop pretending that any distributed features will ever be used.

(which is to say, if github disappeared tomorrow, everyone using it would find a way to transition to yet another central server with central authoritative repo that everyone uses)

Git doesn't do remote propagation all by itself, so if you're thinking "distributed" like DNS, then yeah of course devs don't do that. Of course we "rely" on a central repository. But if github goes down for good, we change our remotes and the migration is painless.

What else would you want? Propagation would be neat but is completely unnecessary (which is why it hasn't been done). But if the remote loses all my data, well, I and every other dev have a copy locally and we can start working from a fresh remote.

Github repositories are "authoritative" by convention. These things are a feature when you work in a team. In some of my personal projects, it's not the Github repository that's authoritative but my local repository. I really don't understand what you're trying to get at, honestly... git is popular because it covers all those use cases.

Git is about everyone having a full copy of a repo so they can go through the entire history and branch and commit freely. To actually move a project forward amongst several devs there will inevitably have to be synchronization using push/pull so there's no way to escape that.

That being said, I will agree with you that most remotes exist on personal computers and not server and we tend to be focused on more centralized servers. I think that is a remnant of the Subversion mentality and is slowly getting better.

But, the distributed features of git are alive and well. Maybe not as alive and well as we'd all like. But, alive and well.

But the whole reason why git exists at all is to support development of the Linux kernel. I don't think you can brush it off so easily.

Look here for an example of what real distributed development looks like with git: http://git.kernel.org/cgit/linux/kernel/git/next/linux-next....

The problem with Sourceforge is that we now have a thousand unmaintained projects only available there as an archive and are risking to lose them if we're not careful. It seems easier to build a github-to-new_thing service as long as github cooperates (web api throttling).

If git is to be the dominant tool, it should support a wiki, tickets, code review and more complete distribution. Kinda like Fossil++. I hope git-appraisal or at least the idea gets more popular.

I'd say there is a large amount of projects between these two extremes, and Github makes it relatively easy to get contributors "accidentally", by making it trivially easy to contribute. And a small percentage of those will probably stick around.

For small contributions (e.g. bugs due to different configuration of my system that are trivial to recognize and catch, errors in the documentation, properly describing a bug or crash I see) GitHub is really quick. With other projects, figuring out how to get post access to the bug tracker and how to check that the bug hasn't been reported yet, or reading up on where and how to submit code changes probably takes more time then dealing with the issue itself, and I'm not going to bother.

Not saying that other places can't be similarly quick (I'd say Bitbucket and GitLab probably are), but many projects hosted on their own infrastructure are worse about that.

> This being the case, who cares if GitHub is dominant? Or SourceForge, or whatever the next popular thing might be.

For one, I do, and for two - why was sourceforge changing their business model to shady predation a problem? It was not because they were a website on the Internet - there are millions of URLs of clickjackers or other malware you could visit and harm your computer with, but you rarely see them.

The problem was that a ton of open source software had mindshare on sourceforge, that remains a problem to this day, and it took years to move most projects away from that hostile environment. Plenty of very useful free software remains hosted on sourceforge, and there are plenty of reasons - developer inertia, community loss from switching, legacy systems in place that aren't portable, lack of interest in learning new tools, and many more - but the reasons matter less than the result - that we have thousands of projects staying on a website known to infect people with malware.

Most of that software remains as portable as anything on gitub - often even moreso, because sourceforge offered many fewer developement ecosystem features than github now does - but has no switched for whatever reason. We can go after the individual projects and heckle them until we can get them off sourceforge, but that is a ton of effort and mental energy we could have better used making good software.

Which is fundamentally why the decision between github and any open source alternative is so important. This is not a question of benevolence, or even time - Github, Inc is a private company hosting a proprietary website that has 11 million accounts and 29 million source repositories today. Any action they take can destroy either trust in the platform (why exactly do you trust a proprietary web service, again?) or its usability for whatever purpose you depend on it for, and since it is proprietary there is no recourse. You just have to repeat the sourceforge hell and somehow move off of it as a hosting platform - except you might have drunk the koolaid, and now have your issues, releases, build service, wiki, and website all bound to the github platform. If moving just the source control, release hosting, and a forum from Sourceforge was bad, trying to get away from Github would be much, much worse.

But all these migrating projects should know better. They were already betrayed once by proprietary software they depended on, but are taking familiarity and mindshare over the security to never have that happen again. At least with gitlab, when Gitlab Inc jumps the shark, you - or anyone else could spin up the lifeboat to easily and seamlessly save your community with. And that collateral alone means Gitlab Inc. is much less likely to betray you for profit.

It is not a question of if. Unless Github open sources itself, and that is impossibly unlikely considering how huge their code base must be now and how many football fields of lawyers they would need to prune their internal code, a proprietary software project must eventually act against your interests because you are not in control of it, no matter the intention of the creator.

If you are going to have to bite the transition bullet, you might as well only have to do it once. Considering the parity between github and gitlab, I have never met anyone who would literally refuse to contribute to a project because its not on github, you just miss casual eyes that are more common there because the platform has captured more userbase.

But that userbase control is so dangerous, and we should all care enough to try to correct for it when we can, if it doesn't negatively impact us much. And honestly, a project like Python would have been perfect for it - they won't see a dearth of developer interest just because they are using the second most popular source control web service out there.

Being open source doesn't mean that won't happen. A lot of open source projects have acted against their users' best interests. A good example is Firefox with the whole "Pocket integration" controversy. Another example is Wikipedia, with its editorial policies that drove away editors. You can fork Firefox, and you can host your own Wikipedia mirror with exactly the same software setup, and in fact a lot of people have done so, but mantaining your own fork/mirror of a project on this scale is a lot of work. Unless you have unlimited free time (you don't) open source doesn't inherently remedy the issue that other people will do things that you do not agree with, and that may cause problems to you.

Platform choice is ultimately an economical decision. Github has significant incentives not to "go rogue", i.e. they don't want to shoot themselves in the foot. They currently provide very significant value to the community, and are in a very comfortable position, but that could change really fast if they take the Source forge route.

While the more code that gets open sourced the merrier, I personally don't believe open sourcing Github would, at this point, bring a lot into the table, especially since gitlab is so fully featured already. Their secret sauce isn't really the software, but the service they provide.

It's not a remedy. It's just a lifeline. Some of us do take Icecat or Iceweasel. With proprietary software, you have no recourse at all. Wouldn't you prefer some safety net to none at all?

This has happened before. Gnome 2 and 3 schismed, and Gnome 3 became more user friendly and configurable to bring back its users. Libva and FFMPEG split because FFMPEG was very contributor unfriendly, and then it started merging all the libva changes so contributing to libva got your changes in everywhere. Open and Libre office forked because of Oracle changes, and now Libreoffice is pretty much the only name left in town, and is more successful for it. It happens all the time in branches and private forks and message boards before it even reaches end users.

But that is the difference between MS Office and Libreoffice. When a problem is huge to the OpenOffice community, they fork and start LibreOffice, and when its substancial enough the community overrides the original developers and takes over when terrible decisions are made. If Microsoft fucks up their office (and the early ribbon was a great example of that) you are stuck, and have no power. When the version you like goes end of life, you either sit on decaying software or forfeit your preferences because Microsoft has complete control.

If Gitlab jumped the shark, you would not be spinning up your own gitlab clone to maintain yourself - the gitlab community would fork away from Gitlab Inc and create Librelab, and mindshare would drive products to it because its a seamless transition. And that is more unlikely to happen with Gitlab in the first place because the power of the user can keep the company in check from making extremely user hostile moves like Google, Microsoft, Apple, Amazon, Facebook, etc can do with impunity because users are trapped and they hold all the keys to the castle.

> Their secret sauce isn't really the software, but the service they provide.

The services are the problem. Its the same problem with Facebook - Google+ is feature equivalent, but it was dead in the water to start and its free clones like StatusNet (albeit thats more twitter) are completely dead because they aren't just personal software, they are platforms. And platforms with mindshare and the users are insurmountable.

Its not about the wiki, or issue tracker, or pages. Those are replaceable - painfully, but doable. But replacing the community of developers is not a solvable problem, because they are already on github. You have already lost. And that gives github overwhelming and dominant power in how you conduct and host free software now, with no recourse.

Some of these replies are pivoting to talk instead about the fate of abandoned projects on SourceForge. That's a great discussion, but is a DIFFERENT discussion. The parent comment talked about consequences that reduce engagement with active projects. By definition that becomes irrelevant when the projects are inactive and long abandoned.

Anyway, nothing in this lengthy post is really all that compelling. Developers didn't shift from SourceForge to GitHub because SourceForce became shady. The timeline was the other way around, SourceForce became shady because everyone left. That initial shift happened because tastes changed, people legitimately preferred what GitHub was doing interface-wise... and once a critical mass has moved, it pulls everyone else who wants the social advantages of being in the popular destination.

If GitHub turned evil (or worse yet... "uncool"), then I just don't see the migration pain you're talking about. Pushing a git repo to a new remote is trivial. Learning a new issue tracker ticket system takes about 10 minutes (they all work basically the same), and SOMEONE will write a script to automatically migrate GitHub issues to the new thing. Wiki content? Sheesh... it's just Markdown.

The biggest risk is that you've used your GitHub URL as your exclusive web presence, rather than spending $10/yr on a real domain name. But if you've made that mistake, then you'll probably make the same mistake with ANY solution that isn't self-hosted.

By all means, host your own personal open source projects wherever you like. But telling everyone else to stop doing what everyone else is doing, on the basis of some Richard Stallman-esque principles that don't hold water, seems like a waste of time and energy.

If those pages were to disappear or if the decision was made to become less benign then the damage would be substantial and it would take many years to heal the rift.

The web never really recovered from Yahoo's bad stewardship of Geocities (untold backlinks broke, including many from Wikipedia causing those links to point to nothing which led to articles becoming unsourced, or -worse- being changed by bots to point to linkfarms instead).

If github turned evil the migration pain would make the Geocities demise look like a veritable walk in the park.

I can use GitHub as a remote and take advantage of the social and UX aspects they offer, and if GitHub vanishes (or has downtime), I can continue utilizing my git repo with all the distributed features it had before. I can (and have) continue to work while GitHub is down, I can export any of the additional data (issues, wiki, etc) that GitHub offers and store them just like I store all my backups, etc.

Centralized hosting solutions can offer value, even to distributed tools.

Where GitHub ends up conflicting with distributed workflows is when build pipelines or other systems are set up to rely on GitHub (Go dependencies, I'm looking at you). In cases like this, the user is making a choice to pin that piece of their infrastructure to a centralized service. And that's not always a bad call! If the value provided outweighs the harm done when the centralized service goes down or has other issues, it can be a good choice. It's up to the person designing their infrastructure to balance the risks and benefits, as with anything else.

Specifically speaking to GitHub's lack of incentive to invest in extending distributed git features: that seems counter to actual events. They recently worked to develop their large file storage, and rather than release a closed source / centralized system, they released an open source extension that ties in with core git (https://git-lfs.github.com/)

Yes, you can still use the basic git features, and github doesn't break them. The problem is that instead of turning Git into a Fossil++, we're relying solely on Github's tooling around git. Yes, it's easier to have a centralized location that doesn't require synchronization for tickets and reviews, but when you have to move off github, you cannot really export all the history properly without losing some details, so I firmly believe we have to make more of the git story distributed. Those features can be used by github in a friendly web interface, but like the git push and fetch model, it should exist in git itself. That way, it really won't matter where users make contributions, and it will solve the Phabricator vs github dilemma for big projects, plus allow for full archiving and porting of the data. Once your tickets and diff reviews are part of the git repository, you get features that enhance the user experience. I believe git-appraisal is using git's notes feature, and that's a good way to avoid extending the data model.

If you're arguing that open source and self-hosted alternatives get better at the UX and communal aspects that GitHub has been excelling at, I'm all for it. But lets not sell short that the reason people are flocking to GitHub is because what it offers has value, value which is worth using a hosted centralized service for them.

https://git-annex.branchable.com/

https://github.com/joeyh/github-backup

It serves no value for the project because they use a different system for version control, code review and ticketing, yet someone had to go setup a Github mirror because.... people expect to see you on Github?