[jadmin] Advertising xmpp

[Daniel E. Renfer]

If anyone wants to take up the challenge to build a community to work on 
this and inform non-technical users about the benefits of Jabber/XMPP 
both spreadjabber.org and spreadxmpp.org are available.[1]

I would gladly put a button on my website linking there. I'm sure many 
others would as well.

[1]: at the time of this writing :)

Daniel E. Renfer
http://kronkltd.net/


Samuel Penn wrote:
> On Saturday 05 January 2008 14:29:36 Sander Devrieze wrote:
>> 2008/1/5, Samuel Penn <sam at glendale.org.uk>:
>>> On Saturday 05 January 2008 12:48:14 Sander Devrieze wrote:
>>>> 2008/1/5, Samuel Penn <sam at glendale.org.uk>:
>>>>> A small list would be better than a big list
>>>> Why?
>>> Is there an advantage to a big list?
>>>
>>>   * It's harder to maintain.
>> Harder is not impossible
> 
> Agreed, but if resources are scarce it may be undesirable unless
> the advantages are large.
> 
>>>   * If you list lots of small unreliable servers, people who
>>>     choose them are likely to get a bad impression of XMPP.
>> Unreliable servers should not be on the list; it's not impossible to
>> add such measures, only hard ;-)
> 
> I seem to recall seeing uptime stats for servers somewhere, but can't
> find it now.
> 
> It's not just one list that needs to be maintained though - it's many.
> When a version of a jabber client is packaged, the developers need to
> ensure that the list they use is uptodate. A mature client may be
> stable for a while, and get chosen for inclusion in an OS distribution,
> which possibly means that the list actually used by users may be a
> year or two out of date. That's assuming the developers remembered to
> grab the latest version of the list before building a release of their
> client.
> 
> The obvious solution is to have a dynamic list stored on a server, which
> a client can request, with a smaller backup list built into the client
> in case the server is not available. This requires getting agreement
> from client developers to make use of the list however.
> 
>>>   * It may be confusing as to what the differences are between
>>>     the servers, when really there isn't any.
>> How can this be confusing and how can this confusion be fixed?
> 
> If I'm presented with a list of a 1000 servers (say) to choose from,
> I'd want to have some idea as to how to make a choice. I'd like
> information on which are the most reliable and support the most
> services. However, if I know nothing about XMPP, then I may not
> even be aware that some servers might support more facilities than
> others. An uninformed decision isn't really providing any benefit
> to the user.
> 
> Admins and developers are actually in a better position to decide
> why one server is better than another than most users are. Only
> list those servers with a very high uptime, good performance and
> a wide range of features. Possibly limit it to servers local to the
> user (if that is possible to figure out).
> 
> If servers can dynamically report that they are lightly loaded and
> would be happy to have lots more users, list them as recommended.
> Spreading the load across lots of servers would be an advantage,
> but the user would have to be guided towards lightly loaded servers
> for this to work.
> 
> This is potentially a lot of work however.
> 
>>> I can't think of an advantage of having a big list (it doesn't
>>> mean there isn't one, just that I can't think of one and haven't
>>> seen any mentioned here).
>> It's fair? It's compatible with the goal of openess (no hugh entry
>> barriers to get on a list).
> 
> I think that is only an advantage if server admins want more users
> on their server (for my server is bigger than yours bragging rights).
> If a server has been set up for a group of friends, a project or an
> organisation, they may not mind other people signing up, but possibly
> won't want *lots* of people signing up.
> 
>>> Email clients don't present a user with a big list of email servers.
>> You can't register an email account with an email client.
> 
> True, I hadn't considered that.
> 
>>> On Saturday 05 January 2008 12:55:29 Tomasz Sterna wrote:
>>>> And who will be the judge which servers are "more equal" to be included
>>>> on the list, and which are "less equal" and won't be included?
>>> Does it matter if you're not on the list?
>> Yes, it may be an entry barrier and entry barriers are not compatible
>> with the mantra of openness of the XMPP community.
> 
> It's only an entry barrier if having lots of users on your server is a
> desirable goal. As long as people on my server can talk to people on
> your server, it makes no difference whether the split is 500:500 or
> 10:990 (ignoring problems caused by server load).
> 
> Because XMPP is open, the network effect applies equally to all servers
> regardless of how many users are on any particular server. The only
> figure that matters is the total number of users across all servers.
> 
> This is different from IRC where though the protocol is open, different
> networks can't talk to each other. Here, signing up to server A instead
> of server B provides an advantage to server A.
> 
> <snip>
>> Not true, there were similar issues with email: there also were walled
>> gardens for electronic mail.
> 
> Okay. I've never encountered any, though I didn't start using the
> internet and email until 1991.
> 
>>> Both Gaim and Kopete (I'm on Linux) present a number of options when
>>> creating an account, like AIM, Jabber, MSN etc. Very simply, they
>>> could present GTalk as a separate option. Technically, it's the same
>>> as Jabber, but most people won't know this. Alternatively, they
>>> could be presented as the same option (Jabber/Google Mail). In either
>>> case, people who use Google mail might be more inclined to use the
>>> talk facility.
>> Clients like Pidgin and Adium already do this but I don't think this
>> is a good idea at all: in this way it creates even more fraction.
>>
>>> Many programs have a hints and tips dialog that pops up, and the link
>>> between GTalk and XMPP/Jabber could be mentioned there.
>> Could be a possibility indeed, but maybe there is a better way?
> 
> I'll try and have a think.
>