For these companies who owned GitHub hardly plays a role. They want to attract developers and go wherever the crowds go. If there is mass migration to mercurial-superhost.com they will follow. It's just an outlet.
The question is more relevant for companies and communities who built their infrastructure on it and might worry for good or not so good reasons.
Long before the acquisition, we've been hosting important stuff in private GitHub repositories. Including having strategic discussions in those private repositories.
We've also done a lot of that stuff in public too. Some might say a bit too much, given that we've had things leaked and/or misinterpreted w.r.t product direction in the past.
I still agree with your point, but I believe more of this sort of thing is happening. Lots of stuff that has no real reason to be private is just being open source by default.
Wow! I am very surprised by that. Is that an officially allowed policy? Or is it something that is "don't ask for permission, ask for forgiveness"?
The company I work at is very careful about keeping our intellectual property on our infrastructure, and I am surprised that a larger company like Microsoft doesn't have similar policies.
It would be highly contradictory for MS to take the position, as a matter of policy, that it is too risky for them to ever place confidential business data onto a third party cloud-hosted SaaS system, because that is precisely the risk they are asking every one of their customers to take.
Similarly, if you have concerns about putting your company's source code into GitHub now, you should be equally concerned about putting your company's prerelease annual report on the office365 onedrive.
That is a good point though, it’s becoming more and more inconvenient for a company to self host everything. Microsoft does stand to benefit from everyone becoming more accustomed to relying on 3rd party services in the cloud.
Essentially, choose your vulnerability: cloud provider single point of failure or in-house lack of resources
It depends on how important the code is.
I don't imagine MS will ever move Office or Windows to external servers, but a lot of other stuff is fair game.
There is always a security/convenience trade off.
and yet, which company released an OS update with an open root account with no password, patched it in a way that broke file sharing, then a couple of months later released an update with another password bypass bug? Hobbling people with security theatre isn't begetting good or secure code.
Microsoft actually hand over OS code to states regularly for certain contracts so I figure they don't need to protect most of thier code like that.
I think this makes more sense for a secret project (e.x. the next iPhone), but honestly as a security person it seems overkill for anything outside national security responsible code, like state sponsored malware.
I also find it strange that the code is apparently somehow accessible outside that building (see the fired comment). If this was anything beyond security theatre, it'd be on an airgapped network and that wouldn't even be a concern (as the employee wouldn't be able to access the code from their laptop). Seems excessive for very little gain.
You may think it’s unmarked, but if you know how to spot them they’re very easy to pick out.
You think the CIA would do their clandestine work on cars labeled "CIA" ?
Unmarked police cars often have multiple radio antennae, flexible lights, and even government plates, they simply lack explicit police markings and light bars.
Way back when, Microsoft used to host a bunch of auth servers for banks. A friend of mine mentioned an armed guard in front of the data center for that particular service.
I've worked on teams at MS where there was a (non-armed) guard checking everyone who got off the elevator, but before I joined MS I was once left alone in a room full of computers open to the Windows source tree, wearing my "do not leave guest unattended" badge.
Mileage might vary and all that.
Microsoft owns the data center the code lives in and certainly takes care of physical security.
We would definitely never store our proprietary code on systems run by anyone else, regardless of who runs/owns them.
All those companies keep their privates private. GitHub is just a public showroom for them.
Again this is different for other/smaller companies.
Nothing changes immediately for any of us, to me the biggest concern is what happens after those roadmapped projects have run through. What goes next on that roadmap, and will it stick to the principles I love about GitHub, or will it start to veer into Microsoft's territory?
No-one's going to join a company because of which front end to git they use. It's more a question "do Apple/facebook etc want Microsoft to have all of their private source code to look for exploits/rip off/hand over the government etc etc"?
Second, this is the same business model as Office 365, and I'm not aware of that raising any particular eyebrows outside of the fairly limited crowd that can't trust anyone. If you're cool with entrusting your email to Microsoft, your source code is not a great leap.
I could be wrong but my perception is that Atom is losing market share to VSCode all on its own– new devs are much more likely to adopt vscode & no growth ~= decline for an editor. Couple that with the fact that no one pays for Atom...
IMO They don't need to "kill" atom, they just need to wait a couple years, at which point it will just Yet Another Editor down the list with TextWrangler et al., if the next Atom doesn't come along and hasten its decline even further.
Atom still has more plugins, or did last time I looked (which was, admittedly, quite a while ago), and I think the ecosystem is a good indicator of how many people are actively using something.
Tutorial eco-system as well. When I jumped into JS development, all the getting started guides had Install VSCode as step 1.
So now I use VSCode.
Were those two sentences in the wrong order?!
This was me basically 100%. If you're doing JS development, VSCode gives you so much out of the box it's hard to bring myself to even attempt to configure Vim to do all that, even if it is ""totally possible."" I miss the advanced text manipulation capabilities from vim (along with a few other things) but the upside of VSCode is just too great.
[0] https://github.com/atom/atom/issues/17454#issuecomment-39442...
Besides, Microsoft has enough PR skills to avoid unpleasant announcements about redundant products for a while after an acquisition they know to be worrying.
Quite common for new owners to let old employees make promises they can’t keep and then make them disappear and change plans.
Not saying that Microsoft has a plan to 'embrace extend extinguish', but if they did, this is how they would go about it.
Until they aren't. I really don't see MS putting work into two code editors that are in direct competition with each other. I'm sure they'll let the dust settle for a while, but Atom will vanish from Microsoft's product list. No doubt.
Then... who knows.
Github should announce that Atom has become an Apache foundation project. Github then says it will provide x number of developers for an initial three year period. Probably won't make everyone happy but it should defuse most of the angst.
How silly of Adobe to name it like that. :D
How can that be given that Adobe is killing the flash runtime?
Funnily enough, this was my immediate concern, followed by Electron generally. It actually prompted me to go all-in on Vim: I've used Vim in terminals for a very long time, but never found a graphical Vim that I liked. Happily, I've now found Oni, which provides a VS Code-like interface around Neovim: https://www.onivim.io
Git hosting and the associated tools are replaceable, the strength of GitHub is the network effect, so we'll have to see what happens. Regardless of what happens, we've progressed a long way from Subversion and BugZilla, so I don't mind if projects move to a more diverse set of modern hosting. Personally, I'll put my own public repositories whereever the community goes.
Since they said Github will remain independent, so Atom will, I think. Maybe I'm too optimistic but when I think about VSCode's business model, promoting Azure rather than selling the editor itself, they have no reason to kill Atom. They might be integrating Azure with Atom.
A fork won't have the same team working on it, a fork won't have the same domain knowledge over the internals, a fork won't have the roadmap or what was currently planned and how to do it, a fork won't have the same unified development effort (if MS "kills" atom, FB won't be the only one picking it up, there will absolutely be others that won't like the direction FB is taking, and now you don't just have Atom, you have AtomFB, Atom2, NuAtom, etc...)
It won't be that big of a deal at the end of the day (it's not like there is a shortage of competition in this area), but I would be much more on-board with this if MS handles Atom well.
Eventually, though, they might want to allow an easy transition to VS Code in some way to cut redundancies but doing it too soon would anger too many people. Atom seems to be losing market share anyways.
How will Microsoft/GitHub handle such secret requests? Will Microsoft even sue the DoJ to stop it - or will they settle again the moment they obtain a small compromise from the government?
Biggest hurdles normally are: - big chunk, own branch, small chunks? - Contract to sign? - signed commits, unsigned commits? - changelog file? - patch via mail? - extra review tool? ...
In the end it's always a git push. Github only makes it look more beautiful.
Atom had more plugins for some time, but they had mediocre quality.
From my very limited exposure to VSCode's plugins, it seems they are a lot more limited in how they can change the editor's behavior compared to elisp code in Emacs[1]; if Atom plugins are similarly flexible, then I'm not sure you can say it's (strictly) technically superior if you can only implement a small subset of what you can do in competitor's system. At most it's better at some tasks and worse at others if this is the case.
[1] I didn't say "Emacs plugins" since there is no distinction between user-written elisp code and core editor elisp code and you don't need to create any plugin project or such, which I think makes for a much more organic and pleasant customization experience.
You lose flexibility, you gain stability, discoverability, speed, etc.
As far as I know, the VSCode plugins run in their own process, which makes the editor much more responsive when it loaded many plugins.
I agree that restricting what plugins can do can lead to better stability and speed at the expense of extensibility.
Sincere question: Does "more performant" simply mean "faster"?
I meant, I found it much more responsive.
Microsoft isn't going to go around snooping competitors' source code any more than they are going to go around snooping competitors' email.
I don't expect Microsoft, as a company, "to go around snooping competitors' source code any more than they are going to go around snooping competitors' email" or Azure infrastructure or code editor or putting loggers in peripherals or any other tinfoil theories.
I _do_ expect some companies to reconsider their policies in light of the acquisition and decide that other options make more sense for them for numerous reasons, including but not limited to not wanting to hand (even more) money over to a competitor for a service they don't necessarily need Microsoft to provide to them, or if they suspect Microsoft will significantly change the existing ToU/ToS in ways those companies would rather not deal with.
[0] https://www.recode.net/2014/3/20/11624792/blogger-psa-dont-u...
I do not know whether this migration has finished.
More links:
- http://fortune.com/2016/11/14/gitlab-cloud-storage/
- https://venturebeat.com/2018/04/06/why-and-how-gitlab-abando...
Perhaps tooling can help with this. Github, Bitbucket, and Gitlab (and I presume some of the lesser used solutions out there) all support some type of forking and pull request model, even though that's not core git. An abstraction layer atop that can hopefully obviate a hard dependency on one platform.
> 1. What is happening to Atom? I have tried VS code and don't really like it due to the difference in how the 2 systems are designed to work (Atom being more "plugins are king", VSCode being more "kitchen sink included by first-party"). I'd hate to see my favorite editor lose it's major backing. If MS makes a commitment to continue to develop Atom, or they work with someone else to "transfer" development over to them in a way that's not half-assed, it would go a LONG way toward solidifying the trust they are trying to build (at least to me).
> 2. How will other companies who are hosting on GitHub react to this? Will Facebook/Google/Apple start pulling their code from GitHub? Will we go back to having to learn how to contribute to each project individually?
> There's definitely major benefits for diversity in this area (meaning not having the vast majority of projects on one platform), but I'm hoping we (as developers in whole) don't throw the baby out with the bathwater here.
> GitHub has by most accounts helped bring in a renaissance of open source software. It's never been easier to contribute to FOSS at any level, and I'm hoping we don't lose that as everyone diversifies where they host their source code...
I started with sublime, went to atom, went back to sublime, and finally moved to vscode.. trust me you can't go wrong. It has everything and extensions.
It's everything I wished for.
I am however using this as an opportunity to rely on any one single place less.
I'm in the process of mirroring my git repos on GitLab, and trying to think of a way to signify that both the GitHub and GitLab repos are "canonical", and that issues/PRs/contributions can happen at both.
> synonyms: recognized, authoritative, authorized, accepted, sanctioned
That's what I meant for it to mean anyway...
How can two different endpoints both be authoritative? What happens if they differ?
I want both to be master, so that users who are comfortable on both platforms are willing to make contributions to the codebase, so that any one service/system going down won't stop development, and so that as the "community" migrates around different platforms they can always find the full version of the software.
Recommending simplifying a process to the point that it no longer solves the problem it's trying to solve isn't helpful.
You might fake it (and meet your stated goals) by maintaining a true master behind the scenes and syncing to two public slaves... (ie, forks you treat as peers, each with a "master" branch) but that still leaves neither of them truly "canonical" -- a designation of authority that would apply to the place where you'd resolve conflicts given simultaneous commits.
If anything, that comment makes it clear to me that they're staying mobile because they don't implicitly or explicitly trust any of the current providers.
I think if they implicitly trusted someone, they'd just migrate to them immediately - why wouldn't you?
1. What is happening to Atom? I have tried VS code and don't really like it due to the difference in how the 2 systems are designed to work (Atom being more "plugins are king", VSCode being more "kitchen sink included by first-party"). I'd hate to see my favorite editor lose it's major backing. If MS makes a commitment to continue to develop Atom, or they work with someone else to "transfer" development over to them in a way that's not half-assed, it would go a LONG way toward solidifying the trust they are trying to build (at least to me).
2. How will other companies who are hosting on GitHub react to this? Will Facebook/Google/Apple start pulling their code from GitHub? Will we go back to having to learn how to contribute to each project individually?
There's definitely major benefits for diversity in this area (meaning not having the vast majority of projects on one platform), but I'm hoping we (as developers in whole) don't throw the baby out with the bathwater here.
GitHub has by most accounts helped bring in a renaissance of open source software. It's never been easier to contribute to FOSS at any level, and I'm hoping we don't lose that as everyone diversifies where they host their source code...