Hacker News new | comments | show | ask | jobs | submit login

I agree, my biggest concerns are:

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




> Will Facebook/Google/Apple start pulling their code from GitHub?

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.


I think public code will still live on github, but I See FAANG 100% avoiding any private github repos from now on.


Bigger tech companies not only do not host important private source code on Github but won't even host on outsourced physical servers. Where I've worked (incl. well-known names), information that we wanted spread to the world could be hosted on trusted external systems (trust still mattered to keep it from being "edited"), but non-public info was always hosted inside a physical building that we owned watched 24/7 by human guards we employed.


MS employee here:

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.


> Long before the acquisition, we've been hosting important stuff in private GitHub repositories. Including having strategic discussions in those private repositories.

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"?


Yes, it's absolutely an allowed policy. When we made .NET (Core) open source, we meant it. We still use email like any other org, but whenever we're working on our product we try to keep discussions on GitHub. It's also made collaboration with other teams far, far easier.


How so? What was going to be controlled, by whom?


I assumed that Microsoft has security policies to ensure that all confidential information (e.g. non-open-source code and strategic discussions) is stored on infrastructure controlled by Microsoft.

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.


Microsoft aims to make most of its money in the immediate future by convincing every major business in the world to let MS host that company's email, internal documents, spreadsheets and powerpoints on Microsoft's office365 servers.

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.


My company is concerned about that as well. We don’t use any cloud storage from Microsoft or anyone else, and we self host Exchange and SharePoint servers.

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.


Serious question: do you think your company has better security than the Azure cloud? Or is it a trust issue with the cloud vendors themselves?


.... and if you don't trust Microsoft: Why use Exchange and such? :-)


Better is relative - especially in one metric: many eggs in one basket make that basket exponentially more attractive to evil actors. Bigger attack surface and whatnot...


Flipside (pro-cloud pov): if the work to protect one egg applies to all eggs, then cloud providers will always hypothetically be able to spend more on security due to economies of scale

Essentially, choose your vulnerability: cloud provider single point of failure or in-house lack of resources


Yup. It all boils down to a business decision, the technical merits are not prevalent for either case.


Maybe info sec drove the decision to purchase github because that was the easier way to reign in the data leak. =)


> I assumed that Microsoft has security policies to ensure that all confidential information (e.g. non-open-source code and strategic discussions) is stored on infrastructure controlled by Microsoft.

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.


I'm almost sure you mean private repos on github.com, but just wanted to confirm it. You don't mean corp github right?


Yep.


Not entirely true. Microsoft puts (almost? Yet to find anything that isn't) all our code on VSTS which is accessible remotely, without VPN. I've checked in a (very very minor docs) fix to the Windows code base from my Android phone over LTE.


That's amazing. Contrast that to my friend who works on code at Apple that's so guarded that he can't even access it from Apple HQ. He has to travel to his office in an unmarked Apple bldg several miles from HQ (in an unmarked van) and access the code from inside the bldg. Any attempt to work on his code outside that bldg, on the Apple employee shuttle for example, will result in immediate firing with possible criminal charges. Admittedly, that's not the usual Apple employee, but the contrast between that and Microsoft's, which may as well be hosted on a set of Chinese night market DVDs, is LOL-worthy.


LOL-worthy

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.


Opsec and AppSec usually handled by different teams :)


This sounds proportionate if a state might go after the code. For example phone encryption might be a big prize for the Chinese or even American government.

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 disagree. Phone encryption should ideally be open source-able and it's security should rely as entirely on a device specific key as possible.

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.


I wouldn't take SiVal's comment as ground truth. I think it conflates rules for general employees with rules for his friend, and mixes it with a dash of unfounded hyperbole (criminal charges?).


The code isn't available outside the building unless someone takes it outside, which they make clear is not only a fireable offense but might qualify as criminal. They made it quite clear: If you're in crunch mode, don't be tempted to just take a bit of work with you to get a bit more done on the long shuttle ride.


Fair enough. I obviously don't know your friend or his project, so I can't with certainty say anything about his situation. I viewed your post through a critical lens because the details given didn't match my experience or the experience of any of my old colleagues, and you are a second-hand witness.


I am going to agree with what doctorsher said in response to your comment. I can confirm that what SiVal said is not a typical experience in Apple.


For reading, I agree, but if you're making changes it is a different story.


This has to be something very mission critical like phone encryption. No way this is the norm even at Apple.


I thought it was widely known Apple was extremely secretive, compared to the broader tech company at the very least.


> unmarked van

You may think it’s unmarked, but if you know how to spot them they’re very easy to pick out.


If I was an intelligence agency, I would do the trivially obvious thing and only use "unmarked cars" when I didn't care about being spotted, and an actual nondescript vehicle the rest of the time.


