Hacker News new | ask | show | jobs
by fipple 2769 days ago
On the contrary, I’ve found that companies who are actually doing hardcore software engineering, where the code is the main value driver for the business, rarely open source their best stuff, but they’re great places for engineers. Google doesn’t open source its self driving car code. Facebook’s value driver is the network, not the code, so it can open source anything. Dropbox’s client is amazing and is not only closed source but heavily obfuscated.

When a small company open sources everything, their main value driver is in sales or marketing or partnerships or something. Not a bad thing, but not a really engineering centric place.

5 comments

Think the MBA speak for this is “commoditising you competition”. It’s when you use open source or zero pricing to either offensively or defensively to nullify an advantage your competitor has. Google attacks Apple by offering an open source OS (Android). Now everyone can make a phone.

They defend against Facebook controlling the internet by offering an open source browser (Chrome/ium).

Microsoft defends against irrelevance in the Linux age by open sourcing .Net Core. So now you’re just writing code for .Net, not Linux.

FB open sources dev tools to both attack and defend the talent pool.

Google open sources Flutter to counter React, decides it can show FB how it’s done.

Google also puts out K8S because AWS ate their cloud lunch and they need to show they also get it. Now you’re just running on K8S, not AWS.

AWS just open sourced a JDK. Now we can all give Oracle the finger.

Apple sits in their spaceship, not giving a fuck. Chris Lattner tried to open source for the sake of OSS, with LLVM and Swift, but he left.

> Chris Lattner tried to open source for the sake of OSS, with LLVM and Swift, but he left.

Maybe there's some history here that I'm missing: but it looks like LLVM and Swift are open source. Did Chris have any trouble open-sourcing them? Was the reason for his departure related to that?

He succeeded at open sourcing those two projects. Not sure why he left, but other than WebKit, which was probably a defense against Microsoft and IE, don’t think anything else can come out of Apple.
WebKit started as a fork from khtml (from kde). Apple didn't have a choice about open sourcing Webkit because they started with GPL2 code. They would have kept it closed source if they could, but that would have taken a few years of development, while they could start with khtml and get a great browser in just a few months.

I expect in a few years (5-10) Apple will do an audit, discover that only a small amount of code isn't written by Apple, and replace that with inhouse code and then relicense to something propitiatory. Time will tell.

Well I guess there's Foundationdb [1] and cups [2] but those were acquisitions.

[1] https://github.com/apple/foundationdb [2] https://github.com/apple/cups

> Chris Lattner tried to open source [...] LLVM

LLVM was open source from its beginning: it was Lattner's research project. Apple acqui-hired it/him, and they have a private fork.

I agree that it's pretty remarkable that Swift, which was conceived at Apple, was opened up, however.

I think it make sense from a cost/benefit analysis. Swift was created to make it easier for developers to write iPhone apps. Open sourcing the code provides developers with example code (given it was a brand new language), and more eyeballs to potentially look through the code to improve it whereas google open sourcing search should just allow bing to catch-up.
Amazon "open sourced" OpenJDK, which has been open source since the day 0 of Oracle purchasing Sun? Oracle just committed to maintaining backports for OpenJDK 8, and that part of Oracle's business it might be commoditizing: paid support for legacy versions, not the code.
> They defend against Facebook controlling the internet by offering an open source browser (Chrome/ium).

Imo chrome and android are about being able to ensure ads are delivered.

At this point, the ability to deliver ads is the definition of internet control.
So open source is just a service model where the product is free but you get loyalty.

So "you are the product" seems to fit open source as well then, eh

Excellent point.
I think your comment is close to the truth but not quite there. Companies don't open source their core business, basically an extension of "don't outsource your core business" (https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-...).

Google: Search engine? Closed source. Ads service? Closed source.

Facebook: yes, the network is important, but still: Ads service? Closed source. Data science stuff they use for harvesting relevant data from users? Closed source. Dropbox: agreed.

I agree, companies like Facebook open source things that are being helpful for them, and in most cases, due to their huge scale, they didn't find anything similar and had to do themselves. For a company to open source its core product it only make sense when you expect to have revenue from enterprise SLAs and custom services, as it is the case of companies like MongoDB and Redhat.
I guess another reason for Facebook to not open source their social network code is security.
Nice try. :-)
Security in this case meaning: "Keeping the truth of their business secure from the public in order to avoid backlash"
Seriously, the Dropbox client? I mean, I never used it but I can hardly imagine anything that makes it so special. I use Nextcloud and from what I can tell, there is nothing that sets the Dropbox client apart from the Nextcloud sync client (which is 100% open source).

In addition, some parts of the Dropbox sync client are open source too: https://www.dropbox.com/de/help/desktop-web/linux-commands#b...

Sure if your business model depends on selling the software then open sourcing it might be a bad idea. But if you are selling software to other companies they most likely are not interested in the software but in the service you provide, so they will require Service Level Agreements which should be the base of your business model.

However, with consumer software that doesn't work very well, since nobody gives a about service levels (even if it would solve many of their problems) ;-)

For one, delta-sync was built into the Dropbox client from the very beginning, and I'm getting the impression from this thread that Nextcloud still doesn't have it till this day: https://github.com/nextcloud/server/issues/417

