It’s a really great example of worse is better.[1] We went from sophisticated network file system to a daemon that destroys your battery life (at least on Mac) watching for file changes in a directory.
FTP is neither sophisticated nor a network file system. Frankly I'd take Dropbox over FTP any day of the week - FTP needs to die.
Thankfully your options are not limited to either Dropbox or FTP. Thus people who want simplicity can have Dropbox (or similar) and people who want control can have sshfs or any number of other tools out there that require some assembly but also don't suffer from the numerous problems that pre-TCP/IP protocols like FTP suffer from.
I’m literally talking about the theory of the paper by Richard Gabriel (https://www.dreamsongs.com/RiseOfWorseIsBetter.html) which is that worse solutions often win because it takes too much time to bring a good solution to market.
If you were trying to make a “good” solution to the problem addressed by Drop Box, it probably would not look like Drop Box. For example, you’d do a real network file system that wouldn’t need to do a binary diff of the file each time to see what changed, because it would have access to the block level changes at the file system layer.[1] You'd have file locking in the protocol (like CFS), and could sync data from a locked file instead of waiting for the lock to be released.[1]
It also probably wouldn’t have made Houston a billionaire because who is going to install a kernel driver off the internet? But on the flip side, Dropbox almost certainly killed much of the interest in real network file systems, because it is good enough.
Which is why we’re all using an internet powered by Javascript, Electron apps on the desktop, etc. Worse is better.
In that case it might have been helpful if you stated that you were shifting the context away from FTP; as was the context in the GPs comment. ;)
NFS and AFS (from what limited I know of it) are more designed for local networks thus to leverage NFS over a WAN you'd then need to tunnel your connection (eg via SSH or VPN). So while there is obviously overlap between them and Dropbox I wouldn't really say the two are all that comparable.
However to answer your point, I don't think anyone would disagree with the specific part of your point regarding how simplicity is often better than something arguably more powerful. However just because something is simple it doesn't mean it isn't also good. "Good" is just a question of whether it meets requirements. If your requirement is that it can be installed and operated by layman then Dropbox is a far better solution than any other the other proposals you've mentioned.
Yup, mentioned that in my previous post. Awesome project. I remember the first time I discovered it - I felt like a caveman who'd just discovered fire.
Network file systems are harder than they sound, and writing additional file systems for Windows is a huge pain. Even Microsoft's own solution - OneDrive - they've had to walk back slightly on their "placeholder" implementation for detached operation, which was great when it worked but occasionally managed to blow up badly.
I think you mixed up worse is better. The idea behind the phrase is that quality does not increase with functionality. Functionality often means features along with bells and whistles. Sure that application looks pretty and offers tons of features but with that complexity and glut comes a steeper learning curve as well as possible security and stability issues in the code (more bugs).
A good comparison would be comparing using make files and a simple text editor like vim to visual studio. Is visual studio truly better because it offers more features when a make file and vim can do much the same? A programmer used to VS might call the make file method worse, but the reality is that it is the simpler path which makes it better. Realize that simple doesn't mean "simple to use" but simple in terms of complexity (philosophical simplicity is at play here).
Worse is better is better translated as "A simple design is better, but not from the users perspective."
I'm talking about these two points from the paper, regarding the "Worse is Better" philosophy:
> Simplicity -- the design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design.
> Correctness -- the design must be correct in all observable aspects. It is slightly better to be simple than correct.
Dropbox is simple in implementation, at the cost of simplicity in the interface and correctness. E.g. it is simpler to simply punt on locked files in Windows. Tell the user to quit Word if they want their file to sync, instead of handling file locking at the protocol level. Likewise, it's simpler to detect changed files after the fact than write a filesystem driver to knows what blocks are changed. But it degrades the user experience (their computer burns clock cycles re-figuring-out information a real filesystem driver would've had).
The upside of all that is that Dropbox was simple to implement, simple to port, and simple to deploy, which made it popular:
> Therefore, the worse-is-better software first will gain acceptance, second will condition its users to expect less, and third will be improved to a point that is almost the right thing.
Your situation is different than mine; this is the first I've heard of Dropbox even registering as a top use of battery.
How many files do you have? I've got 26000 files in my Mac's dropbox folder. (Granted, very few of them change more than once or twice a day; maybe 20 or so of those do.)
I last used Dropbox in 2011 or so (I stopped using it because it killed my battery life). It may have gotten better since then. (But my point is addressed to what it takes to get popular, i.e. that its easier to make a “dumb” tool popular, and Dropbox was popular back then.)
Going out on a limb here, but I think it's possible things have changed in 7 years (and that it was probably something specific to your setup, not something millions of Dropbox users with a Mac had to put up with).
> i.e. that its easier to make a “dumb” tool popular,
If this was your intent, then using the tired "worse is better" trope and claiming an issue from 7 years ago, that no one else has claimed to have seen is seems a far cry from it.
Dropbox became popular because it was easy, it worked, and did exactly what it said it did. That might be "dumb" in that it's not feature packed, but you use a lot of negative connotations when none are required.
There has never been a network file system that really worked for this use case - detached operation by average users. The nearest we ever got was WebDAV.
It really sums up nerds' lack of comprehension of the importance of user experience. It's like the UX version of the apocryphal "640k is all anyone will ever need."
The first iPod was terrible though and sold poorly. The 3G was the first good model, and they didn’t start taking off until the 4G. History only proves that his analysis was completely correct.
No, Windows support came with the 2G in 2002. iTunes for Windows wasn’t a thing and few Windows machines had FireWire, but the Windows-compatible iPod came out in 2002.
The 3G was the breakthrough model, but I lend that as much to the dock connector (which was available in USB and FireWire) and the growth of x-platform iTunes as anything.
The broader point that it required Windows support for the iPod to become mainstream is of course true. That said, the iPod was also the reason so many of us became Mac users in the early 00s because the “halo effect” was undeniable.
You're right. It really was the dock connector that made it a viable product for many people. The fact that the first iPods were Firewire (which I totally had forgotten about and I even had a 1G iPod) made it very difficult to make it work outside of the Apple ecosystem.
A great many successful tech companies can be described in terms of more consumer-friendly Unix tools.
Slack has the better part of a billion dollars in funding for what's essentially resource-hungry IRC with pictures. Dropbox does little you couldn't accomplish with a server and rsync.
What I'm really eager to see is git for everyone else.
When you simplify and generalize git to the point where "everyone else" can use it, you get Apple's Time Machine and Windows' File History. I'm not that familiar with Time Machine, but if File History had a more visible interface that you could use to easily "checkpoint" individual documents or directories on demand, you'd pretty much be there.
Branching is too complicated for most people to work with and overkill for most scenarios.
What would "everyone else" do with Git? It's a Rube Goldberg solution implementing a highly specific set of ways to do file versioning.
Most cloud storage providers offer rudimentary versioning; are you referring to the idea of promoting commits to being first-class? It would need to be baked into Word, Excel and similar, and those tools already have builtin version tracking, as horrible(?) as it is, so... :/
People I know who definitely have this problem tend to work in creative fields - especially musicians and (digital) visual artists. They almost universally have a bunch of files with names like project_final2_revised_reallyfinal3_with_edits_from_sally.psd.
Of course, a solution that works well with all the different binary file formats people in those fields use wouldn't be easy.
Ah, that. Yes, absolutely I'd love for a solution that fixes that.
It would definitely need to work with large files though, which categorically precludes Git.
The first point, I think, would be building a delta engine with case-specific code for the most common ubiquitous file formats, like docx, xlsx, psd, etc. Of course it wouldn't be able to be perfect with everything but it would certainly be better than eg just recompressing each version or something equally naive.
The UX would be the next major hurdle. Time Machine is a good example of the kind of simplicity that would be needed, but it would need to be a have a bit more surface area to be applicable and useful to all scenarios.
One other feature that comes to mind, which would be incredibly difficult to get right but probably critical, would be useful version diffing. I think keeping this simple and just building something that can do $anything->SVG (with maybe cheats where bunches of the SVG is mostly just a bitmap in certain cases) and then doing something fast on the SVG (and/or its bitmap contents...) would probably be the most viable target.
It think it does need branching and collaboration. There needs to be a way for Sally to contribute those edits, and they might not actually make it in to the final result.
No doubt there would be a learning curve. I think that's OK. The target market here is serious users who already dedicate time to learning professional tools like Photoshop.
Oh no. Now you need full file format parsing so that you can resolve merge conflicts.
:(
That would take years to get anywhere with ._.
The diffing idea I suggested above is just manageable, a la macOS Preview, with hacks. Branching requires folding-back-in, and that's not just a case of "A or B", it's a case of "A, B and C conflict with D and E, while F G and H are okay," where I could then say "save B and E but drop F". If B is a layer, E is an imported asset and F is a custom filter... you get the picture. You need a reimplementation of Photoshop (halting problem).
:/
Sad that everyone hates GIMP.
But... hmm, this could get folded into Blender, and then make the rest of the industry jealous.......
The dhouston on that YC post is this guy now: Andrew W. Houston is an American Internet billionaire entrepreneur who is best known for being the co-founder and CEO of Dropbox, an online backup and storage service. According to Forbes magazine, his net worth is ~$3 billion.