What's the difference between an "unmarked car" and a "nondescript vehicle" ?

You think the CIA would do their clandestine work on cars labeled "CIA" ?


> What's the difference between an "unmarked car" and a "nondescript vehicle" ?

Unmarked police cars often have multiple radio antennae, flexible lights, and even government plates, they simply lack explicit police markings and light bars.


Surely an unmarked van owned by Apple would have none of that?


The point is that the "unmarked" vehicle sticks out as unusual even without having "Apple" or "Police" emblazoned on its side.


Yeah, which is hosted on Azure, a data center that Microsoft owns and employs guards for, and secured behind our standard corporate authentication. :) (Source: I work at Microsoft, near the VSTS team.)


> Yeah, which is hosted on Azure, a data center that Microsoft owns and employs guards for, and secured behind our standard corporate authentication. :)

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.


Yeah, all I was really saying was that the grandparent's comment and the parent's comment weren't in opposition.

Microsoft owns the data center the code lives in and certainly takes care of physical security.


The only thing a VPN would do in this case is hiding that you're even accessing VSTS and providing modest proteaction against MitM attacks. You still have to use 2FA to log in, and the code you access is still logged.


VPN puts you on corpnet. And yes, I'm well familiar with our various account protection techniques (I work on the token server) - I was calling out that some companies trust their systems enough to make it remotely accessible, not saying it's a bad thing that I could be productive on the bus ride home.


Github offers an enterprise version and I know of at least one big company which hosts their code there.


Note that this doesn't preclude the possibility of an on-prem Enterprise Github setup.


As an owner of several Google org repos on GitHub, I can vouch that this is definitely true. Only open sourced code goes into GitHub. Private repos are only used for staging purposes thereof, i.e. getting a release of open source code ready prior to the world visibility bit being flipped.

We would definitely never store our proprietary code on systems run by anyone else, regardless of who runs/owns them.


They already did. Except maybe for test setups and to configure a project before announcing it.

All those companies keep their privates private. GitHub is just a public showroom for them.

Again this is different for other/smaller companies.


Ah, I think that's how it's always been. What's the difference between me running my small company out of Azure, and keeping the source code in GitHub, now that Microsoft owns it?

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?


FAANG, I've never seen this before! Facebook, Apple, Amazon, Netflix, Google?


Correct, It's often used in modern context when talking about what stock is powering the market right now. It's a "FAANG" market.

EDIT: https://www.investopedia.com/terms/f/faang-stocks.asp


Oh, it's a stock thing? It makes more sense as Wall Street slang - in terms of the technological landscape, one of those companies is so obviously dissimilar to the others that the phrase makes little sense.


I don't understand by what metric Netflix is included but Microsoft is excluded. It should really be FAAMG, or maybe FAMANG.


The acronym was coined in 2013 to describe the best-performing tech stocks at the time. Microsoft's resurgence hadn't really happened yet. The acronym was so convenient that no one's updated it except to add Apple (which didn't require a change in pronunciation).


Well in this very specific context, it's hard to imagine that Microsoft will be avoiding using GitHub just because it's owned by Microsoft.


FAANG is used very generally to refer to these five companies. It's not just in this specific context. I'm wondering why Microsoft is excluded.


I see Big Four (Google, Facebook, Amazon, Microsoft) more often than FANG although that is obviously confusing on Wall St where that phrase usually refers to the large accounting firms. Apple is excluded because it is a hardware company not a software company although sometimes it is subbed in for one of the others, depending on who is using the phrase.


If you include MS, you have to also include IBM. FAMAING.


I thought the N was Netscape, a major competitor to Microsoft (browser and server) and Google (browser)


Netscape was a competitor to Microsoft in the 90s, and it has never been a competitor to Google.


I thought they already have their own version control systems?


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

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"?


First, as pointed out elsewhere, the Apple/Facebooks of the world already aren't putting their private repos on any external service (perhaps they rent iron on a cloud, but certainly not SaaS).

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.


> Atom

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.


This sounds entirely anecdotal. I haven't seen any significant exodus from Atom to VSCode among people I interact with. It seems like folks moving from other editors are about as likely to choose Atom as VSCode, and the things that used to lead to people choosing one or the other (i.e. performance, VSCode only opening one project at a time, the stupid huge icon bar in VSCode, etc.) have been resolved...Atom is now reasonably fast, VSCode can open multiple projects and you can close the stupid bar. I tried them both and ended up with Atom (and vim, where I actually still do most of my work, but new JavaScript projects are in Atom).

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.


The 2018 Stack Overflow Developer Survey [1] puts VSCode at almost double the number of developers compared to Atom (34.9% vs 18%). You're right about the package count: atom.io lists 7654 packages, compared to 6802 at marketplace.visualstudio.com, many of those being color themes (some seem generated and machine-published, too). That said, workflow for extension authoring in VSCode is amazing, the community is very much alive, and sometimes it almost feels like there's an "extension for everything". Quality may vary, naturally.

