-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lucas Nussbaum wrote: > 1) Jabber is a difficult technology. It is very difficult for end users > to understand what it's all about. I think we lack a good documentation > for end users, covering stuff like what is a Jabber server, a JID, can I > communicate with users on other servers, etc ... Or I haven't found > it yet. If such a documentation exists, it would be interesting to start > a translation project, so Jabber-related websites could use localized > versions.
Does email have good documentation? If you're online, you know what email is. Why? Because any ISP will give you at least one email address to use, and then name off a couple of email programs to use and how to set them up. If an ISP gave you a Jabber account to use, presumably it'll be the same as your email. So JIDs and what is a Jabber server wouldn't need to be documented for the end user. So why aren't ISPs giving out Jabber accounts yet? That's gotta do with the state of our code-bases. An ISP isn't going to setup a buggy, incomplete, and hard to manage server. They need the equivalent of an Apache, something they do setup and use. > 2) The number of clients/libraries/servers. For somebody coming to > Jabber, it is very difficult to choose a client. There's no comparative > charts saying "this one does this, but doesn't do this, etc ...". There's > http://www.jabber.org/software/clients.php, but I find it quite useless. > There's the same problem for libraries. There are for example 4 > different libraries in python (jabberpy, xmpppy, pyxmpp, twisted). How > do they compare with each other ? Tell your friends I use this client. Set it up for them. Get them to use it. If they like it, they won't go looking for a new one. If they do go looking, maybe they'll find something better or worse. Word of mouth should be good, except for the isolated adventurer. Though client reviews won't hurt. Contribute them to Linux Journal or something. It would get the word out too which results in people doing what's described in the above paragraph. > B. do something like the Apache Software Foundation : best > clients/libraries/servers should be endorsed by the JSF, so users would > be able to choose between a restricted number of > clients/libraries/servers. Of course, criterias for the selection should > include things like : - the code must be documented. > - the licence must be free. > - stuff like a public CVS, a bugzilla, etc ... must be available. See jabberstudio.org. It could be improved to point people towards specific projects. I know SourceForge.net does more than just host projects (ie: Most active, popular, etc.). > All those ideas are non-technical work. I think that technical work has > proven to be unsuccessful with solving the jabber community problems. I'll beg to differ on that point. The lack of technical work is the problem. If tech work was unsuccessful, stpeter's mantras wouldn't all be "...more code". They would be "Less code, more process". Anti-mantra #1. :-) - - Nolan - -- http://www.semanticgap.com/people/sneakin/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFBNrQ8huPszQVSPEARAhHKAJ9NhLwWuQTYjXJ+0zXxgcPaZSL/FACgj7Tt LO4XNwjAfw3+lXWMzGT/FOI= =/Fle -----END PGP SIGNATURE----- _______________________________________________ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
