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