[webteam] welcome

[Adam Nemeth]

I think there's a common phrase in English that "I STRONGLY disagree".
Well, this is something what I thought after this letter, but let's go
point-by-point,

On 7/10/07, Sander Devrieze <s.devrieze at pandora.be> wrote:
> >
> >     *  End Users (main focus)
>
> Not needed, we just have to give client projects the tools to target
> end users. E.g. we can create some copyleft introduction to Jabber
> that client projects can put on their website.
>

Could you tell me who would be the AUTHORITY then who would tell end
users what IS jabber and what ISN'T, telling them the supersimple
fact, that while jabber has an open network
  a) There isn't a "main" client unlike every other IM networks with a
>0.01% share
  b) What clients are there if there's no main client
  c) What is this protocol thingy about?

You know that IM is like pre-e-mail today, I know it is. For other
people there exists "e-mail" "MSN/AIM" (depends on country mainly),
and "internet" (as they prefer to call web). In most people's head
these are three different systems!! (Trust me I researched it.)

For an IM network (and will hear from their peers that "Do you use
MSN/ICQ/YIM/AIM/...? I use jabber, it's better" (been hearing and
telling this since years), they expect to see "download jabber here"
and "register here for jabber" because simply this is how IM works
today, and works basically since the 90s... The main ORIGIN of the
users for jabber.org are possibly those who type "jabber" into google
after such a conversation.

If something, it IS jabber.org responsibility to tell them why there's
a client choice and what does it mean to be an open protocol, and to
have an open network.

> >     * Managers
>
> Not needed, we just have to give client projects the tools to target
> managers. E.g. a database of case studies they are allowed to put on
> their website.
>

It's not about client choice really. Using a private network is not
about what clients you use. Using an extensible and protocol what
could fit your current workflows is really about the protocol itself,
it's the protocol's feature to let them deploy their own network, let
them enable a single sign-on, possibly shared groups / default
contacts, having security (no using of public/foreign resources),
while able to log every conversation.

If it would be about projects, it would be about server vendors anyway
(like jabber.com, jive, processone), not individual client projects
(like psi or gaim).

But the protocol itself is what could fit their need on EIM solutions,
and that's the point.

> >     * Server Admins
>
> Not needed, we just have to give server projects the tools to target
> admins. E.g. we can give server projects that lack a good community
> website the knowledge to set up a good community website (I thinking
> about jabberd14 and jabberd2 of course).
>

OK, this is the place where while I don't agree with the cause, I
agree that server admins aren't a different target group probably:

1) They're employees / members of an organization (not necessarily
companies, could be schools, communities, etc), which would need those
informations (although a bit more technically) as companies needs
(and/or have a "communities" part)

2) If they're admins, they'd already choosen their systems to deploy,
and if they've done this, they'll have information on their server
vendor's page.

> >     * Developers
>
> Not needed, library projects have to target these people. We just have
> to sustain them.
>

What if a developer is about to make a new library?:)

But this is the point where I strongly disagree again. Developers need
creative uses. Do you know what does every single social network
deploy nowadays? It's userplane. While I don't want to ruin their
business model, I think there could be much more sophisticated
solutions for such - based on jabber, of course.

But we need to have demos for such, we need to have examples, and of
course we need to have client libraries, but it's the last item on the
list (they could create one themselves if needed).

And they also need information about what is to be on an open network,
with open protocols, because developers would LOVE interoperability
_while_ maintaining their own network, but this information needs to
be clear for them (eg. it's not GoogleTalk-only - no, it's not clear
for a lot of them!)

"Developers, developers, developers, developers" - as Steve Ballmer
said once. Yes, we need them, and they need us - but we must show this
to them.

(I know I'm half a marketing guy:)


-- 
Aadaam <aadaam at gmail.com>