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)
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.
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.
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?
