There is no problem with competitive packages, but we want to
avoid pollution with 10 template classes, 7 different mail classes,
and 3 different layers for databases doing the same only with
different function names.
First of all, do a reality check: Why do I want to commit a new
package? Really bad answers are "To see my name in
PEAR" or "I didn't understand the API of the existing
class".
A good reason for a new class is often, that you are missing a
function, behaviour or speed in an existing implementation. In
this case, you should take a look at this class, if it possible
to extend this class. If not, then you have a good reason to
commit a new class. "If not" means, it isn't possible
to add the required functionality without changing the basics of
this class.
If you write a new class, try to keep API compatibility with
existing classes as far as possible! If it isn't possible to keep
the class compatible himself, try to create a wrapper class to
keep compatibility. Don't care, if this wrapper needs a lot of
time or memory, a wrapper class only has to keep compatibility and
make migration easier.
Committing a competitive class has to be announced on the PEAR developers mailinglist!
