"We gave a lot of thought to open-sourcing the underlying system, and none of that thought will be elaborated on here."

I'll elaborate on their behalf: "That would be hard and expensive and we have money to make."

Even if they wanted to open source their system, it is likely is that they migrated their codebase to the Dropbox platform, and it would be difficult for them extricate their code. Most larger tech company (e.g., Google, Facebook, MSFT) have this problem when they want to open source products...

God forbid anyone make any money. Where I work we feed our engineers on the appreciation of free users. That's the only way to fly. Self-entitled much?

God forbid anyone share abandoned code. Where I work we incinerate anything potentially useful when we're done with it. That way no dirty freeloaders can take advantage of it.

Let Pa be the probability that some piece of your open-sourced codebase reveals an important technique or strategy to your competitor, thus leveling a technological advantage you have,

Let Ca be the cost of that lost advantage,

Let Cb be the value of good will from the open source community

In what case is Cb bigger than (Pa * Ca)?

When Pa == 0, so like, most of the time.

It's an email app. It talks IMAP^H^H^H^Hto Gmail. It runs on iOS. How many secret, commercially important techniques do you really suppose it contains?

Suppose it writes to Dropbox using internal APIs? How many developer hours should they spend abstracting/obscuring that usage? What are they going to gain by doing that? What are they risking if that process misses something?

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 is easy to underestimate, and that to convince someone to do something you have to appeal to their incentives/concerns rather than your ideals -- the entire argument in favor of opening this app is built on pedantry and baseless assumptions.

> 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?

Yes - if you make a HTTP call from an app, it can be trivially sniffed. Sniffing HTTP is the first thing a third party trying to discover that undocumented API would do, and you don't need source code for that at all. (This is also why you must always sanitize data coming in from a user's device, even if it's from your own app.)

You can make the argument that there would be a time cost cleaning up the internal calls that will no longer work once the servers are turned off. Sure, but: 1) there are no secrets that would give competitors a new advantage, and 2) if you don't have that time, just chuck the code over the fence and see what happens - worst is that no one uses it, which will be the case with closed code anyway.

The is just so unimaginative that I can't believe you've ever seen the inside of a large operation. How are you going to sniff traffic that's communicating on a private network? And how does trivial sniffability not extend to all unencrypted traffic, ergo nearly everything is public? That's a totally useless definition and misses the point entirely.

Your point #1 is totally unjustified: you don't know what you could learn by e.g. looking at a data structure used internally. #2 shows that you are unable to answer the question of which of Dropbox's incentives are satisfied by doing this.

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.)

Undocumented API then?

That "formula" really isn't particularly difficult to work around.

First off, if you're open sourcing your codebase because you're getting out of a particular market, you have to ask whether revealing techniques and strategies to competitors in that market is really an issue. After all, if those techniques and strategies had given you a competitive advantage, you probably wouldn't be having this discussion.

Second: If you really are concerned about that, just use the GPL.

The assumption here being that the integration of the now disused product into the parent product (Mailbox into Dropbox) has no potential to reveal the internal workings of the parent product e.g. APIs or data structures. Or that those techniques would only be applicable to competitors in that market. Both are convenient for your argument, but there's no reason to think that they're correct. Moreover, there's no reason for a risk adverse company to accept those assumptions.

My point was to challenge open source cheerleaders to actually give a reason beyond their own gain for why a company should do this. Instead, we have blithe dismissals and narrowly constructed hypotheticals built on optimistic assumptions.

> My point was to challenge open source cheerleaders to actually give a reason beyond their own gain for why a company should do this. Instead, we have blithe dismissals and narrowly constructed hypotheticals built on optimistic assumptions.

I'm sorry, but what? Your whole initial argument is a narrow hypothetical "they will see our secrets" with no theory of what those secrets might actually be - what exactly do you expect in return? I gave you an answer based on your formula, and a follow-up comment afterward. Can you expand what about my answer was built on optimistic assumptions, in a way that your initial theory was not?

There are no private APIs nor secret data structures in software that you've distributed to users. It can all be decompiled and sniffed. "Oh but the competitors will see my code" is basically FUD. How many times has YC told us it's all about the execution, not the technology?

Yeah, the difference is that the "narrow hypothetical" is a concern a real person at any company would have when tasked with deciding whether something should be open sourced. It's appropriately conservative.

You, however, are asking everyone to assume that it's totally safe to reveal any/all source code.

> There are no private APIs nor secret data structures in software that you've distributed to users.

That's fine. What about the code that lives on your servers and supports the client?

When abandoning a market and an app, there is no strategic advantage in that code. This means the solution to that equation is CaCa.

I imagine Mailbox has a heavy server component, which would be non-trivial to get set up and running on your own.

If you're looking for an alternative, we built one at Nylas. :) https://github.com/nylas/sync-engine

Nylas looks awesome. Has anyone built a plugin for it that allows for "message snoozing"? That was the real ingenuity with Mailbox IMO.

Not yet! Totally something that we'd love to see, though.

That's hardly a reason to not open-source. You're not required to provide support just because you release your source code. Even a dump of their repositories would be useful for people who are interested in Mailbox.

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 commercial application.

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 DropBox long time ago after each update comes with new issues. But this just broke camel's back. I will make the switch happen this weekend.

> 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).

"That's a speculation on your part"

Whereas your post is speculation on yours.

"Nobody asked them to support it"

At the same time, if they do open source it, people are going to see that it was once Dropbox, and any issues they see with it are going to be seen as the fault of Dropbox.

"Just dump the damn thing online"

Far more work than it sounds like.

"Clearly their intention here was profits"

They are a company with bills to pay and engineers to pay, right?

"They won't do it so nobody else should try to safe email either."

I don't see them going around and killing other people's email clients.

Honestly most startup backend systems are not amazingly engineered or something to be proud of, so I would guess that the code would need some considerable work before releasing it to the public if that is what they chose to do. Even after release, the project would need considerable support to get it off the ground (helping the first users, accepting contributions, establishing the project community and leadership). Simply dumping the code on Github with no instructions and leaving it to rot is not particularly useful.

Then OS the previous version that got them purchased by Dropbox.

Someone started a petition in an effort to lobby dropbox to do just that:

https://www.change.org/p/dropbox-open-source-mailbox-app?rec...