Documentation, I thought, is the Achilles Heel for open source.
It's baked into the process. Great coders volunteer to write great code, but documentation is a go-to-market process, and when you're giving stuff away that's not part of the strategy.
There are some nice features here. It transfers your old mail folders, the address book, and the process for installing passwords is neat. But I already had a junk mail filter and Thunderbird's kept getting in the way. I spent an entire morning trying to get things working to where they had been with my old client.
When I went to look for help, I was lost. Since open source help is based on input from users, a new programs help files are sparse. And there won't be a "book" on Thunderbird for some time, if at all.
I've worked on both manuals and books, so I know how this goes. The manual is done alongside the software, and you can't go beyond documenting features as they're added (and dropped). For the book, a writer tries to do things with the software and describe that process in a clear way. You need finished code, and a finished manual, to find the tips and techniques of a new program.
So, for the thousands who "rushed the rail" to get Thunderbird on its first day out, there's bound to be some disappointment. (I backed off the program entirely and went back to my old client for a time.) The masses really need to wait a few months for what I call the "gamma test"-- the use of the program by users who know what they're doing-- to be complete.
But that's not the way the process works. Thunderbird is out now, it's exciting now, and in six months people who need it may not know about it, while those who get it now may already be disappointed (as I was).
So maybe I was wrong. Maybe it's not the documentation that's the problem for open source.
Maybe it's the go-to-market strategy.
What do you think? How can we make the move to open source applications easier for complete morons like yours truly?