Millions of people use the Dropbox cloud. Many of them know about the opportunity to suggest an idea for new functionality. But only a select few have been waiting for the implementation of the most desired feature for ten years. In this article we will look at how Dropbox has managed to ignore the needs of its users for such a long time.
Like any concept, utilitarianism is not without criticism. However, from the point of view of a software developer, it seems quite reasonable to first make changes to the product that are desired by the majority of users. And when companies create specialized portals and feedback forms in order to make the voice of the people heard, this cannot but please.
But not every fairy tale is destined to come true. Today we “celebrate” the 10th anniversary of the original post asking for what has since become the most requested feature, but which is still not implemented.
Table of contents
- How this all began
- An idea!
- Vox populi
- Timeline
- Suggested options
- Why does Dropbox act like this?
- Conclusion
How this all began
2008 was a year marked by the Olympic Games in Beijing, the global financial crisis, and the terrorist attacks in Mumbai. It’s no surprise, then, that the birth of a little-known cloud storage company was lost in the presence of those events. And yet Dropbox emerged from the backwater of the Y Combinator business incubator into the open ocean of the real market.
I first encountered the brainchild of Drew Houston and Arash Ferdowsi in January 2011 as a student. Someone from our stream thought it would be a good idea to share educational materials via Dropbox. I got an invite to the group's shared folder, and the guys with the superpower to actually remain awake during lectures started posting photos of their lecture notes there.
In July 2012 I bought a Dropbox account, and for good reason: I lost files containing music of my own production. More precisely, I deleted them with my own hands. Now I can’t even remember how it happened, but storing all important data in the cloud has become an immutable rule after that. Troubles with a hard drive and unruly hands are no longer scary.
Many things have happened since Dropbox was founded in 2008. It moved 500 petabytes of user data from Amazon to its own servers, launched a line of products for businesses, acquired several companies, and grew its revenue to over $2.5 billion a year.
In an effort to keep moving forward, Dropbox launched the Ideas portal to learn about user desires and provide them with the most requested features.
An idea!
I occasionally create small programs and utilities for my own needs, and I also develop the DryWetMIDI library. The files associated with these activities are certainly dear to me, and therefore live in a folder synchronized with the cloud.
But no matter what programming language you write code in and what platform you use, during the development process, temporary files and directories will be automatically created. I develop in C#, and building projects in Visual Studio results in the appearance of bin and obj folders. There's no benefit in synchronizing these up to the cloud.
Someone might say: “Well, let them synchronize, the Internet is fast these days.” Reasonable. But when there are many files, the process can take quite a noticeable amount of time even with a good network speed. After all, downloading one file of size N is not the same as M files of a total size N. The latter will take longer for obvious reasons: you need to send separate requests for each file, probably open connections, receive responses from the server, etc.
Another example is the obj folder generated by the docfx utility I use to build a reference site for my library. At times, there were thousands of small files in there that took an hour to sync with the cloud. In addition to being a waste of time and bandwidth, I had to keep my computer on until Dropbox finished its job.
At some point I got tired of it. A natural need for the following functionality arose:
Specify name patterns for files and folders that should not be sent to the cloud, while remaining locally on the computer. In essence, we’re talking about a file similar to the .gitignore one in the Git version control system.
It turned out that Dropbox couldn't help with this, and there were a lot of people who posted about the same problem. That's when I learned of the idea Add .dropboxignore directory to exclude folders without using selective sync.
Vox populi
In the article How ideas shared on the Dropbox Community are inspiring new features, community manager Emma Fay acknowledges that it is important for the company to hear what features and changes the audience needs and to deliver them. It is emphasized that Dropbox takes this very seriously.
The process is simple: a user creates an idea on the Ideas portal, after which others vote on it. Then Dropbox employees decide what to do with the initiative, and assign it a status. In the end, if the company agrees that the change will be useful for the product and its users, then upon completion of implementation the status will be set to Delivered.
The All Ideas section shows the total number of ideas at the moment — 889. However, only 27 (about 3%!) have the Delivered status. Perhaps these are the most desired proposals, with the largest number of votes? No. Moreover, the absolute leader of the list — the idea discussed in this article — has been consistently ignored by the company for 10 years.
As of today, the hero of the occasion has 1,300+ votes, 600,000+ views and over 1,000 comments. The closest competitor — the rejected idea Offline mode for Dropbox Paper web? — has less than 500 votes, and many fewer views and comments. As for the closest implemented one, the statistics are as follows: 200+ votes, 70,000+ views and 150+ comments.
Before we speculate on how this happened, let's look a little into history.
Timeline
I'm not sure about the date of creation of the idea, but right now the site says December 18, 2014. However, the first comment is dated December 16, 2014. It is unlikely that a person had a time machine, so most likely the correct birthday is a little earlier. But I have no proof, so we will rely on official data.
As one of the users noticed, the problem had already occurred to other people before. For example, in March of the same year and even in January 2012, and then in November. Someone even implemented this functionality by themself (although the project has long been abandoned and was only under macOS). In other words, it immediately became clear that the feature was extremely in demand. Everyone was waiting for the Dropbox representatives to respond.
And on December 18, 2014, they replied, advising users not to store in the Dropbox folder what does not need to be synchronized with the cloud. The same recommendation was repeated in March of the following year.
Some people began to lose hope and resent it. Increasingly, messages began to appear about abandoning Dropbox and switching to other cloud storage providers who offer this functionality. Over the years, the names of products such as MEGA, BitTorrent Sync (now Resilio Sync), pCloud, Sync and others have been mentioned.
But many still believed that users' opinions were important to Dropbox. Therefore, messages continued to appear with a detailed description of the necessary functionality and examples of use cases. People were even agreeable to the feature being implemented but left undocumented.
In July 2015, the author of the idea contacted Dropbox support, receiving a response that comments would be sent to the development team. I also had contact with support (already in 2022, in the eighth year of discussions) and received exactly the same response. Dropbox then remained silent publicly until September 2015, when they stated that the pain of users was understandable, and the feature was being discussed internally.
And examples of this pain continued to appear. The most frequent issue was the synchronization of node_modules folders: thousands of small files are sent to the server for hours. There have been other stories in which gigabytes of temporary data are uselessly transferred to Dropbox. There were also game developers on Unity, whose synchronization of meta files similarly highlights the importance of the proposed function. Problems have also arisen in LaTeX projects.
In January 2016, the number of votes for the idea exceeded 200. And what about Dropbox? Dropbox reads the discussion and understands the problem. The company has no other answer. However, in 2018, the company's employees decided to honestly declare that the implementation of the feature is not planned.
Of course, there was a wave of disappointment, canceling of paid accounts and product recommendations from competing companies. But not everyone lost hope, and once again an extremely detailed description of the problem appeared. After that, several messages were received from Dropbox representatives that the comments were passed on to the development team (for the umpteenth time).
In June 2019, a user shared an ironically worded announcement of the new version of the Dropbox Plus, sent to his email:
The all-new Plus plan is packed with top-requested features.
At the same time, the most requested feature, as you may have guessed, was missing from the release.
But, at the end of that year hope appeared! Dropbox has announced that it is working on a feature that will allow you to exclude files from syncing with your account. And after another 3 (!) years, the status of the idea was changed to Delivered.
Has it happened? Of course not. The provided “solution" has a number of problems, and we will analyze them in detail further.
A week later, under the onslaught of loud perplexity from users, the status was changed to Investigating. On the eighth birthday of the idea, a weary user prophesied that we would make it to 10 years as well, still without resolution. And now this day has come.
Let's remember what we were offered over this long period.
Suggested options
To simplify the presentation of the disadvantages of various approaches, we will use the previously shown example with the bin and obj directories that are created when building .NET code. But the essence will not change if we talk, for example, about the node_modules folder and the Node.js environment.
Storing data outside the Dropbox folder
Storing information outside of a synced folder was the very first solution suggested by Dropbox. And although the absurdity of this advice is obvious, let's describe the disadvantages of the approach. Actually, there is only one, but it's huge.
When building the project, the folders described above will appear. Moreover, they are created automatically inside the project directory. There is probably a way to move them somewhere so that they end up outside of a Dropbox folder, but no one does that and there is no point in forcing users to complicate their processes.
You can suggest that programmers use, for example, GitHub instead of Dropbox. But what if you create a small utility for your own needs that you don't want to send to GitHub, and versioning is not important? Git will also require execution of some commands to send data to a remote server, negating the transparency of synchronization with the cloud. And why forbid combining one with the other — to store a Git repository inside a Dropbox folder? Moreover, it was shown above that this functionality is needed not only by software developers.
At the same time, there are also defenders of the suggestion. But I hope a successful tech company like Dropbox, doesn't take seriously suggestions which essentially say "I don't know why this feature is needed, so no one needs it."
Selective Sync
Dropbox has been providing a feature called Selective Sync for a long time. You need to go to the settings of the client application, and in the huge folder tree uncheck those that do not need to be synced. But:
- With the check box unchecked, the folders will be deleted from the computer, but they will remain in the cloud. But bin and obj are needed locally to run programs. Actually, they are executed from the bin folder by default.
- To use the Selective Sync function, the data must first be sent to the server. But the files in question are temporary, they should never get into the cloud.
- When creating a new project and getting new bin and obj folders, you need to manually repeat the whole procedure.
- Of course, you will have to perform the same actions on another computer.
These are not even disadvantages, but the solution to a completely different task. Although, some people use Selective Sync to address this issue.
Official solution
In the end, Dropbox made it possible to ignore files and folders. Of course, they did it in a way that seemed like they had missed the whole long-term discussion.
According to Dropbox, users should run a command every time in the context menu or set a special flag through PowerShell that signals the client application to skip a file or folder. Problems:
- Non-obvious folder transformations when performing the procedure on different computers synchronized with the same Dropbox folder.
- These steps must be performed on each computer.
- Information that a file or folder does not need to be synchronized with the server disappears when they are deleted. If you delete bin/obj folders, they will be automatically recreated on the next build. Of course, without the flag.
- Users note that files are still “touched” by the Dropbox client, even though they are marked with the flag. This sometimes leads to compilation errors due to locked files.
- The file or folder must exist for the procedure to be possible at all. This restriction makes it impossible to say “Don't sync any folder named X” before creating X.
Why does Dropbox act like this?
So, Dropbox is well aware of an idea with a huge number of votes and comments, many examples and detailed explanations of the problem, but the company has been ignoring its users for 10 years. How can this be?
It is probably related to an unwillingness to reduce the amount of data stored by users. Right now, when purchasing a minimum plan, a user gets 2 TB of storage. Two points:
- most people don't need that much;
- usually, when renting server capacity, a company pays only for the volume actually used.
Summing the first with the second, it turns out that in the case of an average user, Dropbox only incurs the cost of storing far less data than 2 TB, but the user nevertheless pays for the full 2 TB.
What happens if you provide an opportunity to not synchronize a ton of unnecessary data? Instead of, for example, 500 GB stored locally (out of the paid 2 TB), only 100 will be stored on the server. The thought “I think I'm paying a little too much" may sound louder in the head. It's not far from leaving for competitors.
And there are a lot of them these days. Here are just some options (prices are per year):
- Google One: 100 GB for $20 and 2 TB for $100;
- Microsoft OneDrive: 100 GB for $20 and 1 TB for $70;
- Sync: 2 TB for $96;
- pCloud: 500 GB for €50 and 2 TB for €100;
- MEGA: 400 GB for €50 and 2 TB for €100.
Dropbox, meanwhile, only suggests 2 TB for $120. Not to mention that some of the above products have built-in functionality for ignoring files and folders.
There are a lot of requests for a more diverse range of plans, for example, Is there any smaller plan like 100 GB? or Can we have a lite plan?. By the way, I already forgot, but it turns out there was a 1 TB option before. So the increase in the volume provided and the resulting price fit into the company's strategy to raise revenue.
To be fair, there were also requests for larger storage amounts, for example, Allow a personal account to have more than 3 TB or Personal plans with more storage.
In April 2023, the CEO of the company announced the dismissal of 500 employees. Among the reasons, it is indicated that although the company is profitable, growth has slowed down. Presumably, Dropbox is trying to increase profits in various ways, so there is little hope for the emergence of alternative pricing plans or providing an opportunity to reduce the amount of data stored by users.
Conclusion
Dropbox was once the leading, if not the only, product providing cloud data storage. Using it meant getting high-quality and reliable service. Unfortunately, sometimes if a company is successful enough, it begins to ignore the voice of its users. And that can come back to the company in a bad way.
There are many discussions on the web, the essence of which is the same: Dropbox is stagnating. The company does not implement new really useful functions and does not listen to its users, although it provides them with a tribune in the form of a platform for publishing ideas. In fact, this site merely offered the illusion that we can influence the development of the product. Ignoring the most desired feature for a decade is nonsense.
According to the earnings reports, the number of paid accounts exceeds 18 million. This means that several thousand dissenters aren't going to make any difference. So see you next year!
Top comments (2)
Thanks for writing this piece! We really needed something like this to celebrate the 10 years of this feature request, and use it as an example of how not to treat your users.
I don't understand why nobody at Dropbox has been bothered by this over such a long time. Maybe they aren't even using their own product?
And then they talk about Environmental impact in their ESG page: "Dropbox is committed to fighting global warming and reducing our carbon footprint. We're always looking at ways we can make a difference in our day-to-day business practices."
Think of all the electricity and hardware wear wasted to sync useless files, on our computers, on all the machines involved to exchange data on the Internet, on their servers!
Cleaning up beaches is nice, but when you're a software company, with incredible software developers (they had Guido van Rossum after all), the least you should do is ensure you leverage your software writing skills to minimize your environmental footprint. When waste is multiplied by hundreds of millions of machines, it adds up!
I don't think the reason for such a terrible lack of consideration is that they're afraid it'd reduce our storage needs. The folders that need to be ignored typically aren't that big compared to the rest. And as you rightly pointed out, there are no intermediate options anyway to pay less for slightly less storage.
In fact, I'm pretty sure they'd be the ones saving the most money by implementing this feature!
So the most plausible explanation is just bad product management, up to the top since I fail to see how the most requested feature for more than 10 years would not have even reached the CEO for consideration (if he is unaware, it means he REALLY doesn't care about user feedback as you can't do simpler than consulting your own feature request system to see what are customer pain points). Investors and the board of directors should take notice.
I am in there, sadly. Multiple threads, fighting the fight, collating them, pinging the founder, and … being actively ignored for years. I offered to build it for them, to literally code it myself. But social features was more important. It was not only us either, the Designer folks, the Photographers and many more face the same as temp files get saved next to active work files. Sadly, the world moved on since and now most everything is a suite bing backed up online, or cloud native by default. Ironic that they could have cornered the market, but chose not to. Fun.