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.
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.
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.
So "you are the product" seems to fit open source as well then, eh
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?
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.
[1] https://github.com/apple/foundationdb [2] https://github.com/apple/cups
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.
Imo chrome and android are about being able to ensure ads are delivered.
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.
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) ;-)
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.
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.
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.
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.
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.
As in, failing at the one thing the app is supposed to be doing...
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.