Live data from Hacker News

Dropbox closing Carousel and Mailbox

blogs.dropbox.com

421–430 of 435 posts

Re: Dropbox closing Carousel and Mailbox

#421
post #354

Earlier quoted context omitted.

That's because making a big pile of money the Silicon Valley way requires two things: a product, and a moat. It's not hard to create an email product, but email moats are hard because it's an anarchist technology by design.

Would you mind explaining what does "a moat" mean in this context?

Warren Buffet talks about "moats" all the time. Basically a business with a moat is just a business with a defensible advantage.

If you think of your business as a castle, a moat is something that stops others from taking your castle from you. This could be anything from a network effect (Facebook, LinkedIn), economies of scale (Amazon, Walmart), to patents (most biotech companies) to brand (Coke).

The way he put it was something like, "If you gave me 100 billion dollars to take Coke's market, I can't. They've been investing in infrastructure and brand all over the world for decades. Even if I could make a better tasting beverage, people would still buy Coke. They have a moat".

http://www.valuewalk.com/2015/09/warren-buffett-on-economic-...

Re: Dropbox closing Carousel and Mailbox

#422

Ugh. Yet another intriguing email startup being acquihired and killed off by a more-established tech company (see also: Sparrow). It's 2015 and I still bounce around email clients every couple months because all of the major options have substantial flaws.

Yeah, it's frustrating. I was using Sparrow until it got acquired and then shut down. Then switched to Mailbox... which then got acquired... Whoops. I ended up so frustrated I created my own email client in my spare time and half accidentally got into YC S14 haha. You can check it out here: http://www.slidemailapp.com I'll admit, as a previous poster said, it's not without it's flaws but we try hard and we really do…

vu0tran, I'm almost sold. It looks great, and I love the private part (which was the one thing I could barely live with in Mailbox).

If you do snooze[1], I'll throw all my money at you :)

[1]: which of course either requires server side (e.g. Mailbox) or (preferably) client side logic. I'd be fine with the latter, but I agree it's a non-trivial problem.

Re: Dropbox closing Carousel and Mailbox

#423

Earlier quoted context omitted.

No; but often the server components are heavily tied to some other proprietary libraries that they're not ready to open source. They could remove all proprietary code from their codebase, but that costs money - likely more than they were willing to spend on this product. Unless open source is part of your marketing strategy (which means the effort would have a budget), it's really difficult to open source an existing…

That's a speculation on your part.. and PR spin-off on theirs. Nobody asked them to support it, or whatever. Just dump the damn thing online so others can pick up and continue to "help fight your inbox to zero". Clearly their intention here was profits and since they didn't see any - they kill it off. They won't do it so nobody else should try to safe email either. I wanted to get my company (over 3,000 users) off Dr…

> Clearly their intention here was profits and since they didn't see any - they kill it off. They won't do it so nobody else should try to safe email either.

Um, of course their intentions were profit? Dropbox is a for-profit company, nobody ever questioned their intentions as being anything else.

And it's not pure speculation; I've worked on enough internally-developed products to know it's not always feasible to open source an entire service offering after the fact. It's expensive enough to do between code scrubbing, legal reviews, etc. that you're generally only going to do it for strategic reasons (i.e. you know you can never make money doing it but want to commoditize the market space to hamper a competitor's growth, you want the community to help support your infrastructure, or your business model is open source + support).

Re: Dropbox closing Carousel and Mailbox

#424

Earlier quoted context omitted.

Acquihires are more about hiring functioning teams composed of engineers and executives who are used to working with each other. That's a lot more expensive to build than just the salaries; and you can generally take that team and throw them at a problem with a reasonable expectation they'll accomplish something. Also, there's generally some amount of IP and customer data involved as well.

"you can generally take that team and throw them at a problem with a reasonable expectation they'll accomplish something" For about 6 months to a year, after which time most of them have left, or have gone into "waiting for the golden handcuffs to come off" zombie-worker mode on a project they have no inherent interest in. Totally anecdotal but the couple of acquihires I've seen from the inside have gone like this an…

