Slashdot Mirror


Kroupware Komplete

sorinm writes "The three companies behind the Kroupware Project (Erfrakon, Intevation and Klarälvdalens Datakonsult) announced its successful completion today. This new groupware approach using only Free Software is now available in stable versions under the Kolab brand name. Commercial support on an individual basis is already offered with further support options to come."

23 of 310 comments (clear)

  1. Has anybody tried it yet? by Creepy+Crawler · · Score: 5, Interesting

    How well does it do compared to EX-change?

    IOW: is it a "Komplete" software product, or the usual 90% GNU solution?

    Does anybody care to write a compairison feature and integration wise?

    --
    1. Re:Has anybody tried it yet? by arendjr · · Score: 5, Informative

      Yes, it's complete.

      It uses LDAP for company-wide addressbooks. It offers services for distributing free-busy lists. It can be used offline through disconnected IMAP. It allows for sharing folders (containing mail, calendars, contacts, whatever) between people. It has normal POP3 and SMTP support. Everything is configurable through the webinterface, in which you can set vacation messages as well. HOWTO's are available for integrating SpamAssasin and Amavis (anti-virus) with Kolab. You can install SquirrelMail on the server to allow webbased access to your mail.

      What do you want more?

  2. Kolab and Kontact, I'm confused. by $calar · · Score: 5, Interesting

    OK, so the KDE project started Kontact, which merges KMail, KOrganizer, KNotes, and KAddressBook. I was just at the Kontact web site and it doesn't mention Kolab. My thought was that Kroupware was supposed to merge at some point with Kontact, is this true? But Kolab screenshots look different than Kontact's. Is this going into KDE?

    http://kolab.kde.org/

    http://kontact.kde.org/

    In other words, is Kontact dead?

    1. Re:Kolab and Kontact, I'm confused. by falonaj · · Score: 5, Informative
      OK, so the KDE project started Kontact, which merges KMail, KOrganizer, KNotes, and KAddressBook.

      That's right. Kontact is currently in development, and will be released as part of KDE 3.2. Kontact is the way official KDE development has chosen.

      In other words, is Kontact dead?

      No, not at all. Kontact will merge all Kolab functionality that has been developed by the kroupware project.

      Until the KDE project has released Kontact, you can use the KMail-based Kolab client offered by the kroupware project.

      The kroupware project is sponsored by the German gouvernment. Because of the requirements of the German gouvernment offices, they chose to release a KMail-based Kolab first rather than waiting for Kontact to be finished.

  3. Enough with the goddam 'K' names by Anonymous Coward · · Score: 4, Insightful

    Stop the insanity! 'Kroupware' sounds like a brand of German kitchen-utensils or something.

  4. Re:Hopefully this fulfills the Exchange Need by afidel · · Score: 5, Informative

    Nope, you still need a commercial connector to use Outlook with this. We have had the ability to do that for some time (things like the old HP Exchange alternative and the suite from Oracle, what most of us want is the equivilant of SAMBA, a free and FREE drop in replacement for Exchange that doesn't cost anything to implement so long as we don't need support.

    --
    There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
  5. K's not always funny. by NanoGator · · Score: 5, Funny

    I thought Killustrator was funny, but Kroupware? Ugh. Very krappy.

    --
    "Derp de derp."
  6. This is a big step forward. by James+A.+A.+Joyce · · Score: 5, Insightful

    Now we have a proper, KDE-enhanced groupware solution for all sizes of organisations. Unfortunately, even if it is better than Exchange, those organisations are still going to stick with Exchange just because it's what they're familiar with. Hopefully we can try and get this stuff supported in the workplace, and if we contribute code and offer support to the companies we work for if they use this, we can get more widespread adoption.

  7. Exchange answers... by exhilaration · · Score: 4, Informative
    A little karma whoring never hurt anyone... :)

    From the FAQ:
    How can I make Outlook talk to the Kolab Server?
    You need a Plug-in called InsightConnector from http://bynari.com. This is proprietary software and you need to aquire a license. Demo versions are available. A second company, konsec.com, announced to make a similiar plug-in offering in Q3 2003.

    Later on it states:
    Is there no Free Software Outlook plugin? Will you create one?
    We are not aware of an existing Free Software plug-in for Outlook. Within the Kroupware project we have not been contracted to create such a plug-in. "Kervin L. Pierre" announced to work on it and started sourceforge.net/projects/otlkcon.

  8. What's with the name? by Anonymous Coward · · Score: 5, Interesting

    Kroupware? There is an Open Source product whose that is going head to head against major proprietary mail server packages, and someone actually thought to call it 'Kroupware'?

    Is that like 'HackingCoughWare' or, perhaps, the more subtle 'ScreamingInfantWare'? Ok, perhaps this is a troll, but I've historically had a hard enough time selling open source stuff into various enterprises. ("MySQL? Aww, what a cute name. Now go get us something that sounds professional." I've heard that. Literally. Twice.) I realize we're all smart enough to know better.

    Selling a product is as much (if not more) selling an image than it is selling features, reliability, etc. At least for the PHBs I've had to sell to in the past. Trying to bring a mission critical piece of software in that's named after an anoying childhood malady will, before anything else, elicit a bunch of laughs from the powers that be, and then there's that much more of a hole to dig out of.

  9. To bad Evolution probably wont support it by Plix · · Score: 5, Informative

    According to the FAQ (and from ximian.com) it appears as if Evolution doesn't support Kroupware and wont be supporting it anytime soon (see this post to the evolution mailing list). This is a real shame considering that outside of the KDE camp most people aren't using K-Mail in favor of Gnome clients like Evolution and Balsa.

    1. Re:To bad Evolution probably wont support it by Wesley+Felter · · Score: 4, Informative

      If both Kroupware and Evolution supported standards, then they wouldn't need any extra support to work together. Unfortunately, Kroupware is taking a weird approach of accessing contacts and calendar entries using IMAP instead of LDAP and CAP. Evolution doesn't support CAP either.

  10. It's cute and all... by NanoGator · · Score: 4, Interesting

    ... but all those apps that begin with K become a real nuisance to find on KDE's version of the start-menu when you're a Linux newb such as myself.

    --
    "Derp de derp."
  11. again not quite there by scottking · · Score: 4, Insightful
    once again the open source community releases an exchange killer, and once again it is missing the most important component...

    native integration with outlook.

    i said this before in another post, but i am going to say it again. businesses aren't ready for desktop linux, which means server side solutions (no matter how brilliant) MUST work with the desktop apps that employees use. no one wants to relearn their e-mail client; and yes i am aware that evolution is almost identical to outlook at the interface level. but the truth of it is, the perception of any new desktop software is "now i have to learn everything all over again". it's the illusion of difficulty, so we as developers (and by we i mean you :) ) should make it our primary goal to lessen the difficulty of the intgration with newer, oss technology where ever we can

    --
    scott king
    1. Re:again not quite there by Grishnakh · · Score: 4, Insightful

      If you want an Outlook connector, go write one yourself.

      This product was not written by some vague "open source community" at large. It was written by two consulting companies who were contracted by the German government to provide a very specific solution using open-source components, and that's exactly what they did. The German government will not be using Outlook on their client machines, so they sure as hell are not going to fund development of anything to do this. If it's so important to you or others, you're free to write it yourself or fund development with your own money. Or you can buy an existing solution from Bynari for a lot less than an Exchange system.

  12. Re:Hopefully this fulfills the Exchange Need by hdparm · · Score: 4, Interesting

    But I do not want to use Outlook at all. Evolution or Mozilla will do just fine for say, everybody. Plus, talking about free/FREE - why is everybody prepared to pay big bucks to Microsoft or Oracle but not to some other company for said Outlook connector, if they really want to use Outlook? That would be heaps cheaper option.

  13. otlkcon status by kervin · · Score: 5, Informative

    http://otlkcon.sf.net is mine.

    I've been working on it from about Nov'02, and was pretty much trying to keep things on the down-low until I had a proof-of-concept to show. You see, ironically, I did this to not have yet-another-vapor-project out there :)

    The a simple connector plugin would not have taken this long. But I've decided to take a solid stab at solving the root problem, that is, an extendable MAPI message service, and the tools needed to program for/with this set of MAPI providers.

    First part of the Message service, is the message store. That's the DLL in MAPI responsible for actually saving your mail to the filesystem, amongst other things. The second most important service provider, the transport service provider, is responsible for sending the mail off, basically.

    I've been focusing on a sub-project at http://sapimapi.sf.net. Don't let the stats put you off, I've been putting a decent amount of hours on this one ( sf.net CVS stats are broken right now ). This testing utility has a built in scripting language, and common MAPI routines, to make it easy to configure the behavior of MAPI clients for testing the service providers. I also intend to fit in TNEF routines and info on much of the undocumented MAPI properties I've collected from/at various places. The testing utilitly is early, early alpha; I have the language lexer/parser done, and I'm working on the built in MAPI library calls. Extended MAPI from C# is a bitch. Funny they forget to mention stuff like that in the brochure.

    Open source connector will get done soon. I've heard of at least one other group working on the problem. I suspect it's only a matter of time till one of the unprofitable companies, selling a MAPI connector, releases it as open source. There are a lot of them.

    The important thing, I believe, is that we get a complete extendable toolkit, that would spark the continued development of extensions. Eg. address book, chat, voicemail, etc.

  14. Achtung, der namentrollz... by heironymouscoward · · Score: 5, Funny

    Ja, das namen "Kroupware" ist untercompatible mit der "marketing" und "salez". Ve haf zehr lang geflamed unt gechat mit keine success. in Deutsch, "kroup" en "group" ist blinkindentic.
    Ja, Slashdot namentrollz, genough mit dem "kind und kroup" joken. Ve asken zie einen gutten namen te finden. We zen unterserious. Das winner mit deze bestes namen ist kandidate fur ein Freiexemplar gewinnen. Achtung, frei als in "freies Bier"! Ja, ja. Ist Kool, nein?

    --
    Ceci n'est pas une signature
  15. Namecalling by skurken · · Score: 5, Insightful

    It's interesting to find that most comments thus far has been about the name of the app. Is there really no more to say or are people just looking for cheap Funny-karma?

    I'll chip in for the ante then:
    This seems to be an intreresting product for hybrid companies (like I've worked with) where the engineering part is using Linux and the manager part is using Windows/Outlook. This way there is a serious player for interconnecting the two of them that (unlike Evolution) doesn't rely on an Exchange server. If now Evolution just could start working with this as well and we'll have real interconnectivity. Good.

  16. Support CALSCH, CAP, and James by kervin · · Score: 5, Interesting

    Kroupware and the others are nice. But what we really need is for CALSCH http://www.ietf.org/html.charters/calsch-charter.h tml to finish with CAP http://www.ietf.org/internet-drafts/draft-ietf-cal sch-cap-10.txt . As you can see CAP is on it's tenth public revision.

    We need a standard that specifies the transport of the calendar protocol, badly. We need CAP finished.

    The special folder in IMAP scheme will work. But is a little on the hackish side, and incompartibility between servers is a serious problem, even with standard formats, like iCal based schemes.

    Next we need a cross platform messaging server. Although, it does not support IMAP as yet, Apache James is my favorite, at http://james.apache.org. First of all it has a strong group endorsing it, the Apache group. That's going to be important for selling this thing to risk-adverse corporate types. Second, it's Java, so I trust it a little more in the buffer-overflow department. Also it would probably integrate nicely in current J2EE setups. I've heard people are doing this.

    James needs IMAP and CAP support. And then we will have a decent shot at the less entrenched sector of the exchanges market.

  17. Hey come back here with that! by Graymalkin · · Score: 5, Insightful

    An aspect of Kroupware project I find really interesting is the "indirect funding" by the German government. The government said "we need features X, Y, and Z and be compatible with Outlook and Linux". The developers responded to those requests and won the contract to develop the software. I've thought for a long time this would be a really intelligent way for government agencies of any size to get the features they want out of software for a reasonable price.

    It'd be cool to see a larger group commercial group offer themselves as contract coders for government projects. They can offer a product with X features to the agency, get the money to fund the development, then distribute that software back into the wild under a Free license for everyone else to benefit.

    It seems a major issue with many government agencies and corporations adopting Free Software alternatives to commercial offerings is with support. No matter how good a coder a particular OS contributor is, they are not likely available 24/7 to fix a major problem or to add a particular feature. If there is a warm body at the end of a telephone who is paid to fix bugs or add features I think more institutions would adopt Free software solutions.

    In particular to Krappynameware's case, the German government is pretty gung ho about Free software to begin with. Their requirements actually included Linux support and interoperability. It'd nice to see a government agency apt to use non-proprietary solutions to their software needs. Such solutions only leed to vendor lock-in and wasting of taxpayer dollars or euros.

    What groups besides maybe the major Linux distributions like SuSE and RedHat and maybe Ximian provide the sort of support government agencies contract out? I obviously haven't seen many because I can only list three off the top of my head. Are there any vendors that provide those sort of services as a regular business plan?

    --
    I'm a loner Dottie, a Rebel.
  18. Some more info by thorsen · · Score: 5, Informative
    There are quite a lot of posts here that asks some ligitimate questions, and I'll try to answer a bunch of them here.

    First of all: The "Kroupware" name. Don't worry, it doesn't exist at all anymore. Kroupware was the name of the contract development, and will not be used for anything else. The server is called Kolab, and the client is KMail, Korganizer, KAddressbook and KPilot. In KDE 3.2 these will come together in one bunch under the name Kontact. We are now porting the features to KDE cvs HEAD.

    Second: There are a bunch of people asking about features. For this project we had a list of requirements from BSI that we would implement. We implemented exactly this and not much more. When people say the word groupware, they immediatelly expect three thousand different functionalities, and if you in version 1.0 try to implement all of them, you will break your neck trying.

    The functionality is:

    Calendaring with iCalendar - send invitations between KMail and Outlook for example

    Addressbook - a global one by LDAP and a local one in vCard contacts

    Tasks - not groupware tasks though (only KMail to KMail or Outlook to Outlook, since OL doesn't understand iCalendar tasks scheduling :-( )

    Vacation mail setup - for vacation nag mails

    MDN

    Disconnected IMAP support

    Roaming support by storing the calendar/contacts... stuff in IMAP folders

    Resource scheduling (book cars, rooms...)

    I probably forgot a bunch of features. Clientwise, the most important are definately that you can invite between KMail and Outlook. On the server side, the interesting thing here is that this is the only truly free groupware server available, and will allow the Outlook people to continue working with it.

    In case you visit the Linux Developers Conference in Edinburgh next week, you can see a presentation/demonstration by me.

    Bo Thorsen,
    Klaralvdalens Datakonsult AB
    Project leader on the client.

  19. Re:Hopefully this fulfills the Exchange Need by metamatic · · Score: 4, Informative

    You could replace Exchange servers with Domino servers using iNotes Access for Microsoft Outlook.

    Rather than the ~3,000 users per server max of Exchange, you can load up to 100,000 simultaneous users on an iSeries machine running Domino...

    --
    GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak