Dear-GitHub: Host Github by itself as an open source project
github.com
github.com
GitHub’s success is largely due to the network effect and it’s entrenched status as the canonical code repository.
Besides libgit2, aka “the secret sauce”, is already open source. What are you waiting for?
They’ll be running it on a raspberry pi, not hosting the Rails or NodeJS repo.
Has it really ? I remember many threads here on complaining about Github's up time
https://news.ycombinator.com/item?id=5808496
I would describe GitHub's real "secret sauce" as the issue-tracking, wikis, project boards, and release management parts, that don't get represented in the repo itself.
Which is to say, if you wanted to commoditize GitHub (which is basically what "open-sourcing your secret sauce" means), you'd have to create some sort of library that allowed you to treat a git repo + all those other things as one structured data-object. You would be able to use said library to both operate on all those pieces of data locally; and to sync them between different Git hosting services that all share those features.
Or, better yet, figure out a way to put all those features into git itself, so that every git repo automatically transports those pieces of data alongside itself.
Git already has notes, and signed commits/signed tags, which are all those same kind of "objects that just happen to be there." So they don't need to copy Fossil's architecture; they can just copy the way that said object types interact as dependents of commits (while letting them get blown away when commits themselves do.)
If Git repos just "had" wikis, issues, etc. inside them, the lock-in wouldn't be there, so people would be switching between Git hosts all the time—and there wouldn't really be much value in a "git host" at all, beyond what just having a Git dir on your own server, plus a native-GUI Git client supporting the wiki/issues/etc. features, would get you.
People clearly never cared about that, since Fossil ( https://www.fossil-scm.org/index.html/doc/trunk/www/index.wi... ) has these things and it never caught on
This is okay. It's just source control at the end of the day.
I think though that 99%+ repos or there have zero issues, pull requests etc.
It's more than that. GitLab raised the bar here. Being able to run GitLab CE internally has de-risked the decision to test internally. For the next wave of customers in the space, familiarity with GitHub open source isn't enough.
If Github was made with micro services architecture, it could be split into open source "Client side + Test-backend" and closed sourced "Production-backend". Backend can be composed of some interface and multiple implementation such as test impl and prod impl. “the secret sauce” could be the "Production-backend" and MS have good in-house talents who operates Azure so no need for the help from OSS community to improve backend.
However for example +1 button took so long time to be implemented even though it seems like small change in client side code and some adjustments in database. That itch lead to the https://github.com/dear-github/dear-github open letter and signers listed here: https://docs.google.com/spreadsheets/d/1oGsg02jS-PnlIMJ3OlWI...
The last sentence of the open letter says: "Hopefully none of these are a surprise to you as we’ve told you them before. We’ve waited years now for progress on any of them. If GitHub were open source itself, we would be implementing these things ourselves as a community—we’re very good at that!"
I think that's OSS community want, including but not only I want.
I think you're drastically underestimating the amount of code Github is powered by and how freaking long any type of refactor/rewrite would take. We're talking about years.
Does anyone have link to any interview or article talking about granularity of their architecture?
It's talking about a component of Github backend called Resque (Distrubuted Job Queue)
As long as I see these thing the architecture is highly distributed and it's possibly composed of micro services.
I've been through a number of large rewrites/reworks that took monoliths much like Github (with many many many services behind it) and split them up into modular pieces and it's an insane amount of work that can take years. You simply need very good reasons (including business reasons) to do that.
Moreover, companies at these sizes just have a LOT of code all over the place. Tooling, infra, supporting services, etc... Not to mention it's just not useful to have external contributors for a business product like Github. Doing code reviews, addressing bugs that were introduced, spending time discussing things with contributors takes an incredible amount of time.
Basically if the reason you want Github open sourced (and reworked into some weird architecture you described) is so that people can contribute to fix things and add features....Github could/will just hire more devs to work on that.
Github.com = Github Core + Production Services and Infra
Github Enterprise = Github Core + Services need for Self Hosting
Maybe it's not worthy to proceed based on assumption but if there is something like "Github Core" which is shared codebase between prod and self-hosted, open sourcing the core can be an option?
Then possible path might be isolating least coupled (and small) components of client side code and open source?
The last one is a really powerful move for a software company. Normally, people will use your software if it's free, but if there's performance or other limits, it decreases the number of potential users. External open source projects then pick up the user base you might have acquired later. By open sourcing your own product, you effectively eliminate the need market for the external projects, giving you back your user base (which helps your community, potentially leads to sales, etc).
For some companies this would be cutting things very close in terms of profit margins, but Microsoft has plenty of other income that it doesn't need to worry about an occasional loss. It has way more to gain from leveraging this product in all its other tech offerings, even if they made zero money off enterprise support.
I don't think Microsoft's previous open sourcing of Xamarin is a good indicator and may lead us to misunderstand MS's strategy. To me, it would be very out of character for MS to open source Github.
Yes, MS has released things like C# compiler (Rosalyn), Visual Studio Code (Javascript Electron app), and Xamarin to the open source community.
But, MS has not open sourced CodePlex, Visual Studio Team Foundation Server, Skype, Linkedin.
I see a difference between "programming tools" and "collaboration platforms" and Github is in the 2nd category. I see no strategic reason why MS would pay $7.5 billion for Github to just turn around and open source it.
> But, MS has not open sourced CodePlex, Visual Studio Team Foundation Server, Skype, Linkedin. [...] I see a difference between "programming tools" and "collaboration platforms" [...]
They've open source some of those "collaboration platforms". It's not a clear black & white situation, I don't think.
LinkedIn has a large open source footprint: http://linkedin.github.io/
More importantly, Azure has a ton of Open Source: https://azure.github.io/
A lot of what might possibly be considered "secret sauce" bits of the Azure stack are open source, and you could possibly cobble together your own mini-Azure if you needed too and for some reason it wasn't just cheaper to buy Windows Servers with Azure Stack out of the box or even to just use Azure's existing cloud.
The Azure Functions Host is the biggest example off the top of my head that a lot of people imagine would be closed source but is open source.
(Another example is I've used over the years for different reasons is Azure's "Kudu" website deployment engine.)
I don't know if there's a cut/dried point where Microsoft might currently be drawing the line between its closed source stuff and open source, but "programming tools" versus "collaboration platforms" doesn't seem to be it (even before getting into semantic arguments about the fuzzy boundary between such categories).
That said, there probably is no obvious strategic reason for Microsoft to open source GitHub at this point, and maybe all that money that was spent in the purchase are plenty more reasons not to.
But Xamarin is an interesting leading indicator, and if there is a person to put in charge of GitHub with any interest in exploring the possibility of at least open sourcing more of GitHub, even if never quite "all" of GitHub, it is probably Nat Friedman.
>More importantly, Azure has a ton of Open Source: https://azure.github.io/
Sure I get those examples of "bits and pieces" being open source. Likewise, Google open sources lots of things like Protobufs (BSD license), CityHash (MIT license), and Kubernetes (Apache license) -- but they don't open source their crown jewels of proprietary source code collaboration, the Google Cloud datacenter management stack, and of course, their latest iteration of PageRank. A lot of those Azure github repos I see are open source examples for client SDKs as opposed to building a full clone of Azure that's equivalent to RedHat's OpenStack.
Those limited examples didn't seem to be the spirit of Joel Handwell's wish. I think we can presume that he wants to download the entire Github source code, compile it, and self-host it like GitLab. I could definitely see MS open sourcing bits & pieces of Github but still not give away the entire stack.
To me, it looks like MS is taking Github in the direction of a hosted service for full Application Lifecycle Management. (For example, add more features to compete with Jira.) Github-Enterprise could possibly eventually overtake Microsoft's own Team Foundation Server as the preferred release management tool. It adds to MS portfolio of other cloud services like Office 365. Likewise, if we ask for MS to "please open source Microsoft Excel", it's probably not going to happen because it's not compatible with their strategy of selling Office 365 subscriptions.
My wish is the same wish as the open letter dear-github (https://github.com/dear-github/dear-github) signers and not to host open source github in other server than github.com. Just hoping to see requested feature implemented earlier by cooperating with OSS community. I wish to still use github.com after it's open sourced. So for me, the limited partial component open source can be a starting point and the open source effort do not need to go all the way to the production backend which is distributed performance optimizing hacks usually not directly affects UX/UI.
> To me, it looks like MS is taking Github in the direction of a hosted service for full Application Lifecycle Management. (For example, add more features to compete with Jira.) Github-Enterprise could possibly eventually overtake Microsoft's own Team Foundation Server as the preferred release management tool.
In terms of that speculation I disagree. I don't see Microsoft adding Jira-like features to GitHub when they can already encourage people to use VSTS (Visual Studio Team Services) Work Items if they want the high touch issue tracking. There's already flows between GitHub's Issue tracker and VSTS, and that seems likely to increase. Which is very similar to the existing separation we already see Atlassian makes between Bitbucket Issues and Jira, with Atlassian working hard to upsell Jira to Bitbucket users with more complex Issue Tracking needs.
If anything, Microsoft is maybe in an even better position to make that transition and/or integration work, given the impression that it never feels like anyone inside Atlassian ever uses Bitbucket's own Issue Tracker day-to-day, yet Microsoft plainly today has teams in both GitHub Issues and VSTS, and needing to smartly straddle the "fence" between the two.
It sounds like Microsoft's intent seems similar with the rest of GitHub-related ALM. GitHub has gotten a lot of its support by being relatively ALM-agnostic. While there are many fans of Gitlab adding CI out of the box, there are also proponents that prefer the competitive GitHub Marketplace and the general ability to pick/choose CI/CD providers or other ALM tools.
Microsoft has already for years tried to position VSTS (and sibling project App Center) as the "best" ALM provider for GitHub CI/CD/Release management/etc. I don't expect that to change with them owning GitHub, and it's only in their favor I think to try to leave GitHub itself appearing relatively "ALM neutral" and leaving the upsell to GitHub's Marketplace.
Similarly, there are rumors/indications that GitHub Enterprise has underperformed in the marketplace versus the expense of maintaining its fork of the main GitHub codebase, and Microsoft's easier option is just to migrate its users to on-premises TFS. They'd likely lose hearts and minds doing that, but it seems more likely than migrating the other direction. I think, solely gut instinct, its more likely they just keep both around and let the users decide, at least in the immediate term, but if one is "losing out" to the other, I would currently put money on GitHub Enterprise as being the one to be canned.
If GitHub wasn't built from the start for hosted deployments, it will probably be both expensive and a pain in the neck to run. GitLab probably has it's issues, but I won't be surprised if there are assumptions made in GitHub's code that assumes you are essentially running on high memory / high cpu machines to reduce latency.
Additionally, we found functionality like HA and DR were implemented very seamlessly in GitHub Etnerprise. Easy to set up and not a hassle once it's running. GitLab basically tells you to build your own HA which isn't something we're interested in doing.
However, I think you underestimate the value of open source. Besides being the right thing to do (respects freedom, allows developers who built it to use their code later in line with license agreement, allows others to learn by contributing or at least reading, plus many other benefits) it can be a powerful recruiting tool. There's real business value in getting good hires.
Also, irony means suggesting the opposite. I don't know why anyone would use M$ ironically.
Judge the comment on the merits of the data provided and opinion based on that and don't get hung up on a name?
"M$" may also be useful as an indicator of bias but again, it is not the whole comment.
Does GitHub have some proprietary tech/functionality that is valuable enough to warrant it being closed source? As far as I can tell, GitHub's most valuable assets are it's large user base and the brand itself, it's actual functionality seems to be pretty standard amongst git hosting applications (Gitlab, Gitea/Gogs, Bitbucket, etc...). However, like I said, I myself am not a heavy user of it, so there could be some feature the others are lacking that GitHub would like to keep the code closed to prevent others from replicating.
I have a hunch that your actual complaint is that they too do with it what they wilt, and what they wilt is not "give to you everything they add on top of GitLab for free and forever".
GitHub does not have anything remotely close to that.
My intention is to make github.com "Client Side Code" better by let OSS community join into the development. So open sourcing backend and architecture is not my interest and possibly not interest of MS too. I'm not sure if Github is made of micro services, but if it is, certain client side code could be open sourced first and only that could generate great contribution to improve it.
I'm heavy user of Gitlab and disappointed because it is no longer fully open source and some enterprise features would not be welcomed to be implemented by OSS community because it conflicts with Gitlab company revenue. In my ideal world, MS splits Github source into client and backend and open source "Github client + test backend" for community to test if client code works while they make pull request and keep production backend closed. Do you think MS would be interested in this?
If everyone contributes their pet UI feature (e.g. custom theme, use XYZ monospace font), then there will be dozens of features that only 0.01% of users use, but it increases the overall complexity of the product and maintenance burden.
And my point was not +1 button but splitting code into open source "Client side + Test-backend" and closed sourced "Production-backend". Backend can be composed of some interface and multiple implementation such as test impl and prod impl. Actually Github could be hosted in Azure and I do not care their backend as I go github.com anyway.
https://github.com/dear-github/dear-github/issues/304#issuec...
That way the social aspect is still there, regardless of if the repo is hosted ON github.com or a remote copy.
If Microsoft open sourced GitHub, I'd still use GitHub.com, for the reasons I stated above. Heck GitLab is already OSS and I don't use that because GitHub wins via the network effect[0].
PS - I have no issue with people asking for this; I'm simply pointing out the "win" if Microsoft agreed, is lower than you'd immediately anticipate.