It looks like this was forked from (or to) an iPad version?
It's probably a lot easier to sell there, granted.
It looks like a nice client- What are it's distinguishing features? What needs help? What are your intentions now- To throw it out there, or keep building it?
Are there binaries?
How are you handling the Messages in-memory? I'm looking for a mail client that can handle my multi-hundred-thousand email inbox, but everyone except Mulberry tends to have a problem ;)
Looks really sharp. Kinda reminds me of FF with the tabs at the top.
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?
... is really slow for opening large mailboxes, are you using some trick to make it faster? mutt alone just scans all mails before displaying anything. thats not a good idea for 100k+ emails
header_cache only works with Maildir and IMAP. If he's using Maildir for a mailbox w/ 100k+ emails, then he may start running into filesystem limitations.
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 :-)
What was the benefit of such an arrangement? My email server is already "in the cloud" so to speak. As it's a downloaded app, what value was added from a man in the middle, as it were?
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?
It's under the "I don't give a shit as long as some dude in china doesn't slap another name on it and sell it licence". I am not sure what the official name for that is tho :-)
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.
I think MIT and BSD licenses fall into that category in that the copyright must be left unaltered. But that still won't stop someone from doing what you say ;)
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.[19]"
http://en.wikipedia.org/wiki/Open_source
"Works are in the public ___domain if the intellectual property rights have expired,[1] if the intellectual property rights are forfeited,[2] or if they are not covered by intellectual property rights at all."
http://en.wikipedia.org/wiki/Public_domain
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."
http://stackoverflow.com/questions/4007674/whats-the-default...
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.
No license/no copyright declaration means no rights in all countries that have signed the Berne Convention (http://en.wikipedia.org/wiki/Berne_convention). This includes the USA since 1989.
"Copyright under the Berne Convention must be automatic" and "Under the Convention, copyrights for creative works are automatically in force upon their creation without being asserted or declared."
I'm pretty sure the grandparent meant "no copyright notice = no rights granted" rather than "no notice = no rights reserved". Maybe I'm just reading it too charitably.
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.
This is awesome. I've been looking for something like this for Windows for a long time. You put some serious effort into this and it's beautiful.
FYI - for those looking to run this: open the non-64 bit solution, build it, then go to the installer directory and run the windows installer. Works really nicely.
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.
Just got really excited about this and tried it on my iPad. I managed to set the accounts up no problem but on downloading data it just keeps bombing out on me, and now i cant get back into the app.
Well not entirely true, that other post is actually about a experimental gmail plugin that I made. It hooked up in gmail and added something that we call the people centric inbox, never released tho
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.
I used it may be once when it was in beta and then never touched. The thing is, C# as well as Java have poor startup time which becomes the biggest problem of using any of such applications.
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.
1. correct
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.
A full answer would take a whole book, but could you outline what part of the process was unwieldy, and what you had to rewrite as you learned more about the user experience?
In particular, since you are using WPF, would you have altered your prototyping process so that it was more user experience focussed?
"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."
Want to know how I know that you've never written an email client?
It looks like a nice client- What are it's distinguishing features? What needs help? What are your intentions now- To throw it out there, or keep building it?
Are there binaries?
How are you handling the Messages in-memory? I'm looking for a mail client that can handle my multi-hundred-thousand email inbox, but everyone except Mulberry tends to have a problem ;)
Looks really sharp. Kinda reminds me of FF with the tabs at the top.