Candidates for maintaining DA, step up! (was Re: protocol error)

I feel this is fair enough:

Due to my recent obligations (college tightening up, starting a new
business around OSS software and agile business), I feel I can no longer
maintain Directory administrator to the point I wish I could.

It's been great working with everyone who has contributed (I wish I had
the time to include everyone here, but every user has a copy of the
CREDITS file ;-).  99% of all e-mail volume I ever got has been positive
or more than positive, and the contributions that have come through have
made an enormous difference to me and to the rest of all the users (I'm
counting tens of thousands of downloads, and I cannot count the
Conectiva and Mandrake users who are using it!).

Fortunately, OSS software gives me choices.  Since I'm not about to let
this project die, because it's incredibly useful to lots of people, I
have chosen to let the community go forward with it.  It's a choice made
with sorrow, but a choice that I think will ultimately benefit us much
more than the current situation.

So, in orderly fashion:

1. I extend my most intense gratitude to all of you who have helped,
from the smallest bug report, to the largest patch, through financial
support, enormous user patience and loyalty, and willingness to cope
with several quirks in the software releases so far.

2. I want whoever is willing to maintain Directory administrator to step
up to the plate and say "I'm willing!".  The following will clarify what
the maintainer(s) is(are) supposed to do, so everyone will know what the
maintainer(s) is(are) getting into ;-): (no that's not a beard or a
split chin)

a) Integrating patches from developers around the world.  There's a
volume of 2 patches every 20 days, plus the backlog of like 10-15
patches that need to be integrated.  This includes polishing patches or
asking the users to change some code in their patches so they can be
more easily applied.

there's a:
GNOME 2 patch
SAMBA patch
very interesting small patches to correct bug fixes

b) Maintaining the Web site.  It's a static PHP website, which resides
in a server space the Open-IT project has kindly lent.  I'll speak with
the server admin to see if its continued use is possible.  The website
has Analog reports enabled and every week the Analog report is generated
and a link mailed to the Web site maintainer.

c) Publishing releases in the web site.  The sourceforge project page is
not used for the releases.  Releases usually include Red Hat and
Mandrake RPMs, which are an integral part of high quality software
releases, and sometimes if the release is worth it, uploading to contrib
servers and talking to distribution packagers. Maintainers may choose to
split responsibilities in this respect in order to diminish the
workload.

d) Maintaining the RFE and patch managers in SourceForge.

e) Maintaining the mailing list. It's unmoderated but closed. The volume
of spam is virtually nil.

f) Improving the code.  The code is fairly clean, and everything has
been compartmentalized and structured, although there are some files
that have horrible functions.  Just a byproduct of my laziness and C's
ability to obfuscate simple things.


To do a), I'll turn over the latest source to the maintainers.  The
patches are in the SourceForge server.  b) will require me to talk to
the server admin so the maintainers can get a web account, or perhaps
moving to SF for web hosting. c) nothing from my part ;-)  d) will
require me to assign ownership of the project to whoever chooses to be
the lead maintainer. e) I'll turn over the management of the mailing
list and the master password. f) is a no brainer: if you like to code,
you'll be diving in easily.  there are no large entry barriers.

To develop DA, knowledge of C, GNOME libraries (preferably version 2,
since someone did the amazing job of patching DA so it will work with
GNOME 2), and the LDAP libraries.  Evidently, whoever chooses to
maintain DA can port DA to whatever software architecture he chooses,
but I encourage to reuse as much of the code as possible.

All in all, this will take 10 hours a week for only one maintainer.  A
group of people can make the workload much more palatable.

I cannot turn over the copyright of the code, due to the multi-author
nature of DA, but this is good: it'll ensure that DA stays open source. 
Naturally, whenever someone contracts me to do enhancement work to DA,
I'll contribute whatever changes I do as patches to the main project.

I cannot demand anything from the potential maintainers, but I ask
politely that everyone involved in improving DA keep at all times in
mind how important software quality is.  It's the really small details
that make the difference: a misspelling here, a quirk there, odd
behavior over there, a button that's been misplaced, turn users off. 
They rob confidence from the project.  I've tried so hard to keep the
quality up in every release.  This is one of the core values I'd like
the community to preserve.

Finally, I don't want to choose only one maintainer, or for that matter,
choose at all.  Whoever is willing to contribute to the project on an
official basis, will be welcome.  10 heads think better than only one (a
thing OSS proved solidly).

This is turning into a will, so I won't extend myself any further.   
Again, thanks a lot for everything you've done for me.  It's been a
great ride.

(I won't disappear, trust me)
-- 
    Manuel Amador
    R&D Chief
    Amauta
    +593 (9) 847-7372


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/