[jasode]

>LinkedIn has a large open source footprint: http://linkedin.github.io/

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

[joelhandwell]

>Those limited examples didn't seem to be the spirit of Joel Handwell's wish.

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.

[WorldMaker]

Right, that's mostly what I think. We might see a lot of individual puzzle pieces open sourced, but not see the top-to-bottom "full stack" overview/instruction set/orchestration tool for all of it. Like I said, you could probably cobble together most of Azure if you tried, but it's like getting a shuffled collection of Ikea flatpacks without any instructions and no allen wrenches. That's certainly a model GitHub could follow here.

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