[1] https://insights.stackoverflow.com/survey/2018/


Wow, that's surprising. VSCode is not just (far) ahead of Atom, it's the leader on that survey. I'll have to give it another look. Last time I used it, it had far too many annoying characteristics.


> VSCode is not just (far) ahead of Atom,

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.


> This sounds entirely anecdotal. I haven't seen any significant exodus from Atom to VSCode among people I interact with.

Were those two sentences in the wrong order?!


Anything that came out after vi is just another editor.


I picked up emacs in 1993 when I first got my hands on a unix system, and it was the only thing there that made remotely any sense. Fast forward to 2018, I'm still using emacs, and the upside is I haven't had to learn anything new in the intervening 25 years.


Please refrain to divert the discussion towards operating systems, we're talking about text editors here, for which ed is the standard.

https://www.gnu.org/fun/jokes/ed.msg.html


I very much share the sentiment and I’ve been using Vim (recently Neovim) pretty much exclusively for the last ~20 years. But VS Code “just works” to such an extent that I’m seriously tempted to use it.


(OT editor wars)

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.


What is vi? Lol


It’s the successor to v.


I thought it was the successor to ex.


Personally I've seen more people using Atom than VSCode, but that is just anecdotal.


Fellow Atom user here. According to Lee Dohm, Open Source Community Manager at GitHub, "Atom remains key to GitHub. Our product roadmap is set, and the team will continue all of their work." [0]

[0] https://github.com/atom/atom/issues/17454#issuecomment-39442...


A product roadmap is set until it changes. "I am altering the deal. Pray I don't alter it any further".

Besides, Microsoft has enough PR skills to avoid unpleasant announcements about redundant products for a while after an acquisition they know to be worrying.


In a buyout, always be sensitive to situations where promises of status quo come from someone who is not in control of the situation.

Quite common for new owners to let old employees make promises they can’t keep and then make them disappear and change plans.


This.

Not saying that Microsoft has a plan to 'embrace extend extinguish', but if they did, this is how they would go about it.


> and the team will continue all of their work

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.


I actually really like Visual Studio Code, I could imagine a great product coming out of the marriage of Code and Atom. I could also imagine infighting killing Atom, but I’ll try to be optimistic.


Until the deal closes.

Then... who knows.


The really nasty changes always seem to come at the beginning of the second fiscal year after acquisition. So meet me back here in 18 months and we’ll talk.


Obviously Microsoft doesn't want or need two open source editors. I think the smart move would be what I call the Adobe strategy.

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.


Ah yes, Apache Foundation, the place where ambitious but under-resourced projects go to die. /s


You joke but, for the vast majority of projects, it's kind of true. It's gotten to the point where, if it's not out of incubator, I have a really hard time convincing any one of my colleagues to put any time into projects hosted there.


I've got a few friends that are still very involved in the Flex community which is now at the Apache foundation. Adobe if I remember correctly is still funding staffers to work on Flex many years later. I believe Flex is either the second or third most successful project at Apache in terms of downloads.


Thought you were talking about the good old lexical analyzer "flex" there at first.

How silly of Adobe to name it like that. :D


RE> I believe Flex is either the second or third most successful project at Apache in terms of downloads.

How can that be given that Adobe is killing the flash runtime?


The team has created a ActionScript to JavaScript compiler so it will have a future without the Flash runtime.

https://cwiki.apache.org/confluence/display/FLEX/Flex+JS


I talked to the flex team a couple of years ago - and they did not think this was possible. I wonder how complete it is. At the time they said though Actionscript claims to be ECMAScript it is far from Javascript in very fundamental concepts they are based on such as inheritance and encapsulation (AS) and closures (JS).


> 1. What is happening to Atom?

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.


> What is happening to Atom?

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.


This is exactly what they will do. Make it easier to connect to azure. It might just work.


I wouldn't be worried about Atom; half of Facebook is using it; if anything were to happen, they would fork it.


While i'm confident that Atom will not "die" any time soon, if MS pulls the team that's currently working on new features and reassigns them, then at best it's going to be a large blow to the project.

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.


