[jessedhillon]

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?

[smt88]

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

[jessedhillon]

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.

[jarek]

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

[jessedhillon]

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.

[smt88]

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

[austenallred]

Undocumented API then?