401–410 of 435 posts
> The Carousel and Mailbox teams have built products that are loved by many people And now those people will hate Dropbox.
thankfully many is very different to most. its a pretty good approximation that compared to dropbox /nobody/ uses those products.
Earlier quoted context omitted.
Would you mind explaining what does "a moat" mean in this context?
It's a ditch dug around a castle to stop people getting in. i.e. the 'wall' in the walled garden.
Earlier quoted context omitted.
Yeah but that's ridiculous, they had only 13 employees that's 7.6MM per employee over the span of 2.5 years, some of them I'm sure they left already... You tell me when this starts making sense because it just doesn't right now. Too much money! I don't care how big of a genius you are you're not worth that as a developer of an email client, and honestly to write an Email client is not genius level shit. The UI was do…
The deal was stock and cash, so it is pretty much impossible to judge how good a deal this was for Dropbox[1]. Stock is a very cheap way for a company to acquire another. [1] http://techcrunch.com/2013/03/15/mailbox-cost-dropbox-around...
Not exactly. Could be the other way round too. It depends on whether the stock of the company is worth more or less than cash in the long run.
So buy them, wait two years, then kill them off? Great use of funds there Dropbox, I guess you put the stellar bunch in charge of the development roadmap in charge of acquisitions too.
Earlier quoted context omitted.
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.
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.
The self-starter types of people tend to route around obstructions and unpopular decisions by doing it themselves, better.
* So you've acquired a Gmail client - why? Surely whatever good comes out of that Google would just re-create into Gmail. Sure enough: Inbox. I'm not even sure how this would have fitted into the Dropbox strategy? I doubt they would have wanted to be acquired by Gooogle. I doubt they would have wanted to compete in the email space... If it was just to get attachments from email surely there are many other ways to solve this problem.
* Second thought: Dropbox has acquired a photo sharing and organization app. Surely they don't think they will win over Facebook, iPhoto, Flickr... What for? Store the photos? Even if it's an awesome product, don't they just risk Apple Photos getting better? Or wait... Here comes Google Photos.
Inbox. Google Photos. iPhotos. Facebook Moments. It feels like both Mailbox and Carosel were just ticking timebombs.
Earlier quoted context omitted.
Still using Sparrow, but wondering if it works on El Capitan? Does anybody use it on El Capitan?
I use it with El Capitan. Still works fine.
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…
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.
Earlier quoted context omitted.
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: I…
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 rea…
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?