[webteam] welcome

Sander Devrieze s.devrieze at pandora.be
Tue Jul 10 12:23:51 CDT 2007


2007/7/10, Adam Nemeth <aadaam at gmail.com>:
> 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?

End users don't care about this. Only geek end users do. That's also
why this information is hidden on the Google Talk website:
http://code.google.com/apis/talk/open_communications.html (btw: one of
the teams can try to contact Google and other service providers with
similar pages and persuade them to make this information copyleft so
that other projects can copy this). That's also why I keep this
mention minimal on the Coccinella website (because Coccinella does not
target geeks in the first place). So, we don't need an authority to
tell end users what Jabber is for several reasons:
* the different Jabber projects are much better in explaining Jabber
to THEIR target end users
* we should try to create a situation where it is obvious that you can
use a "instant mesaging ID" for every client and for every server and
that everything is compatible. One of the urgent things we should do
IMO, is to create an umbrella brand: every Jabber project should add a
label to show that it uses Jabber. First, we need a good name (Google
likes to use "Talk", some people prefer "Jabber", I don't care: just
take something and make sure all projects add this labeling, IMO this
should be the top priority for the XSF).

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

Yes, I know that. End users are stupid :o) That's why we shouldn't try
to educate them. Let others (Ubuntu, Jabber client projects, Mozilla,
Apple, Google,...) do this difficult task; they are better in this
because they only target a specific type of end users.

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

That's why we urgently need a good umbrella brand. In that way I can
tell "I use <umbrella brand>".

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

Too difficult and too much work. Let's others do this work; we're all
lazy, isn't it? ;-)

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

At least the Coccinella project successfully targets businesses... B-)

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

Plus, you this not only applies to clients, but also to server
projects and library projects and even companies that provide Jabber
services to other companies.

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

All of this.

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

See the ejabberd Feature Sheet for example, this is made for
businesses and optimized for ejabberd. I'm pretty sure a project like
this would never be able to create something as optimized for
ejabberd, as the ejabberd project itselves.

<snip>
> > >     * 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?:)

See my first email to this list.

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

Agreed, that's why I want this collaboration project: so that creative
uses spread much faster and deeper amongst the Jabber community, plus
we will try to create more creative new things in collaboration with
other projects (I have some ideas for Linux distributions for
example).

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

All agreed.

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

Agreed.

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

The reason why I said not needed was because developers are not all
contributors.

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

/me has a major in strategy and organisation :-)

-- 
Mvg, Sander Devrieze.


More information about the webteam mailing list