Actually those are completely seperate products. One written in .net/c#, the other in objective c / pure c. Some of the concepts have been "forked" tho.
Actually with the ipad app we are not even trying to create an email client (doesn't look like it currently) but more of a email communication tool. Sounds vague but in the coming weeks things will clear up.
Did you give the "new" Opera a try in regards to your large email "collection"? I had similar issues in the past, but the new version is surprisingly good in handling large repositories. Just as an idea ;)
True! I did use that for 2-3 months over the summer (version 11? 11.5?) , and it worked reasonably well. I eventually moved away, because it had a bunch of locking pauses.. I'm not sure what caused them. My guess is that when checking for mail in account A, account B,C,D would lock up?
but yes, if you are stuffing +100k emails into one folder -- that is completely insane -- that's why you use procmail to sort your email into different folders as it arrives; I subscribe to a LOT of email lists and ctrl-D delivers a lot of magic when I don't want to or have the time to sort through a bunch of crap but
Well we could build 'a' business out of it, but we realized it wouldn't be a scalable business. For a couple of reasons:
* We tried to do to much (classic mistake -> email + social + contacts...)
* There are way too many ways that people use e-mail (folders, labels, rules, sorting, etc, etc)
* Because there are too many ways you can not create a commercially viable alternative that fits a large nr. of users
Truth be told, we didn't even want to create an e-mail client but rather wanted to fix e-mail workflow. We never ended up being able to do that due to forementioned reasons. We intend to rectify that in a couple of our other products.
We still see a need (and people actually ask for it) for a unified e-mail/social inbox. So we thought to have the open-source community have a go at it.
Excellent answer, and I love your thought process. Why have all your work go to waste not publishing it? This way, you don't have to worry about the inevitable "Why doesn't it do <random fringe feature>? I NEED that in my workflow!", you still get good recognition in the field, and all us users benefit from another good email client.
I would still try to put any kind of businessmodel onto it and look if any money comes out. Now you are here on the mainpage and thus much more famous. Having your source code in the open doesn't mean you don't see a paycheck for your work! (especially when most of your page views will come from HNers, who value great coding work and thus are more willing to pay for it, even if they don't have to. Think about this one article about Textmate2 some days ago.)
> For the last one week, a considerable number of people who
> have downloaded the Inbox2 app have had issues.
> The main reason for this was that our infrastructure was not
> scaling fast enough at the rate the app was being downloaded.
Why does an email client depend on your infrastructure?
Actually the client doesn't but we also have another version which runs in the cloud. Old versions of the ipad app were hooked up to that, newer versions are completely stand alone so that has also changed in the mean while... hey what can I say, we move fast :-)
Well the cloud is always on and online. Additionally we want to work with metadata which we want to store in the cloud and is not supported by for ex. the IMAP protocol. I can't go into to much details regarding our product roadmap but having a cloud backend really helps.
Another concrete case is new email notifications. When our ipad is not the active app we simply are not able to inform you when new mail arrives (due to apple background app restrictions). With a client/cloud hybrid we can do the heavy lifting on the client and use the cloud for example to send notifications when new mail arrives.
The cloud is always on and online? I don't mean to be argumentative, but your cloud apparently couldn't handle the load. Downloading an email client shouldn't require a "hit by a bus" analysis of the app's creators.
An app can store metadata locally; no need to have that on your servers. No doubt you can do some interesting things by having a server-side infrastructure, but I'm concerned about the security implications. If your server gets hacked, an attacker would have access to all of my email. Not to mention that you would have access to all of my email and why should I trust you?
This is a good intention, but unfortunately the way copyright law works, having the license be ill-defined means that nobody can really use it and be assured that they're above-board, particularly in something like an Apache or GNU open source project, or in a company environment.
Unfortunately, there's not really a good, widely used license that does what you want, mostly because you run into problems pretty quickly based on derivative works with what you want. Let's say somebody merges your email client with a browser - can they call that by a different name? Can they sell that?
Anyhow, I'd suggest looking at looking at the Apache or BSD licenses (if you want the broadest use) or the GPL (if you want to ensure that modifications to the code must be distributed with any binaries made from the code). Licenses are a bit of a pain, but you can just pick one of the common ones and it'll really help adoption.
* Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
Ok I think I read you, but lets say his new commercial product was proprietary; the product costs $100. If the license for his original Inbox2 product was GPL, he would be required to distribute the source code on his new product right? So my point is, if its a BSD license he can integrate that code into the $100 product and not have to share the source code. I'm no software license expert so if I'm mistaken please correct me here.
IANAL either, but I still think he'd be free to use his original code in a commercial product. By releasing under GPL, you give others a limited license to redistribute and modify the software subject to some conditions, but you keep all your rights, and you are free to distribute proprietary versions of the code.
When you write code, you automatically have copyright on it (in most countries). Failing to include a copyright notice or including a license text does not make your work fall into the public domain.
As far as I can tell this code is not currently open source. The only permissions given are:
"now fork it, fix it and send pull requests". Which omits some important permissions, without which this cannot be called open source.
The author publicly announced it was open source via HN.
"Open-source software is software whose source code is published and made available to the public, enabling anyone to copy, modify and redistribute the source code without paying royalties or fees."
"Works are in the public domain if the intellectual property rights have expired, if the intellectual property rights are forfeited, or if they are not covered by intellectual property rights at all."
He put it on GitHub, and he announced it was Open Source on HN.
"There's no license in this case and you cannot claim any intellectual property of the code. It would be the same if you uploaded the content on your own site without providing any license. According to the terms:
We claim no intellectual property rights over the material you provide to the Service. Your profile and materials uploaded remain yours. However, by setting your pages to be viewed publicly, you agree to allow others to view your Content. By setting your repositories to be viewed publicly, you agree to allow others to view and fork your repositories."
No, that's not how it works. At least in the US, an author has an implicit copyright over his or her work even if he or she does not post a copyright notice. The author would have to explicitly forfeit his or her rights to the work in order for it to be in the public domain.
This was actually the case in most of the world when the USA was still using a register. It's relatively recently that the USA has signed up to what the rest of the world has been doing for a while ... just for a change.
Of course there are some places that haven't signed the Berne Convention and don't have a copyright treaty through TRIPS or something similar.
Also not a lawyer, but pretty sure that no license is the same as "All rights reserved" (meaning, the most restrictive possible). Claiming "All rights reserved" doesn't give you more rights, but does establish that you communicated it and that anyone violating it had a better chance of knowing that.
(I think -- not a lawyer)
His statement to fork, fix, and ask for pulls perhaps gives some rights, but not usage or deployment ones.
In other word, if the author intends something else, they should say so.
EDIT: just noticed ThirdParty folder -- that changes the default to whatever is compatible with the licenses asserted in these libraries. I didn't check them.
Hmm- I think that is a grey area. Note what is said here about default license/rights on GitHub as of 10-7-2011:
"Copyright and Content Ownership
We claim no intellectual property rights over the material you provide to the Service. Your profile and materials uploaded remain yours. However, by setting your pages to be viewed publicly, you agree to allow others to view your Content. By setting your repositories to be viewed publicly, you agree to allow others to view and fork your repositories.
GitHub does not pre-screen Content, but GitHub and its designee have the right (but not the obligation) in their sole discretion to refuse or remove any Content that is available via the Service.
You shall defend GitHub against any claim, demand, suit or proceeding made or brought against GitHub by a third party alleging that Your Content, or Your use of the Service in violation of this Agreement, infringes or misappropriates the intellectual property rights of a third party or violates applicable law, and shall indemnify GitHub for any damages finally awarded against, and for reasonable attorney’s fees incurred by, GitHub in connection with any such claim, demand, suit or proceeding; provided, that GitHub (a) promptly gives You written notice of the claim, demand, suit or proceeding; (b) gives You sole control of the defense and settlement of the claim, demand, suit or proceeding (provided that You may not settle any claim, demand, suit or proceeding unless the settlement unconditionally releases GitHub of all liability); and (c) provides to You all reasonable assistance, at Your expense.
Yes I did. My reply was to someone who assumed "no license" would grant him "all rights" (public domain) when in fact it does not give him any rights. For the copyright owner, the reverse is obviously true.
You and the other downv^Wredditors read it without considering the context.
The github page has a screenshot, but no features list. It could be a good idea to add one. Right now, I still don't have any idea of what makes your email client different from any other, and why I would want to use it.
This looks amazing, and I'm looking forward to compiling and running it on my Windows machine later today. I'm accustomed to simple and elegant apps like Sparrow and Mail.app on OS X and get really frustrated when I have to use clunky Windows mail readers. This looks like a huge step forward in many ways. Great job, and thanks for sharing.
First of all, Thank you for the contribution to the OSS community but I just have to ask one question. With all the language wars and what not:
1. This is written in C#, correct?
2. Two full years of your life - do you literally mean 40+ Hours/week?
If this took two full years as in 40hours/week or working on it full time, I'm shocked it took two years. SMTP, POP3, and IMAPv4 are exceedingly simple protocols and the UI just seems to look like standard controls, no custom UI elements. Just had to ask.
I know I could probably whip together a decent email client in C++ within a couple months from scratch and maybe a week or two if I used any number of libraries out there.
2. not as a paying fulltime job, but still probably around 30-40 hours a week
3. good luck with that, I also thought I could whip up the first version in 3 months... :-) Its not writing the code that takes so damn long its getting the machine and the user experience/expectance aligned.