Friends, Plugins, Countrymen - Lend Me Your Ears

[Paul J. T. <cap...@sq...>]

Sorry, looks like I wrote another book and emailed it to the
development list. Please be patient and actually read this whole
thing.

Anyways, I thought it was about time that let everyone know the
strategy that I am taking with Plugins, the Core, and so forth.

As you HOPEFULLY read[1] in the pages I published on the website, I
think that Squirrelmail is the BEST Open Source webmail client that
currently exists.

In order to keep that place in the Open Source webmail playing field,
however, I am certain that Squirrelmail has to embrace an expanded
set of priorities that will lead us onward.

===========
~ HISTORY ~
===========

In the beginning, the Squirrelmail that Luke and Nathan was targetted
at a very small audience. That audience was limited to those who were
specifically looking for a simple webmail client that would run on
cheap hardware and simple web browsers.

Well, a funny thing happened on the way to that goal: they managed to
accomplish it in way that also served the needs of a MUCH MUCH MUCH
(times infinity) wider audience. Their original expectation was that
Squirrelmail would be a webmail client used as backup when someone
did not have access to their desktop email client. In fact, Luke was
once very shocked to discover that I actually use Squirrelmail as my
sole email client for my personal email account. And I suspect that I
am FAR from alone in this ballpark. (Maybe someday we'll do a survey
to prove this point...)

According to the tenets presented in "The Cathedral and the Bazaar",
a TRUELY awesome Open Source project is one that ends up having uses
outside the scope of that originally intended by the authors.

Well, this is exactly where Squirrelmail is and is exactly why I
think it is so great. We have done a great job building an webmail
client that can not only be used for the needs of the original
audience, but also an excellent solution for webmail users across the
board.

=======================================
~ What This Means for Development Now ~
=======================================

So, you might ask: "What the heck does this have to do with current
Squirrelmail development???"

Well, in a nutshell, Squirrelmail must reaccess its principles and
goals. It must take a new look at what we are all about and where we
want to go. To do otherwise would be to, effectively, ignore the
group of people that have accidentally become our primary audience.

Now, if you read my web pages[1], you would know that I find it of
UTMOST IMPORTANCE that we never violate the original tennets of the
Squirrelmail project. However, I feel that our goals can be expanded
beyond those original tennets in such a way that allows us to
accomplish more without breaking them in any way.

So, with that all said, here are the "New & Improved" principles[2]
of Squirrelmail, as I feel that they should come to pass. You will,
of course, recognize some of them.

  1A: Squirrelmail must be easy to install and configure.

  1B: Squirrelmail must have low server requirements, allowing
      it to be run on low-end hardware with just a basic Apache
      and PHP installation.

  1C: Squirrelmail must have low client requirements, allowing
      it to be used on low end browsers without REQUIRING any
      fancy JavaScript, or so forth.

  2A: Squirrelmail will provide a complete webmail application
      that can be used as an individual's primary access point
      to email.

  2B: Squirrelmail will maintain an architecture that will
      flex to the needs of a variety of system administrators,
      server configurations, and web browsers while maintaining
      efficiency and speed.

These principles can be encapsulated in kind of an old chinese
proverb sort of way. You know, this kind of thing:

  Rule #1: The master is always right
  Rule #2: When the master is wrong, see rule #1.

No, I am NOT saying I am the "master" and am always right. What I am
saying is that principles 1A, 1B, and 1C above take precendence in
all cases. The chinese proverb part is that when principles 2A or 2B
violate 1A, 1B, or 1C, then 2A and 2B lose out. Plain and simple.

With that "algorithm" in mind, I think that these new principles can
be very effective and leading Squirrelmail on to a new, even cooler
future then we have today.

One last comment on the principles above and the way they work. As an
individual, I see the second set of principles (2A and 2B) to be JUST
as important in the long run as the first (1A-1C). Of course, they
should never override the first. That is one of the reasons that I
feel that I am a good choice for the current leader of Squirrelmail.
Even a better choice, I believe, then Luke would have be at thia time.

Squirrelmail needs "new blood", as Luke told me on the phone last
week, if it is going to press on. My vision for Squirrelmail
(basically, the revised set of principles above) will help that
happen by putting a priority on things that had not before been
thought of as a priority.

Along that lines, one thing that I will not allow is for the first
three principles to be used as an "excuse" for not allowing things
into the core.

The heart of the first three principles is NOT to keep Squirrelmail
featureless and stripped down. Rather, it is to keep Squirrelmail
running well on low end servers and low end browsers. This can be
accomplised and still provide a complete, full-featured webmail
client.

==========================================================
~ How these Principles affect Development & Squirrelmail ~
==========================================================

There are two main ways that these new principles will affect the
future of Squirrelmail as a webmail client.

First, principle 2A will affect Squirrelmail NOW as we continue work
on Squirrelmail 1.2.

Previously, Peter had been saying that 1.2 would be coming out any
day now. Well, after 1.2 comes out, the 1.2 series will follow the
intelligent rule of simply existing for bugfixes and the like. New
features will NOT find their way into 1.2 after the initial release
because that is what the development series is for. Our users should
be able to expect that they can upgrade to the next version of a
stable release without things breaking. This can not be guaranteed if
we keep throwing new things in at our every whim.

With that in mind, I looked at the status of 1.2 a week ago, I
realized that I would be embarrassed to call it a new minor release
of Squirrelmail. Sure, there were some nice improvements and bugfixes
in there (collapsable folders, for instance). But, there seemed to be
a large number of things that were just plain missing. This included
things that people tried to get into the core that had been resisted.
This included code that just didn't work right because it was badly
written. In short, I did not think it was up to snuff with the
quality that we should be delivering.

So, for the sake of the Squirrelmail name, I decided that we need to
get some more work done on Squirrelmail 1.2 before it saw the light
of day. To save the length of this email, a little, I will write an
additional message to the list discussing the development priorities
and goals of Squirrelmail 1.2.

Secondly, principle 2B will really raise it's ugly head into
Squirrelmail development during the coding of Squirrelmail 2.0.
Basically, 2B has to do with the fact that the general architecture
of large parts of the Squirrelmail code is non-existent. It is very
spaghettied together and, in some places, is suprising that it even
functions.

No, this is NOT a slam on the Squirrelmail developers. Writing a
webmail application is a HECK of a project in the first place and I
am both suprised and impressed with how well the team did in getting
to this point. However, to quote Luke again, they were just throwing
it together when things started out and just did the best they did to
get things working.

As with the life of any good software project (open OR closed
source), it is time for some rewriting. (Or refactoring, as I prefer
to call it)

As far as Squirrelmail 2 is concerned, we will be working (much as a
part of our sister project, Zookeeper) to write well structured and
flexible API that will make giant leaps forward in the general
cleanup of the Squirrelmail code. Furthermore, we will be working
through the php files that handle the internal logic and UI
presentation for Squirrelmail, working hard to structure these better
in a way that does a better job of seperating logic from presentation.

(For those interested in putting different frontends and/or templates
onto Squirrelmail, this should catch your attention as it is the
first in a several phase process to even make that kind of option
available for Squirrelmail.)

Anyways, that is it for this CHAPTER of the book. Stay tuned for the
next one in 5-15 minutes or so as I outline our development
objectives for Squirrelmail 1.2.

Thank you for reading this far... :)

[1] http://www.squirrelmail.org/wiki/index.php?page=SquirrelVision
[2] http://www.squirrelmail.org/wiki/index.php?page=SquirrelPrinciples

-- 
Paul Joseph Thompson
cap...@sq...
AIM/Yahoo/MSN IM: Captain Bunzo
ICQ Number: 38801719