Comment by beshrkayali
10 years ago
I do like Github, and I understand how it makes the entire process of maintaining a code repo a lot easier, but what I'd genuinely like to know is why don't big projects just move to their own thing? I understand that there isn't a single solution that exactly matches what Github has, and that maintaining your own git server + git management/issues/etc.. app is a pain, but I see it as the only real solution. Developing in the open can't be done on platforms where restrictions apply, and they do apply. I'm saying this with no intention of sounding like a jerk, but 18 project maintainers and/or developer need to write an open letter to get Github to give'em a "me too" button? I understand the issue, but i still find it rather silly.
The only aspect I could think of where Github has the pro is the community of developers it has, but does it really matter that much? Especially for established/big projects that probably don't care about the fork/stars numbers, or the random look around-ers that pass by.
> I understand that there isn't a single solution that exactly matches what Github has, and that maintaining your own git server + git management/issues/etc.. app is a pain
You outlined exactly why people don't build their own or use another system. Github is the best there is. That doesn't mean it doesn't have problems, but if your company/project/expertise isn't focused in collaborative development and/or version control, you're just distracting yourself by building your own.
The authors are not saying "we can build a better Github." They have complaints and would like them resolved, but don't see a good way of having that happen.
> Github is the best there is.
Doesn't matter really as it's still a locked platform. The argument they're making is that they're developing in the open and they'd like some sort of expedited treatment because of the size of the project or because they're doing OSS. I don't think those two can go hand in hand all the way.
The most important thing is not even that GitHub is the best but that everybody is used to GitHub.
The point about GitHub today is that being "the best there is" is as irrelevant to its continued success as "being the best microblogging service there is" is to Twitter's.
Open Source projects move to GitHub because their users are all already familiar with GitHub from all the other open source projects that use it. That means those people already have a user account, know how to check out your code, are able to file issues, and can probably make contributions even if they're not very familiar with git, for example using one of the GitHub integrated GUIs that will handhold you through making a PR. If you are an odd-duck project using some other infrastructure you don't have any of these advantages, and the barrier to entry for potential contributors is correspondingly larger.
For users having a near-monoculture of source code hosting has all the same advantages but reversed; it means they only need a single account, and that every process they learn — all of which are well documented across the web — is fully transferable between projects. It also gives them a recognised place to show off their own code, and increasingly people are asking for a link to a GitHub profile as part of a hiring process. This even happens at Mozilla, an organisation that doesn't actually use GitHub for its most prominent projects (but increasingly does for new things; the advantages I mention here are valuable even when you already have everything set up for using something else).
Another benefit enjoyed by projects that use GitHub is the plethora of tools designed to integrate with it; again little to do with the intrinsic merits of the tool and everything to do with network effects (although I will allow that the API is generally very good). So if you chose an alternative to GitHub you might miss out on IDE integration, Travis, landscape.io, reviewable.io, or any number of other third party tools that either exclusively work with GitHub or have smoother integration in the case of such a well-worn path.
Tools like reviewable.io are interesting because they are clearly making up for deficiencies in the GitHub platform itself. In that case it's the totally, utterly, useless code review functionality in stock GitHub. And there are many other things in the site that could stand to be improved. For example the notification system that either spams you with every comment from a repo or ensures that you miss anything you don't check via the web UI. The permissions system that makes it impossible to add commits to a PR against your own repository without losing all the metadata associated with the PR. The issue tracker that doesn't allow assigning issues to anyone other than a project admin. But, from a business point of view, none of these things matter because GitHub isn't popular for being the best. It's popular for having been good enough for long enough to become ubiquitous, and now not being so bad as to negate the enormous network effects.
So the core of the problem here is not whether or not the authors, or anyone else, can build a better GitHub. The problem is that even if they could it would have to be wildly, dramatically, better to even provide competition. And so people, without meaningful leverage, resort to writing open letters and hoping that they can drum up enough noise that someone at GitHub chooses to care.
>but what I'd genuinely like to know is why don't big projects just move to their own thing?
Github is a great advertising and marketing platform for large OSS projects. Quite the opposite, large projects should be moving towards github, because it's a great stage for them to perform on. On top of that, it's rather become the defacto replacement for sourceforge (sorry FOSShub, it was a bold try), with all that implies.
The thing I really don't get is why people use it for small projects. Like Facebook, Twitter and basically every other social media site out there, it's a drama factory. It incentivises people towards public grandstanding on creative and technical issues, and encourages resolving disputes by forking the repo, burning bridges and splitting the dev team rather than discussing all aspects of the problem, chewing it over and making a group decision.
That's the last thing small OSS projects need, and I'd have thought most 5-15 man projects would be vastly better off throwing up a kallithea repo (if they don't just use DCVS the real way) and a dokuwiki and then knuckling down to business. I acknowledge that this reduces discoverability by some amount and thus risks taking a hit to your developer acquisition, but I'd love to see some hard numbers on how much. I'd wager that much like the Apple app store, if you're not in the top 50 on github, you're no one.
But hey, I'm apparently an old fogey born young, and I prefer to self-host when I can, so maybe I'm just pointlessly resisting the tide of the inevitable or something.
@Sir_Substance - thank you for the kind mention. I agree with you but don't forget that any Empire will fall sooner or later. People work with enthusiasm at a new project, after a while this new excitement is replaced by greed because the financial thing becomes the most important aspect. At this stage I would say that GitHub is Google, SourceForge is Yahoo and FossHub aims to become DuckDuckGo. We need to improve so instead of throwing us at garbage we would appreciate a constructive criticism. Thank you!
The reason why I thought bigger projects would be more capable of handling this is because team size = more manpower obviously.
> Quite the opposite, large projects should be moving towards github, because it's a great stage for them to perform on. On top of that, it's rather become the defacto replacement for sourceforge.
Not exactly sure what they're supposed to perform better/easier on a shared-hosting locked-in platform. If it's the issue of getting people excited about the project to want to use it or join in and help, it'd be interesting to see if there are any numbers to back this up.
I'm not sure about sourceforge but i never thought of it as a serious thing for big project hosting before github came around.
> It incentivises people towards public grandstanding on creative and technical issues, and encourages resolving disputes by forking the repo, burning bridges and splitting the dev team rather than discussing all aspects of the problem, chewing it over and making a group decision.
Totally. This is a good point I think. I never understood the fascination with obsessive forking (edit: lol, after the letter moved to github it got 2 forks! WHY! https://github.com/dear-github/dear-github) just to apply a patch or change a line of code (there's a lot of those). It's a nice feature and all, but not really that useful imo. I'd like to see some data on forks that haven't been touched as well, amounting to garbage, outdated code basically.
> ... throwing up a kallithea repo (if they don't just use DCVS the real way) and a dokuwiki and then knuckling down to business...
The thing that bugs me the most about Github and the likes is this. It's slowly taking away the will or need to do this. Same as how the use of Slack/Gitter has somewhat eclipsed IRC in OSS world. From my experience, I learn a lot when I'm doing things I don't really want to do or I find tedious because I either discover that there's a detail that I don't understand well or it motivated me to write an automator to sort things out.
> so maybe I'm just pointlessly resisting the tide of the inevitable or something.
Wait until the fixation on cloud crap washes off and everything will be back to normal lol.
>Not exactly sure what they're supposed to perform better/easier on a shared-hosting locked-in platform.
To be clear, I meant perform as in "tap dance routine" and was being metaphorical.
A large project on github gets more exposure than a large project not on github, because it regularly shows up in the "explore" section of the site. A small project on github gets no more exposure than a small project not on github, because it does not.
(I have no citation for this, it's based on my observations only)
It's a momentum thing I think. A big part of the Github platform mirrors a social media platform. When you meet a developer, you check out what they're up to on Github just like you might check on a friend's status on Facebook. Like Twitter, it's a way to get your name out there.
Also, I don't want to have to maintain an account on a Gitlab (or equivalent) server for every project. Anyone who has enough interest to troll through issues on a project or open an issue already has a Github account. It lowers the barrier to entry for your project.
The final thing is just name recognition. People trust code from Github. They shouldnt, but a Github URL legitimizes your project more than git.abrakadoodle.io.
> Also, I don't want to have to maintain an account on a Gitlab (or equivalent) server for every project. Anyone who has enough interest to troll through issues on a project or open an issue already has a Github account. It lowers the barrier to entry for your project.
There are multiple ways to go around this, OpenID, Mozilla Persona, or any third-party authenticator.
> The final thing is just name recognition. People trust code from Github. They shouldnt, but a Github URL legitimizes your project more than git.abrakadoodle.io.
I see this more of an additional reason for big projects to move away from Github. It gives unwarranted legitimacy to everything on the platform.
I just realized that Persona is going to be discontinued. Unfortunate, but alternatives can be whipped up I guess.
https://developer.mozilla.org/en-US/Persona
> On November 30th, 2016, Mozilla will shut down the persona.org services. Persona.org and related domains will be taken offline.
2 replies →
Along the same line of thought: there's a lot of momentum regarding tooling surrounding GitHub. Continuous integration works smoothly. Slack works smoothly. github/hub and ghi let you interact with the issues and repos from the command line. Vim, Emacs, Atom, and Sublime plugins exist to integrate with GitHub. While moving to another hosting platform might fix some things, there is a lot of solid tooling built around GitHub.