Agreed; they tend not to be great deals for the acquiring companies long-term. But short term you can rally that team to build something else, and your likelihood of finding the mythical 10x developer (or manager) is statistically higher in a startup that successfully launched a product in a compressed time frame (even if the market didn't work out for them).

Any acquisition involves a lot of turnover. Guaranteed that this turnover is built into the models they use when evaluating acquihires. Consider how expensive most company's talent acquisition costs are though (upwards of $100k+ per candidate hired for top talent) and it starts to make sense.

Re: Dropbox closing Carousel and Mailbox

#425

Ugh. Yet another intriguing email startup being acquihired and killed off by a more-established tech company (see also: Sparrow). It's 2015 and I still bounce around email clients every couple months because all of the major options have substantial flaws.

FWIIW, Inbox has been created by the Sparrow team (among other googlers oc), so at least it is not a case where an acquihire ends with the people working on completely unrelated things.

Re: Dropbox closing Carousel and Mailbox

#426
post #400

This is very sad news and I don't really get the decision. The thing with Mailbox is that it was truly a great product before it switched hands to Dropbox. Once they bought it, that was the end of good functions and the product only went downhill from there. There's a lot of potential with email clients that will help you work better, Mailbox was definitely one of those products that helped. With good clients for Mac…

So you're saying that Mailbox was a great product for the whole month between when it launched and Dropbox acquired it? I can tell you that behind the scenes it was far from a well architected service, and the only reason why it was able to ditch the signup waitlist and ultimately handle the needs of its userbase was entirely due to the Dropbox acquisition.

What I am saying is that Mailbox was a great product, yes.

Looking at it from the outside, it seemed that Dropbox initially just continued the initial product velocity that existed from before the purchase.

After a while it seemed that the development lost steam, features were lagging and it seemed that they lost interest.

I am sure it wasn't a very well architected service and beyond that growth was "controlled" by the invite system (which ironically only fueled the growth).

The Dropbox acquisition had a lot of potential, mainly in fueling the growth by adding people/servers and ops knowledge.

So yeah, they ditched the invite system and a lot more people were using the product but what's that worth if the end decision is to drop the product all together?

What I'm failing to understand here (and I will admit it's due to non-existent investment knowledge) is what did Dropbox get out of the 100mm paid on the product and what led the decision to drop it now.

Re: Dropbox closing Carousel and Mailbox

#427
post #388

Earlier quoted context omitted.

There' no such thing as an "internal API", assuming the API works over HTTP.

I don't even understand what this comment is trying to say. If you use HTTP to communicate between services, and those services are not publicly accessible, the use of HTTP makes it no longer a private interface? For a site which supposedly hosting an audience of entrepreneurs and engineers -- people who understand that the value of a thing can be multi-faceted and not always obvious, or that the difficult of any job…

Someone said consumer apps (Carousel and Mailbox in this case) couldn't be open-sourced because they use "internal" APIs.

My point was just that any API over HTTP that's used by a consumer app is not private or internal. It is a public API with unfriendly documentation.

(Note that when I say "unfriendly documentation," I'm not even talking about sniffing. Most consumer apps can be decompiled by non-experts, and then the text-based API calls would be readable.)

Re: Dropbox closing Carousel and Mailbox

#428
We're a group of folks interested in solving this problem - perhaps by building a stable self-funded business around the most widely requested email client features, or perhaps by driving an open source movement in the community. Maybe both. Help us help you.

http://goo.gl/forms/9AVIGXNgkc

Note: All responses to this survey will be shared with the Hacker News community within 24-48 hours after initial posting.

Re: Dropbox closing Carousel and Mailbox

#429
post #400

Earlier quoted context omitted.

So you're saying that Mailbox was a great product for the whole month between when it launched and Dropbox acquired it? I can tell you that behind the scenes it was far from a well architected service, and the only reason why it was able to ditch the signup waitlist and ultimately handle the needs of its userbase was entirely due to the Dropbox acquisition.

What I am saying is that Mailbox was a great product, yes. Looking at it from the outside, it seemed that Dropbox initially just continued the initial product velocity that existed from before the purchase. After a while it seemed that the development lost steam, features were lagging and it seemed that they lost interest. I am sure it wasn't a very well architected service and beyond that growth was "controlled" by…

I guess what I'm trying to say is that I don't think Mailbox was derailed by Dropbox, since it barely had a public life before Dropbox and certainly would not have survived without the acquisition, Dropbox is equally as responsible for the few good years as the original Mailbox team.

As far as what Dropbox got out of the acquisition: no idea. I know there was a lot of interest in the Mailbox team, and they were immediately given a much broader purview post-acquisition (much like the founding team of Cove when they got acquired). Ultimately I don't really think that parachuting in founders to take over parts of your company works -- three out of the four of those people no longer work for Dropbox, for instance. However, at the time Dropbox clearly craved adult supervision, and I think that was seen as the way to get it.

Oh, and if you have a product people like, that doesn't hurt either. I just found it maddening that Mailbox was built from day one not to make money, and that problem was never solved. That sort of thing can only last for so long.

Re: Dropbox closing Carousel and Mailbox

#430

Earlier quoted context omitted.

Like many things, clients could do with some usability enhancements. E.g. encrypted mail. Without which, I find it off-putting.

Encryption is really an identity problem. For intra-corporate mail, email works just great, because the identity problem is solved. Trusted communications between 3rd parties just isn't a natural mail use case.

> For intra-corporate mail, email works just great

Not really. Hence the rise of intra-corporate chat software.

People instead prefer to join focused, well defined groups to send and receive intra-corporate communication.

Not bee CC'ed spammed all to h*ll about every little office detail that has zero impact on you and your job.

Post reply on HN