[webteam] welcome

[Florian Jensen]

Hey,

the umbrella brand exists! It is Jabber! I use Jabber!

The technology is called XMPP. That is why Jabber.org should be for end
users, with documentation and helping them to start.

XMPP.org / .net should be the place for developpers.

Or like PSA said: dev.jabber.org is still free ;)

Greets,

Florian Jensen

On Tue, 10 Jul 2007 19:23:51 +0200, "Sander Devrieze"
<s.devrieze at pandora.be> wrote:
> 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.
-- 
Flosoft.biz / CEK Media Service
CEK Media Service
Seestr. 8
73773 Aichwald
Germany