SquirrelMail is a standards-based webmail package written in PHP. It includes
built-in pure PHP support for the IMAP and SMTP protocols, and all pages render
in pure HTML 4.0 (with no JavaScript required) for maximum compatibility across
browsers. It has very few requirements and is very easy to configure and
install. SquirrelMail has all the functionality you would want from an email
client, including strong MIME support, address books, and folder manipulation.

The founding principles of the SquirrelMail Project were aimed at an audience
that was looking for a webmail application that would run on low end servers for
clients with simple browsers and a small set of expectations. Well, the
SquirrelMail user base has swollen greatly beyond the expectations of the
original SquirrelMail developers. Much of this new audience often wants and
needs a webmail client that will be much, much more.

In order to meet adequately the expanded needs of our current client base, the
basic principles of the SquirrelMail Project must be expanded to include several
additional items. The SquirrelMail Project goals are:

SquirrelMail must be very easy to install and configure.

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

SquirrelMail must have low client requirements, allowing it to be
used on low end browsers without requiring any fancy JavaScript, or
so forth.

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

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.

An important note is that the principles should be expanded and not replaced.
This means that the original, founding requirements of the SquirrelMail project
must never be overlooked as new and cool things are developed. Rather, special
care should be taken to assure that both the new and the old is respected as
development progresses and the capabilities of SquirrelMail are extended.

JavaScript

Some people argue that JavaScript isn't a fancy or heavy requirement anymore,
and that the project goals should be revised. Well, JavaScript is neat and all,
but some clients, such as lynx and links, lack support and will probably never
get it. However, most things that can be done with JavaScript can also be done
at the server side, and any JavaScript should only increase usability, not
functionality. JavaScript isn't supposed to be anywhere in HTML except where
JavaScript-aware browsers look anyway (i.e. in handlers for intrinsic events
such as onclick, onload, and onmouseover). It's still important
to be able to use SquirrelMail with non-JavaScript-aware browsers. If you detest
lynx, think PDA, WAP and so on instead.

JavaScript code runs in the client browser but is not a "sandboxed" technology.
This means that client-side JavaScript code doesn't have near the restrictions
placed on it in regards to accessing local files and changing browser behavior
as do more security conscious technologies like Java. Web developers should
avoid using JavaScript in anything but the most trivial roles as site visitors
who value their privacy and security may have configured their browser to ignore
all or part of a page's JavaScript code. In addition to the myriad security and
privacy problems with client-side JavaScript, JavaScript code often introduces
browser dependencies due to slightly differing JavaScript parser implementations
in various web browsers. Microsoft's web application development environments
actually seem to take advantage of these incompatibilities to lock users into
Internet Explorer.

Web application developers are encouraged to perform all input manipulation in
server-side code or, if it is absolutely necessary, in client-side code that
runs in a protective environment or "sandbox". Input validation should always be
performed in server-side code despite the temptation to do so in client code in
order to leverage libraries that allow "easier" client-side data validation.
Google "Cross Site Scripting", "SQL Injection", and "client-side trust" for an
explanation of the pitfalls associated with weak client-side input validation.

This doesn't mean that it's not allowed to make use of JavaScript in
SquirrelMail or its plugins, but as much of the functionality as possible
mustn't depend on it. Having extra JavaScript features is allowed if they
respect the users' JavaScript preference setting.

The SquirrelMail Project Team is organized as four subteams, in order to get
more good stuff done in a more organized fashion. There is no official project
leader. Major decisions are more of a consensus between the team leaders. Each
subteam has a leader (or two), who is responsible for coordinating the
activities of their team, answering questions, and helping new
developers/contributors get started. Even though we have team leaders, all
project members are supposed to help out with the various tasks.

Our most valuable resource

"If you treat your users as if they're your most valuable resource, they will
respond by becoming your most valuable resource"

Good projects in both the open source and commercial world succeed because of a
whole community of people who are involved in the project, not just because of
the small set of individuals who actually did the tinkering with the code. Open
source is power! Let's look at an example.

A short case study

"Who in the computer world doesn't know what WinAmp is? WinAmp, as far as I
can tell, is the Windows MP3 player that was at the forefront of the
intersection between the world of Windows users and the emerging standard of MP3
for digitally recorded audio. What about WinAmp made it so successful? Was it
just because the program was the greatest thing in the world?

No, I think not. In fact, from everything I have ever seen, there are some
really annoying things about the program. What made it so successful, in my
opinion, is the community that grew around it.

When I first saw WinAmp, it was on a college campus. My computer only had
Linux on it, so I did not install WinAmp. However, I noticed that it seemed
everyone in the dormitory seemed to have WinAmp installed. More than that, they
really were very big on the program. They loved the skins. They IDENTIFIED with
it.

What is that? That is community. That is a person feeling that they are no
longer just a user of the program, but part of the program itself. No, I am not
talking about some new-age "being one with the program" thing here. I am just
talking about the difference between feeling as if you are a part of something,
or just an outsider."

What does this have to do with SquirrelMail?

The community of SquirrelMail itself is worth much more than just the sum of the
developers. Just like a bright flashlight is dwarfed by the brightness of the
sun, the SquirrelMail community must shine much brighter than the SquirrelMail
development team itself. If it doesn't, SquirrelMail will not survive. After
all, developers are real people. Real people graduate, have kids, get married,
get busy, or get hit by ice cream trucks. Life goes on. The strength of the
SquirrelMail community itself guarantees that there will always be life beneath
the surface as it will continue to feed the strength of the development team
itself.

The SquirrelMail Project Team

The SquirrelMail Project Team isn't just the developers. The change from being
the SquirrelMail Development Team is to make that point more obvious. There are
a lot of other peoples helping out too. Here are some examples:

Translators: A good percentage of the SquirrelMail end users don't
understand English. The SquirrelMail translators work hard to make it so that
people who use other languages still can use SquirrelMail. Who cares about some
fancy new feature that a developer implements - if it is only available in
English, it can not be globally used.

User support: Thank goodness for our precious user support people. These
people patiently, repeatedly, respond to people's inquiries on the SquirrelMail
mailing lists. They often answer the same questions over and over, and are very
patient and consistent with their help. Without these people, where would we be?

So, in short and again, the point is that SquirrelMail is simply a lot more then
its developers. We should all try to make the SquirrelMail community stronger,
and the rest of the Project Team is just as important as the developers. We can
only succeed by the time and effort of the team as a whole.