This is a major contributor to sync UX, and by no means trivial to implement.

Another example is their file stubs implementation (Project Infinite) that works across platforms, which is also no small engineering feat, that afaik no other sync software has been able to replicate yet (OneDrive has this on Windows, but no other platforms).

The Dropbox client makes just about every other sync client look like toy projects in terms of technical sophistication, reliability, and general UX. There's a reason why they're so successful. And I say this as someone who doesn't even use Dropbox on a day to day basis (I use Syncthing as my daily driver).

This really seems like a matter of the OP not knowing what they're missing and then flaunting that ignorance.

> This really seems like a matter of the OP not knowing what they're missing and then flaunting that ignorance.

In fact, I added that I never used Dropbox to give context on my perspective. I am not sure that qualifies as 'flaunting that ignorance'.

Regarding the delta-sync feature: That is, in fact, a feature neither Nextcloud nor Owncloud posses at the moment. On the other hand, it would not be that beneficial to my use-cases since I rarely have large files within my synced folders and most of the time I have a GBit connection to my Nextcloud. So I guess I am missing not that much (at least with my current usage pattern).

Granted, for some use-cases, it is essential and bringing such a feature to all major platforms is not a trivial task. Yet I still wonder if protecting the implementation is necessary since the comments in the Nextcloud issue suggest that the primary problem the availability of the developer is (who might have an easier job if he could take a look at the Dropbox code, but ultimately he would have to write an implementation that integrates with his project).

And ultimately I wonder what makes people decide which service they want to use. For many people, it sure is the little friction you encounter during the setup of Dropbox. For me, it is not that much about the features of the client software but about the features of the larger system. Being able to host my own server is essential to me. Having an open source implementation is a nice add-on, which I value and made use of already. AFAIK those features are not available with Dropbox I seriously doubt my previous comment qualifies as flaunting ignorance.

The only thing keeping me in Dropbox is the fact that I use several very important apps (one of which is an encrypted password vault) across very different OS-es -- think iOS, Android, Windows and macOS.

They offer transparent syncing so all your app instances work with the same data and sadly trying to get the developers of the apps to include self-hosted solutions (with added configuration step: the IP/port) is not happening and isn't likely to happen.

And both Apple and Google aren't open to the idea of allowing cross-ecosystem app synchronization (think game you play for an hour on your iPad but then want to play it on your specialized gaming Android device when you are out and about later; in the case of games this problem is solved by using Google or Facebook as login providers on all your devices). And until that's true then Dropbox and other popular cloud storage providers (mainly Google Drive and OneDrive) will always have a place.

LOL! I had given OP some credit and assumed that Nextcloud was a full featured competitor like Box. Whoops!
Dropbox Nautilus Extension is open source because it has to be - GNOME Files is licensed under GNU LGPL. The amount of code in that extension is minimal, the proprietary Dropbox client pretty much does all processing, the extension is only responsible for displaying icons in a file manager.
How about you use it before assertively making claims about it. Just a good practice for life.
Well, for one thing, the dropbox client has never seen fit to randomly delete my local folders, which is kind of a bad thing for a sync client to do.

As in, failing at the one thing the app is supposed to be doing...

> Seriously, the Dropbox client? I mean, I never used it but I can hardly imagine anything that makes it so special. I use Nextcloud and from what I can tell, there is nothing that sets the Dropbox client apart from the Nextcloud sync client (which is 100% open source).

Writing a simple file sync utility isn't difficult, hell you could just wrap rsync and you'd be half way there. Making that open source is easy and low risk, because you haven't really invented anything.

On the other hand, if you can throw 100 developers at the problem, you'll come up with something _far_ beyond the simple case. Sure it might only be 50% faster? But that 50% makes your product "magic" when compared with other tools. This is where you get things like Project Infinite (https://blogs.dropbox.com/tech/2016/05/going-deeper-with-pro...). I can imagine there are some very complex optimisations for the multitude of configurations that Dropbox runs on, that I can understand a company wanting to keep "secret" if it's so core to their business.

I think you'd be surprised at the depth to which these companies are solving problems.

> In order to innovate on the user’s experience of the file system, as we are with Project Infinite, we need to catch file operation events on Dropbox files before other applications try to act on those files. [therefore we need a kernel driver]

You can block the operation within fuse's userspace part while calling out to some helper gui program to ask for confirmation. Seems like an excuse rather than a reason to implement stuff in the kernel.

I think Google actually does open source a significant part of their reusable libraries. I'm thinking about stuff like Leveldb, Tensorflow and Angular off the top of my head, but I'm sure there is a lot more.

Some companies do seem to be ideologically opposed to open source (I'm looking at you Balmer-era Microsoft) but Google has always seemed to have had a certain commitment to it.

I think a Javascript frontend framework like Angular has to be open source by definition. Or is there a way to close source it?
Once the output is built and uglified, you will not reverse engineer it back to the source that google started with. JS projects are not not much different from any other built project. Probably closest to .Net or Java IL once uglified. Still higher than WebASM, but still not he same as source.
It has to be open source in the sense of sharing the source code, but companies take the extra step of making it open source in the sense you have a license to use it for your own website.
You forgot support as main driver