In the next 36 hours, I will finally be releasing Pegasus Mail v4.02. The original plan was to release this back in April and get going on v4.1, but as so often happens, circumstance has intervened and once again I am doing a release later than I wanted.
This message, then, serves three purposes:
1: To tell you that v4.02 is imminent.
2: To apologize for the delays in the release and explain as best I can why they have happened.
3: To tell you what I plan to do to streamline things in future.
Number 1 I have already done (hey, that rhymes!). As for point 2, I wholeheartedly apologize for taking so long to get v4.02 out; it contains over 400 bug fixes, some of which are quite important, and I regret having inconvenienced my loyal user community by delaying these
corrections.
So why has it taken so long to get v4.02 out? There are many reasons...
First on the list is a nebulous concept called "user expectation". These days, users' expectations of what a software release should be are sky- high compared with what they were even five years ago. As a result, the
actual process of releasing a new version has itself become massively time-consuming, with repetetive testing regimes and a level of nit-picking that would have been unimaginable when I started writing the program. Some of the 400 changes in v4.02 are so small that practically nobody will consciously notice them, but they are all part of a much larger concept called "polish". The things that lead people to criticize a program for "looking dated" or "being ugly" are often as tiny as an item being a pixel out of alignment here or there in a dialog, and they all have to be fixed as part of making a better whole.
When I started writing Pegasus Mail back in 1989, I used to yearn for every release - it was exciting, because I got to show people the cool new things I'd done. These days, I dread release time almost above all else, because it's arduous, tedious and seems to be interpreted by some an open invitation for criticism and complaint (sic transit gloria internet). As I am a (relatively) normal human being, then, the actual
process of making a release now often feels in itself like a test of character.
The second source of the delay is simply a matter of resources. Irrespective of the outcome of the now largely-irrelevant and futile DoJ case against Microsoft, the simple reality is that Microsoft destroyed the well-established marketplace for competetive e-mail packages when they started bundling Outlook with Windows; that damage is done, and it cannot be reversed. As with all developers, Microsoft's practices have impacted on me directly, but I at least have the advantage of being smaller than most. In the course of the last two years, I have gone through massive restructuring here, the last phase of which was the shedding of my final staff member in October last year. By reducing my overheads to almost nothing, I have ensured the ongoing survival of the system, but at the cost of having to do more of everything on my own.
So, just like it was in 1993, I now sit alone in my office doing all the work
- writing the code and manuals, processing the orders, handling the licensed technical support... If it weren't for a group of incredibly dedicated volunteers who help with the general technical support, I simply wouldn't be able to continue. As it stands, I am spread way too thin, and an inevitable side-effect of this is that I am no longer doing anything as efficiently as I might. Consequently, releases are taking longer, even over and above the technical reasons I described above for the delays.
The situation is complicated. I work six or often seven days a week, and haven't personally had more than 5 days' holiday in a row for more than three years now... Without staff, it's hard to see how that can change, but the financial situation is now such that although I believe I can continue to operate indefinitely at current levels, I cannot afford to hire staff, nor see any prospect of being able to do so.
The final reason for the delay in getting v4.02 out is because it's a major watershed release. In many ways, it's what v4.01 should probably have been - it's been through at least fourteen betas, which is quite amazing
considering how little different it appears on the surface from v4.01.
V4.02, I believe, finally completes the transition of the system from v3.x to v4.x and gives a genuinely solid base for the development of the major new functionality that will be appearing in v4.1 later this year.
So then: what am I going to do to try and reduce delays like this in future? I have a number of ideas that I thought I would share with you.
1: Patch releases. One of the reasons why releases are so difficult is the amount of co-ordination and testing required to produce a fully-integrated installer archive. Starting with v4.02, I plan to add a "patches" section to the downloads page on our web site where we can make available cut-down interim versions of the program that fix specific problems. These "cut-down" versions will be effectively unsupported, and will require some technical competence to install and use - i.e, we'll probably just give a ZIP file with a very terse readme describing the patch. There will be no installer, and no specific technical support available for patches, but they will fill the gaps between major releases.
2: Public-access betas. At times when we believe the program is stable during the beta testing and development process, my beta test team and I may occasionally release a public beta for people to try out. Public betas will be available on the same "patches" page on the web site, and will be completely unsupported - people can use them at their own risk if they are interested in seeing where we are going.
3: Smaller bites. Starting with v4.1, I intend to work on single features until they are complete, then release a version of the program at that point. This should mean more regular releases with fewer new features in each, allowing a less jerky transition for the user base. Ideally, I would like to aim for three significant releases a year, at approximately four-month intervals.
4: Opening up parts of the development process. While I'm still not willing to contemplate going Open Source with Pegasus Mail, the reality is that I am stretched too thin to be able to cope with the full range of demands that face modern software - things like import/export utilities, PIM interfaces and so forth. I would like to open those parts of the system to responsible developers or development teams on a collaborative basis. What I have in mind is that people with expertise in areas like Palm Conduits or MAPI interfaces will work closely with me to produce a module that is integrated into the program as a standard feature, or is supported and distributed as a standard utility from the official web and FTP sites. As with translation, this is not a trivial thing, and only genuinely committed developers would probably find this rewarding, but if you think you have what it takes to produce a standard part of the system, please contact me directly.
Well, that was wordy, wasn't it... If you've read this far then I admire your stamina.  Seriously, though, the last couple of years have been quite hard and I won't deny that I've had some major morale problems
at times, but I've come through them and am now looking forward to working on exciting new things for v4.1. Thanks for your support, and I hope you like v4.02.
Cheers!
-- David --
------------------ David Harris -+- Pegasus Mail[ Dit bericht is gewijzigd door op 31-07-2002 @ 18:02:01 ] |