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

[Richard Dobson]

> But that is exactly the problem.  The JSF does not have resources to burn. 
> Unlike the Apache project which seems to have a lot of developers 
> contributing to one code base, we have a handful of developers 
> contributing to individual projects.
>
> 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.

Problem is that the clients that are in development are probably quite close 
to the heart of those developers that made them as something "they made", 
and I dont see many of them abandoning all that work they have put in to 
work on something different that is not "their baby" as it were. Also even 
if there were a main project new clients will still spring up as people may 
prefer a different language or not agree with how that main project client 
was designed and think they can do better, having yet another client even 
one sponsored by the JSF is not going to solve this IMO. Personally I dont 
see the fact we have many clients as a "rotten" or bad thing necessarily, or 
the fact that there are lots of abandoned code/projects they are all facts 
of life in open source development, how many abandoned projects do you think 
there are generally?, i.e. this is not something that is unique to jabber 
development and so is not something I see much point in worrying too much 
about.

> 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.
>
> 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.
>
> 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).
>
> 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.

Even if we start yet another jabberdpy project personally I dont see it 
ending up any different to jabberd1.4 or 2. IMO its far better to try and 
put the limited resources we have into continuing the development of the 
existing projects, rather than stretching the limited resources we have on 
yet another server that wont fulfill everyones needs anyway, before we think 
about starting any more projects it would be best to get a tally of the 
people willing to significantly contribute to such a project.

> 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.

IMO the lack of documentation is the primary sticking point which is 
probably putting people off contributing, personally I dont really see how 
new projects are really going to help the situation in any way, but thats 
just my view on things, would love to be proved wrong.

Richard