[jdev] Re: The State of Our Code-bases

[Will Kamishlian]

On Tue, 31 Aug 2004 06:50:52 -0500
Ryan Eatmon <reatmon at jabber.org> wrote:
 
> The end result is that the many small projects are all incomplete, or 
> the projects that are well written and have a large user base are 
> written in a language that is not as widely accepted and so does not get
> a lot of contributions.  If those developers would all work on one 
> client then the chances of that one client becoming what everyone wants 
> is better.  At least, that's the hope.
> 
> In talking with the other leaders of the Apache, Mozilla, and RedHat 
> projects it seems that our "rotten"ness is based in the fact that we do 
> not have a central project that is well documented and easy to get in 
> and code on.
> 
> And by well documented, I don't just mean JabberDoc type docs.  I mean 
> documented source code, code guides to help explain things like NADs, 
> stream object models, karma, etc...  All of those are unique ideas, but 
> if you actually try to use them, you can easily bog down and waste time 
> trying to figure them out.

My inability to document the Jabberd 2 code base has been an continual
frustration for me.  When I started jabberdoc, I intended for it to be
half admin guide and half developer guide.  Thus, after the work I've put
in, I still see it as only half finished.

Documenting the code base for a one-person project is difficult.  I could
document the Jabberd 2 code base; however, I would need someone who could
walk the code with me (because I cannot read C). Given the scarcity of
resources on the project, anyone who could do that would need to devote
limited time that could otherwise be spent writing code or fixing bugs.  

> You can also make the argument that we should just focus on existing 
> projects.  Which I'm all for.  The only problem is that for five years 
> the jabberd v1.4 server has been open, and very few people have pitched 
> in changes.  It entered maintenance mode when Jer stopped working on it,
> and hasn't left yet.  That was the purpose of jabberd v2.0.  But now Rob
> has backed off.

In my mind, the question remains as to why these projects have been
one-person projects.  I feel that the implementation language is part of
the problem.  Lack of official sponsorship from the JSF may be another. 
Lack of financial sponsorship may be a third issue, and from what I read,
financial support is not likely to change soon.

There are issues of control and credit also, and I suspect these play a
role in managing collaborative OS projects.  I say this because control
has played a big part in my enjoyment in documenting Jabberd 2.  I get to
spend most of my time writing because I have been able to decide all
issues regarding presentation.

Did the Apache, Mozilla, and RedHat project leaders have any other advice
on how to attract and retain contributors for collaborative OS projects? 
I suspect there is a lot of accumulated wisdom among these leaders -- it
never ceases to amaze me how these large OS projects have so many active
contributors, each of which plays a specific role.

> The end result are two servers that have problems.  But in reality, most
> people aren't looking for the power of 2.0 (larger number of 
> connections), nor do they want the buginess of 1.4.  They want a simple 
> server, that they can hack on, and extend.  They want it to support 
> maybe 100 or so connections, and that they want it to be easy to install
> and get running (minimum configuration).

As much as I hate to say it, I agree that both jabberd's are deficient
with regard to what many users want from a Jabber server.  If I could
think of a way to attract developers to Jabberd 2, I'd be doing it now. 
I doubt that putting the "JSF stamp of approval" on Jabberd 2 would change
the situation.

> The only answer we can think given the track record of jabberd, is that 
> jabberd is not the project to base this on.  So start a new one, and 
> write it in a currently popular language.  With the main goal not being 
> scalability/performance, but rather showcasing Jabber and XMPP.

Could we toss in a desire to create a library of test cases and possibly
an automated test suite (as has been suggested)?  If we are trying to
attract developers to Jabber in general, I think this would help. 
Furthermore, if we were to build a reference client and server, along with
test cases for each, I think these could help make certification, as
suggested by Rachel, a reality.

> That's been our thoughts anyway...  Part of the reason we are floating 
> the idea instead of dictating requirements, is that in the end that 
> won't work.  Apache, Mozilla, and RedHat all agreed that the JSF just 
> needs to be here to foster the community.  You all are volunteers.  We 
> cannot dictate to you terms or tasks.  We can only offer suggestions and
> advice.
> 
> But something needs to change if Jabber is to grow and draw in other 
> Open Source programmers.

Agreed.  My biggest concern, as has been voiced by others, is that the
potential reference projects not be single-person projects.

Personal disclaimer: I have invested a lot of time in the Jabberd 2
project.  I am not a developer (I only play one on TV ;-) however, Python
is the language with which I am most familiar.

-Will