Kopete in kdenetwork

Rob Kaper cap at capsi.com
Tue Mar 4 10:52:55 GMT 2003

On Sun, Feb 23, 2003 at 01:59:30PM -0300, Duncan Mac-Vicar Prett wrote:
> I hope we all can make a difference about supporting choice and promoting  
> propietary services.

Late follow-up: I wouldn't actually mind the suggestion that KDE could
promote Jabber. One of the problems we will face with the KInvitation
framework will be what kind of features different IM systems support. If we
could be sure every KDE user who uses IM also has a Jabber account, that
would solve and prevent problems, as there is the guarantee some services
are available.

I don't mind support for proprietary services, although I think most should
go to kdeaddons (and seperate releases or however distributors package
Kopete). The primary format for any KDE app should be open and free. MS
document support in KOffice? Add-on, not a core feature. MSIE extensions in
KHTML? Add-on to the W3C standards, not the basis to work from.  

> Kopete is one of the biggest KDE projects, with a incredible large
> userbase, a incredible big development team, users have the word.

Microsoft (and other proprietary) products are amongst the biggest software
projects, with an incredible user base, an incredible big development team..
where are you going with this?

As far as I know, it is possible to stay in touch with users on all kinds of
protocols with Jabber. In theory, one *good* Jabber client should really be

I believe the problem with Kopete is not that it has some support for
proprietary solutions, but indeed that 95% of its functionality depends on
it. You've been right all along: without those plugins Kopete would be
nothing, but I'm not convinced that is a reason in *favor* of inclusion.

I really feel that the proprietary plugins should go into kdeaddons: it
shouldn't hurt stand-alone releases or distribution inclusions.

Another reason not to make the decision on which plugins go to
kdenetwork/kdepim based on protocol market share: market shares shift.
Making open, community-supported protocols our first priority makes sense.
I'm very much in favor of putting KDE in the core KDE packages, as it will
give it a chance to mature. I'm just not sure if it is wise to include it in
such as way that the *majority* of added code is there to support proprietary

By the way: if it is still the intention for Kopete to move, please do it
ASAP. I'm sure 3.2 is still far away, but I hope we can avoid last-minute
inclusions of new stuff to prevent another Crystal crisis.

Rob Kaper     | "They that can give up essential liberty to obtain a little
cap at capsi.com | temporary safety deserve neither liberty nor safety."
www.capsi.com | - Benjamin Franklin, Historical Review of Pennsylvania, 1759
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20030304/38d0c82b/attachment.sig>

More information about the kde-core-devel mailing list