Indeed, the probability of this being discontinued, if it follows normal trends, is dramatically higher than pretty much any Google product, and worse the notion that the "product is their focus" is specious: getting investment cash or a buyout is their focus, as it is with virtually all startups.
Moralizing or taking shots at competitors is a dangerous tactic when you live in a glass house.
In fairness they're a new company and probably only have a basic view on how they're going to make money. They just licensed their core code under 'free software' so it makes sense for them to have a CLA. It will give them some flexibility as they figure out their commercial path - though I can't actually find the CLA on their site.
Anyway, in comparison good luck finding a 'free software' license for the Gmail API, or a CLA - and that's from a company that's benefited from Open Source more than any other.
Is this viral like the gpl? Does the use of the inbox backend, hosted by me, require release of the full source to the entire app that uses the inbox backend? My brief reading of the agpl seems to say yes. Which makes this an interesting toy but nothing more...
Yes, the AGPL does require the release of the source of any code built on components licensed under it. Chances are they'll have a commercial license, though my salary disputes your assertion that an AGPL base can only be used as a toy - we have contracts with some of the largest companies in my country.
I'm an idiot, but I'm willing to believe there are still people out there who love what they do, and would stand by it, even if Corporation X comes knocking on the door with a pot of gold.
I'd rather cheer for them and be disappointed, than dismiss them in advance and live my life perceiving the world through a cynical lens.
Huh. I didn't know I can write so dramatically. You catch my drift, though.
Well, I think everyone kind of breaks down with their "morals" or idealistic visions when presented with the word "billion". E.g. see Occulus Rift founder Palmer Lucey's posts on Reddit from years ago claiming he will never sell the company under any condition.
But a quick offer with a billion was made and just like that Oculus was Facebook's.
The problem is, Inbox already has a BUNCH of VC's behind it. Which means a lot of people only worried about making money on the board. Unless the founders collectively agree they won't sell the company and also have a majority of shares in the company, the first big tech company that comes knocking with an offer will treated like the second coming.
I think the point the parent comments are trying to make, factually correct or not, is that it's not entirely within the control of the people/company developing the product to determine whether they accept a buy-out if they have accepted outside money. It's not cynicism to point out when people make statements they may not have the ability to back up.
Whether that's actually the case is less clear to me though, after following some of the other comments from the developers here.
Working on a problem you care deeply about with great people is already a pot of gold. It's something that money literally cannot buy, and much harder to create than than cash in one's bank account.
And as for control, maybe I should just say it explicitly: we have raised investment but are still in full control of the company (aside: it'd be nuts if we weren't at the stage), and plan to keep it that way going forward. In fact, our investors decided to invest explicitly because they believe our team is the best able to make decisions on growing a sustainable business and solving the developer platform challenges. No matter how good the VC, they obviously don't have the background+skills+focus to design APIs (and likewise shouldn't).
One of our investors likes to say, "We're in your corner, but not in your kitchen," which I've always thought framed the relationship well. I know there's lots of cynicism in the tech world with buyouts/acqui-hires and swarmy VCs, so I can understand where this reaction comes from. And unfortunately I don't have a solid rebuttal other than saying "trust me" with the test of time. Clearly that doesn't work for the HN skeptics. :/
It's also worth pointing out that not all acquisitions are terrible. Google Docs came from an acquisition. So did Google Earth. Facebook continues to run Parse, and Instagram, and Beluga via FB Messenger. Sometimes these acquisitions legitimately make sense, but I think the important thing is keeping the right people in positions to make those decisions when the time comes, and not the people who are just looking for the immediate financial return.
So, since you seem to be a developer on this -I'd like to ask:
1. If I run my own email server and do not have email addresses from yahoo, google, et al, how does this help me?
2. Is there a way to strip html off every incoming message, but retain the original intent of the formatting?
3. Is the API compatible with PGP? Can I enable PGP encryption at the server level? For example, say the client connected to the server sends unencrypted mail over the SSL encrypted connection... is there a command to automatically encrypt the message to the end user if a PGP key is found on a public server?
4. It seems, much to my surprise, that there is a push toward permanent on-line storage of email -- even though this is extremely insecure [must trust multiple unknown parties/countries/servers/continuous rule of law, etc] and prone to failure as opposed to local only storage -- is there a "local storage" option similar to pop3 for those clients that wish to store email on cheap and easily secured local drives?
5. Tons of other questions... but these are the first four I could think of...
Sure, I'll run though these. You can also ping me at mg@inboxapp.com.
1. We just started with Gmail and Yahoo, and are working to support all IMAP servers. The sync engine currently depends on the CONDSTORE extension for performance, and not all servers have that extension enabled. What server are you running yourself? Dovecot? Cyrus? I'm sure we can get it working quickly-- we just didn't want to push support for servers that we hadn't yet tested.
2. Yep, we have some stuff to do this as well as remove quoted text and signatures[0] so you deal with the "canonical" message. We've been collaborating with the folks from Mailgun on making the best MIME parsing tools.[1] However, the incoming message is always still stored on the mail provider if you need the full rfc2822-compliant version. Storing the unparsed data locally during sync would be a one line patch, so you can do that too.
3. The API doesn't have any notion of PGP/GPG. We'd rather people build clients that have GPG encryption so you don't need to store a key on the server. (Why? See Lavabit.) Inbox just makes it easy to build any app, whether that's for one for sending secure messages, one for sending sales numbers, one for triaging bug reports, etc. etc.
Note that right now the open source sync engine has NO authentication and doesn't talk in detail about security. This was completely intentional to make debugging for developers easier. Obviously you should run this behind your own firewall, VPN, etc.
4. You're exactly right with that trend. Inbox sits as a layer between hosted providers (like Gmail) and your app, providing nice API endpoints. It doesn't currently support POP3, but we'd be up for adding it, especially if someone else wrote it. (Backend providers are pretty easy to plug+play here.) But yeah, this is aiming at the much larger market of people who use hosted services like Gmail, Yahoo, Hotmail, etc.
Feel free to get in touch if you'd like to talk more about security. I recommend joining the developer Google Group[2], where we'll discuss topics like this one and more. There are clearly lots of big decisions to make when designing a platform this important, and we want to engage the developer community to get as much feedback as possible at this stage.
We've also put a lot of work into making the code readable and modular. I encourage you to check it out from GitHub and take it for a spin in a VM. It's all Python, so very hackable.
[0] I just noticed that the Mailgun folks haven't pushed live the signature extraction library that Inbox also uses. I'll ping them now. It's pretty cool, and uses a hybrid of regex and a trained machine learning classifier.
It might be simpler to just use a regular SMTP server and procmail or equivalent to deliver to Inbox, with fallback to local mailbox on failure to deliver, which Inbox could then sync. No need to reinvent the wheel here.
By all means believe and cheer. As we can observe from the sports industry, people like having things to believe in and cheer.
But if you are somebody making business decisions based on sunshine and rainbows rather than the observed failure rate of startups, then please make those decisions with your own money and your own labor.
Because otherwise, you will end up creating a bunch of cynical employees and investors.
Moralizing or taking shots at competitors is a dangerous tactic when you live in a glass house.