You can release the source without offering it to be fully licensed. I actually think you might find the closed sales model will result in a lower total income. A model I strongly suggest trying is to offer the code for people to see, help with, etc. Require a license fee (if that’s your idea) for using the software, make the initial license fee very low and be very generous in your trial offering. Ask power users to donate and ask users to donate for feature additions (use a web system for tracking feature requests and allow people to vote by pledging dollars towards new features).

There are tons of email clients out there, most of them have a very small user base or are one of the big ones, you’re trying to compete in a very full field with no clearly best-for-everyone client.

I have spent a lot of time evaluating mail software for every platform and not one has a superset of the best features. I currently use kmail (x11) on OSX, but this is way, way hacky. I love some things about OSX Mail.app, but the closed nature of it and the lack of published API means I can never really feel comfortable in it. It is also missing some features I consider critical: send queue, manual mail filters, arbitrary key assignments…

But every client has its problems. The idea that you’ll be able to pull this off yourself and make it a commercial success out of the blocks while you’re in school seems… ambitious in a “this is never going to happen” sort of way.

Whoever has been telling you closed source = profitable is probably thinking of larger projects. It is my firm belief (and experience) that small projects do better asking for donations and remaining more community-positive. But, either way, good luck. I’m currently having to make some very hard decisions about email clients because not both has the features I want and actually runs well.

No significant news. School is beating me up real bad right now, my hardest semester so far. As a result, my time has been limited.

- libetpan is open sourced.
- etpan-ng is opened source.
- etpanX is opened source.

- libetpan has some contributions (maybe once a month now).
- etpan-ng had mostly no contributions
- etpanX had no contribution until now

To get contribution, projects at least have to communicate much.

And it hasn’t gotten much feedback on MacUpdate/VersionTracker recently.

You hit the nail on the head. Most open source projects, are either dormant, abandoned or are worked on by one or two key developers. Eventually, Kiwi may have had a few people submitting patches, but I haven’t seen any open source Cocoa apps go beyond that. Especially in the early stages, it is normally only a handful developers. Either way, I’m going to be doing the brunt of the work, and I figure I might as well charge a little money for all that hard work.

Open source is not a silver bullet as Nick mentioned.

That’s one motive for open sourcing code, but I’m not convinced it’s the reality in most cases. I think a lot of people thought that it must be after reading some of the persuasive essays put out by Eric Raymond. I’m sure esr convinced himself, because he wanted to believe it: I’m not sure it’s the reality. In practice, most open-source projects close down again pretty quickly. Above and beyond that, I’d like to see reliable statistics on how many successful projects actually get substantial contributions of patches–unless they have good connections with Sun or IBM or someone like that prepared to provide coders. I’m sure some long-running, high-profile ones do, but I’d like to see some proof that that is generally so. One Pine doesn’t make a forest.

So far as mail ciients on the Mac go, there is already a client that is both built in the modern way with Cocoa and is open source. I’m thinking of Ludovic Marcotte’s GNUMail, which runs on both GNUstep and OS X. Now there must be many developers out there who know Objective C and Cocoa, but I doubt he’s overwhelmed with contributions of code. Look at the frequency of releases:

http://www.collaboration-world.com/cgi-bin/project/release.cgi?pid=2

And the OS X version tends to lag behind the GNUstep one, too.

I suppose Matt’s making his source code–or rather all of his source code–available may have had some advantages, but I’m not going to moan at Matt or avoid his product if he chooses another development model, because I don’t think open source is the magic silver bullet people think it is, and I suspect it will be he doing the heavy lifting whatever development model he chooses.

I was also wondering about the possibility of selling Kiwi if it were open source, though my general hunch is that it would be more financially risky for Matt than it being closed source (at least initially). Yet being being closed and advertised as “commercial” software has its own financially-influencing service/support issues and responsibilities.

It’s the quality and support of a product that usually matters much more to my purchasing decision than whether or not it’s open or closed source. Sure, being open source can definitely make a difference on quality/support but doesn’t imply it’s always advantageous as some people seem to naively believe.

What product perception does Matt want Kiwi to have and which kind of customers does he want to support?

And that included selling copies for Windows, Linux, and Solaris in addition to Mac OS.

I think Mulberry’s achilles’ heel was its complex and unattractive UI and lack of integration with WebKit.

Mulberry certainly begs for appearance and usability improvements. It’s easy to see how that contributed to Cyrusoft/ISMET being challenged to attract new customers.

Lack of native HTML message viewing has been increasing relevant though I don’t remember anyone ever specially caring that it be WebKit-based on OS X. Not that anyone would want to implement it without WebKit nowadays, of course.

Maintaining reasonable multi-platform consistency seems to have been both a benefit and curse for Mulberry. Unfortunately OS X has come up short on a few of the platform-specific features that have been implemented. No support for AppleScript (or some other extensibility language) is unfortunately, making the emphasis on “closed” in closed source even more apparent.

Still seems a bit early to seriously speculate what broader benefits becoming open source might have on Mulberry’s future on OS X and other platforms. I know a few folks are specifically interested in fixing bugs relevant to their own usage that may not matter to anyone else.

If you can offer a good IMAP implementation *and* those things you might just sell enough copies.

GyazSquare is the only business I’m aware of selling an OS X e-mail client, GyazMail, as its only product. Mailsmith and PowerMail, on the other hand, aren’t the only products sold by their respective companies. I don’t know anything about GyazSquare but suspect whoever’s behind it has other sources of income/wealth besides GyazMail sales.

I’m kind of confused by Matt’s “Instead of having a part time job during school and working on Kiwi, I can hopefully get my spending money from selling Kiwi and focus completely on it” objective in his response to Dan. How do you completely focus on something that’s only generating spending money and apparently during school?

Sure, people could download the source without paying, and compile it. But most people wouldn’t be willing to compile it, and others would be happy to support your efforts.

If you offered a binary download of the program for $X, and still made the source available, I’d be truly surprised if the amount of money you made was significantly less than if the program were closed source.

That would be a huge advantage for the program’s development. I hope you do get the sales.

it’s interesting that Mulberry, another email client that specializes in IMAP, has just completed its move in the opposite direction:

http://lists.mulberrymail.com/archives/mulberry-dev/2007-July/000046.html

It seems this was, effectively, caused by Cyrus Daboo’s being unable to sell enough copies of Mulberry to make a go of it. And this was despite the fact that many universities liked the client and made it their default for users–AFAICT, because having such a good implementation of IMAP, and also ISMP and ACAP, it allowed them to offer service they couldn’t otherwise have except with proprietary solutions.

I think Mulberry’s achilles’ heel was its complex and unattractive UI and lack of integration with WebKit. If you can offer a good IMAP implementation *and* those things you might just sell enough copies.