Nuclide (https://nuclide.io) is what FB uses/develops internally. I think even if the original team departs, they are going to be just fine. They could hire the original team right away if needed.


MS wouldn't pull the team; it would be GitHub that pulls the team. GitHub is operating as an independent company.


It is, now. A year down the road...?


So MS is just going to pay engineer salaries to maintain a free tool used by FB?


The way I see it, it's not worth the risk of Facebook forking it and essentially getting control of the community of developers who are using Atom. A better way to do it IMHO, as other people in the thread mentioned, is just integrating Microsoft products like Azure to promote their enterprise offerings (where they make their money).

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.


I'm curious if Electron will get a boost of some kind now. Considering how famous/notorious it is, MS could get a hell of a lot of goodwill here if they invest in the tech.


(consumer) Skype is famously Electron based. Microsoft has already been investing heavily in the project and I think we will see them double down on their commitment now that they own GitHub.


More likely, they will make the new, NEW Windows API essentially Electron. Instantly Electron apps run better on Windows because each app doesn't have its own browser runtime taking ip disk/RAM.


The Microsoft/Windows implementation of PWA is already basically this


They're reinventing HTA, in other words. Oh the horror!


I'm sure we can look forward to the next electronconf not being cancelled.


Wouldn't that mostly look like an investment in v8?


Or a common API where it uses Chakra on Windows and V8 everywhere else, until someone plugs in Webkit or some other engine for other OS'. Wishful thinking :)


My biggest concern is that the FBI has turned Microsoft into a "one-stop shop" for its National Security Letters, which at one point represented 40 percent of all the requests Microsoft got from the FBI.

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?


Contributing has always been different for each project and I don't see any real benefit by using github regarding that topic.

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.


I had the impression VSCode had the technical superior plugin system and I found it much more performant.

Atom had more plugins for some time, but they had mediocre quality.


> I had the impression VSCode had the technical superior plugin system

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.


Technically superior could mean in this case that a rogue plugin does not affect the core editing experience. Having a fixed extension API, if the API is well done, could provide that.

You lose flexibility, you gain stability, discoverability, speed, etc.


I meant superior to Atom and not to Emacs.

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 was assuming that Atom extensions were similarly powerful as in Emacs, if that's not the case, then my point is moot.

I agree that restricting what plugins can do can lead to better stability and speed at the expense of extensibility.


> I found it much more performant

Sincere question: Does "more performant" simply mean "faster"?


Oh. sorry.

I meant, I found it much more responsive.


I'm more interested in how companies with private repos on GitHub react.


Companies that complete with MS still use Windows, Sharepoint, Office 365, and OneDrive.

Microsoft isn't going to go around snooping competitors' source code any more than they are going to go around snooping competitors' email.


And more relevantly to GitHub, they still use Azure and VS Code and Surface computers and XBoxes and keyboards and etc. etc. etc.

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.


Microsoft did snoop through the email account of a blogger who received leaked information[0].

[0] https://www.recode.net/2014/3/20/11624792/blogger-psa-dont-u...


Google doesn't. Do Apple and Amazon?


Did you know Gitlab.com was hosted on Azure?


GitLab was migrating to the Google Cloud Platform: https://about.gitlab.com/2018/04/05/gke-gitlab-integration/

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


Especially those that compete with MS or their subsidiaries. But then again, Netflix uses AWS, so who knows?


I don’t understand your comment about Netflix using AWS. AFAIR, Netflix is a reference customer for AWS. Every re:invent is full of Netflix people. Care to elaborate?


Netflix is paying money to its competitor. i.e. Amazon Prime Video.


Does Prime Video actually make money? It seems like a side project compared to some other Amazon stuff.


Amazon is Netflix's largest competitor.


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

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.


> I agree, my biggest concerns are:

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


This is my thinking as well. Do I bail ship to gitlab and support more open software, or do I try to stay centralized?


Personally, I'm not "bailing" from anywhere.

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.


I do not think the word "canonical" means what you think it means.


> accepted as being accurate and authoritative.

> synonyms: recognized, authoritative, authorized, accepted, sanctioned

That's what I meant for it to mean anyway...


In software the "authoritative" aspect of the definition is crucial.

How can two different endpoints both be authoritative? What happens if they differ?


Then people will be confused, which is why I'm exploring options to ensure they stay in-sync.


I'd recommend simply designating one as master, one as slave. Why try to appoint two captains of one ship?


Because having one as master and one as slave is exactly the problem i'm trying to solve here.

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.


Sorry if my comments haven't been helpful. But I don't think the problem you're trying to solve is tractable. I'd be very interested to hear of a solution that doesn't rely on locking and is immune to conflicts.

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.


Sounds like that would be a pain having that kind of work done in two places.


Which is rather unfortunate for something that all revolves around git.


... and when GitLab inevitably gets acquired by another ${megacorp}?..


Then I'll change part of the URL I've soft coded from ...hub... to ...lab... to ... bucket...


Any reason why you implicitly trust Atlassian?


Does s/he implicitly trust Atlassian?

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?


I don't. I use jira at work. It's shit.


You missed the point of that comment


The reason you can trust Atlassian a bit more because they have more narrow focus on dev tools so less chances that they could become a competitor. Unless you’re developing another (git/bit)(hub/lab/bucket)


Seeing potential in the unused combinations: GitBucket, BitHub, BitLab.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: