Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Linux Business

Making The Case For Open Groupware 141

Posted by timothy from the gotta-have-connections dept.
OldBen writes: "This arose out of a thread that bounced between the OpenOffice and Evolution mailing lists. Looks like the folks that brought us phpGroupWare are looking to establish an open standard for communication between groupware components. A site has been established at http://www.ogsproject.org. Right now it looks like it's nothing more than a mailing list, but this is a critical step in the development of products that can once and for all replace Exchange/Outlook/Project, and therefore MS Office." Maybe I'm boring and have accountant-style glasses, but OpenOffice and phpGroupWare are two of my favorite projects, because I can taunt the very nice IT guy at the Microsoft-heavy office I used to work in with some tempting, flexible answers to the "what about Outlook?" question.
This discussion has been archived. No new comments can be posted.

Making The Case For Open Groupware More

Making The Case For Open Groupware

Comments Filter:

  • Re:fp (Score:1)

    by Anonymous Coward
    Let me tell you a little something:

    While you spend all of your free time diddling around on Slashdot and charming your snake (it appears you also bash its brains out) there are people writing code. You benefit from this code. Slashdot, the place you defile, is written in GPL'd code, as is the server that serves it and the OS that server runs on. Try to show a little respect. In fact, I think you should be held accountable for what you post here and you should be required to give a little something back to the people who made your posts possible. At the moment that can't be done but I'm sure Malde keeps meticulous server logs and one day you'll get a knock on your door. It will be the Open Source people, coming to collect the dues for all of the playing you have been doing on their playground. Hopefully I will be with them. I bet you aren't a jovial then.

  • Opps I meant to mod you up. Oh well, +0 is better than -1.
  • There is some pretty interesting work being done on the unified messaging front from TGF Linux Communications [tgflinux.com]. Their backend, called TUCAN [sourceforge.net] is CORBA based, so you can easily write a different interface in some other language on some other platform. I'm working on a web based front end to it, Operation: CAN [sourceforge.net], but there is also work being done on a gtk front end, it's called Creation [sourceforge.net].

    TUCAN and Operation: CAN and Creation are also all released under the GPL.

    - Ben
    *insert clever sig here*

  • Hopefully, the database wrappers won't be a problem; for instance, PHP has ADODB [weblogs.com], which should let you keep your choice of databases fairly flexible, AFAICT...

    Also, there are already a ton of webmail packages out there; I remember HOARD had something that looked promising for a while. I think a lot of the pieces are out there, so hopefully a project like this will be more about architecting a good solution, and the implementation will be more about putting it all together than making it from scratch.
    ---
    pb Reply or e-mail; don't vaguely moderate [ncsu.edu].
  • Unfortunately, Lotus seem to be very short-sighted in this regard.

    Yes, they have Domino for Linux, but at the same time, they have dropped all but Windows versions of the Notes client. Now web-enabled deatabases can be run from any java-capable browser, but for designing and administering your apps, you need a Windows box.

    Mind you, Notes is a pretty kludgy client program anyway, with a lot of user-unfriendly features. It suffers from "developer design" (Where it's really easy to use if you think like a programmer)

  • The key concept is the storage engine driving the groupware server - all of the messages and data need to be stored somewhere.


    I've been a Notes Admin since v3.3 or so, and I have to say that I think Tom has hit the nail on the head with this point. One of Notes/Domino's strongest features is its excellent database structure, and the replication technology. The Notes Client and the Domino server share the same database engine, so moving a particular application from a locally stored version to a server for general use can be done by simply copying the file.

    It's user interface is possibly its worst feature, so hopefully we can ignore that.


    I'm no DB geek by any definition, but has anyone thinking about this considered what/how the database ought to work? Is it possible to
    implement a solution built on top of MySQL or Postgres, or something else that might scale well?


    Can either of these do replication/data synching between servers? Is there any OS DB that does? That what should be used. Combine with standard email, LDAP, something like SteelBlue [freshmeat.net], or other ColdFusion-like system, and you've got most of the stuff you need.

    What we need from a groupware project is for all these types of elements to be tied together, while still allowing the individual elements to be upgraded individually and even replaced with alternates.

    That's what I'd like to see, anyway. A real open source replacement for Notes, combining the best of everything, for everyone.

  • Nothing will protect us ... from idiots and those who take advantage of them..... people can't be bothered to set there security settings and everytime they get ANYTHING, they just double-click it, infect the file servers, and infect me even though I'm careful...

    Well obviously you aren't being careful enough. :-)

    Protection can be helped through gentle enforcement. Make all the default settings secure and pop up a big nasty warning if they go to disable something. Yeah I know they just click-through but it's a start.

    Then implement procmail security on incoming mail. I don't have a link handy but it is a beautiful little procmail script which defangs emails, optionally scans, all kinds of nice things. Next, enforce security a little more strongly by refusing to turn off such protection and making sure that the default policy for viewing attachments is through a virus scanner.

    Back to the world of calendaring: there is no need whatsoever to have scripting of any kind. Simple objects such as "allocate resource" (meeting room, projector, etc.) and "allocate person" and have the client able to send authorization off to a third party (i.e. a secretary) if you desire. From these two base objects you can span out and do more and fo course... if someone decides to make a whiz-bang object your client can always not install it or the administrator can refuse to allow clients to install support for them.

    This remark is kind of flippant; I'm not saying I just designed the perfect groupware system in three or four paragraphs; just that your security negativity is unfounded.

  • Sorry, you did say NSF. I've gotten so used to Linux, I guess, that I read that as NFS. And you are right about what you say about them.

    My apology, sorry.


  • Notes/Domino isn't really a groupware app. It's a pre-internet mail/news app. You can use it that way (as most early Notes users did), but the same can be said for any discussion program.

    No, Domino is a workflow / text database / collaboration tool with mail & scheduling grafted on. The last job I was at had tons of Notes apps being used for workflow. Collaboration not only included providing the documents, but providing (at the field level) security for who could see / modify/ delete each piece of data. The worst part of it is the mail / calendaring. It also had replication (to the field level) between servers.

    Bottom line - if the groupware folks want to imitate anything, imitate the best parts of domino, grafting on the ability to do RFC standard e-mail & calendaring. Don't bother with Exchange, it can't hold a candle to Domino.

  • NFS in no way compares to the text database capabilities of domino/notes. Remember that you can set security and workflow triggers on each field of a form - not something you can do with NFS. And domino is for more than just not-very-dynamic data. (and no, SQL doesn't work either - different needs).

    Also, I'm not confusing Domino with Domino apps. The workflow /text database/etc are built into Domino and enable the apps to be built on top of them.

    I looked through the pointers you provided. It looks like Notes has moved very far from it's beginnings - I felt that the mail / calendaring was the clunkiest part of Notes, the text database / workflow the most powerfull (and I can't even find mention of the workflow part in the pointers provided - by workflow I mean the ability of an app to route stuff / alert a user based on a changed field in a text database - for example the HR department filling in a new employee form triggering routing an email to the computer security folks that causes them to pull up a new user form, that gets routed to the new employee's boss for approval, then triggering the creation of their computer account, which also triggers the IT infrastructure guys to ensure the jack at the new guys desk is turned on ... I am looking for the open source equivilent of this).
  • I'd be happy just to see something in "standard" email that captured more of the metadata than just "to" "from" and "subject". For example, why can't "standard" email also capture:
    • My role in sending it (am I sending as friend, owner of Stonehenge, fellow Perl hacker, resident of Oregon, or what)
    • Your role in recieving it (ditto)
    • Precisely what thread this is in reply to, if any
    • My emotional tone (smiley face doesn't cut it)
    • subthread markings for different paragraphs of an aggregate message (perhaps even shifts in role)
    • My alternate roles for your information (you are talking to me because of my Perl training skills, but I also am a snowboarder)
    If we just started capturing some of that, perhaps as some XML payload attached to the message, 75% of the mail load of the 400 email messages I get a day would be terribly simplified.

    RFC822 is like what, 20 years old? Isn't it time we raised the bar a bit for email? And it needs to be vendor-neutral, with good opensource implementations, but extensible to be able to carry vendor-private stuff as well. XML fits that role well, and is prevalent enough today to start making sense.

    Is anyone interested in working with me on this, or can someone point me to people who are already doing this? I'd appreciate some email. (Ick, what am I saying? {grin})

    I think my biggest problem will be getting it into AOL browser and Outlook. Maybe some people from these two arenas can talk to me about a unified strategy.

  • Soap does fix the data transfer problem, which indirectly solves the groupware problem.

    The *nix philosophy has been "small reusable tools hooked together through pipes". Right now, the general *nix population is scratching it's head and saying, "Hm. How do we extend this idea to the GUI world?" But IBM, MS, and all the other big boys were asking this question two years ago. SOAP is the answer. The philosophy is "small reusable components hooked together through interfaces".

    You want Groupware on linux? No problem... take your SOAP enabled email client, point it at the SOAP interfaces of your SOAP enabled calendar app, etc, etc.
  • This problem has been solved.

    Continue about your business.

  • The GCTP [gctp.org] (group calendar transfer protocol) project has a significant code base and is tackling the calendar end of the groupware problem. There is also a related project, OpenFlock [openflock.org].

    GPL'd, and the current model is written in perl, though the more important aspect of this project is the protocol and establishing a standard for information availability and interoperabiltiy of calendar and event applications.

    Both of these are the incarnation of David Sifry of LinuxCare. David presented a paper [gctp.org] at ALS describing the protocol.

    The code is available via cvs:

    $ cvs -d:pserver:cvs@www.gctp.org:/cvsroot login

    Password is "cvs"

    $ cvs -d:pserver:cvs@www.gctp.org:/cvsroot co -P -d openflock_acls1 -r openflock_acls1 openflock

  • This is a great opportunity for the Open Source movement, but it needs to be formulated and focused in the right way.

    In general, groupware systems have suffered from the notion that the real problem is to integrate a number of different communication and planning applications into a useable, multi-user system. This is a perfectly respectable, goal but will never lead to the revolution that is necessary.

    What is really needed is vision of a whole system for collective knowledge management and group work. The most important pieces of this are a shared, interactive, structured document store that allows for live collaboration in the production of collective knowledge. Doug Engelbart (who has actually been working towards these goals for at least 40 years now) calls this component a Dynamic Knowledge Repository [bootstrap.org], and he has a very clear understanding of what its requirements are. Given this substrate, a wide range of tools for task management, workflow management, and user modelling (amon other things) can be brought together with (hopefully) minimal effort.

    You might see where I'm going. There has been a lot of work done in researching this problem and there have been a number of different groups working toward this goal. Engelbart's group at McDonnell Douglas actually implemented a system of this sort and called it Augment. It would be a shame (and sadly not atypical of open source projects) to ignore the insights of this man and his work.

    More specifically, Doug and a number of us have been engaging in a design process for some time. I think we have a fairly clear idea of what such a system will look like using modern technologies and approaches. Mail me for more information. Or visit the OHS Project [sourceforge.net] pages (currently pretty thin).

  • My favorite quote from the evolution site:

    This is especially true in open-source software, where the only real barrier to use is complexity.

    I'd like to add a second barrier: how to find it.

    Even though Askemos [askemos.org] is in it's infancy, it's simple at least, standards based and promises P2P distribution.

  • This is what Sourceforge.net is for !!
  • it wouldn't be a problem if law enforcement wasn't so hobbled in prosecuting cybercrime.

    Sorry, but that's a poor damn excuse.

    It's illegal to blow up buildings, but it didn't stop Little Timothy in Oklahoma.

    The problem is that Outlook (like other MS programs) will execute an attachment based on it's name when you click on it... combine this with the fact that the OS is squarely targetted at the "I don't know anything about computers" crowd, and this is just an accident waiting to happen.

    The Melissa/ILOVEYOU authors could have been drawn and quartered live on national prime-time TV, but the root of the problem still remains; and until that's fixed, virus authors will continue to annoy/amuse the rest of the world.
  • <i>The last thing Linux needs is a fully integrated mail client.</i>

    Too late, we already have EMACS! :o)

    /me ducks
  • You've brought up some important points about the implemenation of this kind of system. However, one thing you said really concerns me:

    Once we've defined the back end, it should be as simple as building a wrapper around the technology that we select. (I know that's a major oversimplification.)

    It sounds like you want to start with the technology and figure out how to let people use it later. I think this approach is exactly backwards. If you want to build something that people want to use, first figure out what people want. Start not with the technology but with the tasks/activities/scenarios that users engage in that you want your system to support. Then decide what technology would best support those tasks.

    Sorry if I misunderstood you. But I think it's very important to start with the focus on what people want, because then you're more likely to end up with something that will help them and they'll actually use.

  • I think this is a very important point:

    For most people collaboration is about the management of documents.

    Document management is something I've become more and more interested in over the years, and I think it would be great if my computer helped me do it better. For an interesting approach to document management, I recommend checking out Placeless Documents [xerox.com], a project at Xerox PARC.

  • I just installed this and it rocks: html-trap.procmail [impsec.org] I haven't found any complaint with it yet.

    Boss of nothin. Big deal.
    Son, go get daddy's hard plastic eyes.
  • Disagree:
    • Most versions I've seen can't even do imap
    • It's too big
    • It doesn't thread messages. Once you've used threaded messages for a while, you realize that it's insane to read mail any other way.
    • The "save replies in folder with original" feature is nice (it would be better with threading), but in my experience it either doesn't work as advertised or isn't present. It's certainly not easy to get it this kind of thing done right, since I prefer to read in my inbox, then move to folders based on the recipient later.
    • Filter rules can't be taken with you (at least they couldn't the last time I used outlook). This bites. Every time you change computers, it's like someone comes to your desk and turns the whole thing upside down.
    • Junk mail filters are nice, but every now and then they throw out perfectly legitimate mail based on some secret formula. Do you know why? No, you don't.
    • Most versions are very poor in informing the user about what it's doing. It just hangs forever waiting on the network (this has improved in more recent versions). It doesn't alert you if you have a very large message to download. If you are a dialup user with a large attachment, this SUCKS. The world's greatest and most innovative software company can't figure this out, apparently.
    • Every single version I've seen refuses to shutdown occasionally and gets stuck sometimes. Rebooting is not a productivity-enhancer.
    It has an address book and a calendar that work with the mail client. Big deal, it's hardly rocket science. If you spend way too much money on corporate servers, you can get all these things working together for a group of people.

    It would be nice if a groupware project could start as a web-based version of this, refine itself and get really slick, then write a couple servlets (java or c) that can puke out this data for clients that need; email and ldap get you partway there, so the calendaring part would be nice. These projects are making real progress, and not a moment too soon. It would solve a whole bunch of business problems for a whole bunch of people. And that is what this article is about, not a bunch unjustified Outlook fandom. The only reason I have that no such project is really mature yet is that it's a lot of boring programming.

    Boss of nothin. Big deal.
    Son, go get daddy's hard plastic eyes.

  • I have to suffer using outlook each and every day in my USAF job. Outlook is a true and total piece of shit- from the setup to the look and feel to the architecture there is NOTHING about that makes it EVEN REMOTELY more than a piece of shit If you want to know the basis behind these opinions- please ask and I'll be glad to detail my objects but I won't subject everyone to it.

    That being said, a client which allowed bits of half way decent mailers, directories and calendars to integrate would be awesome- I could pick and choose imagine that! Sharing a common LDAP directory would be a start then maybe working with the KDE and GNOME applications to implement a common IPC scheme or common set of objects for their ORBs to reference. That would be a highly worthy goal.

    Please though- don't even consider another outlook.
  • You could try running for congress.
  • Outlook is evil because it does not respect Internet standard: try quoting a mail to put your reply after the quoted part (that you should expurge). Unless you do it manually, there is no way to make it work the way any client should.

    Outlook makes you use proprietary client/server protocol if you wish to employ 100% of it's feature. This proprietary protocol prevents you from using something else than Microsoft Windows, either as a client or server (unless you use Notes, but the problem is the same). Don't talk me about the Mac client, it is a complete joke, just to convince the DoJ that they don't make a monopoly. It lack most of the feature that make Outlook/Exchange useful (ie calendaring)

    I'm not even talkin about GUI weirdness like reodering folders in the treeview each time you put a message in...

    Oh, I forgot: I have used Mutt during 1 and 1/2 year with MS-Exchange as a server because of stupid corporate policy in a company that think it is best to spend money to buy Windows machine to UNIX developer (that have their own SUN box) rather than to have a cross platform IT strategy.

  • I've been hanging around these guys for a few months now, so when I read things like "vCalendar, POP, etc" are standards, I think the point is being missed.

    The thing is, phpGW is at this very minute reworking much of its API to support vCalendar and other standards. Look at the IRC logs for #phpgroupware at http://www.phpgroupware.org/irclogs/ to get a better idea what is going on.

    The point of this project is to establish open groupware standards that will be built on top of existing standards. At no point did any of us ever say "hey, let's make our own version of vCalendar" or any other standard. Why reinvent the wheel? This project will provide a common API that will hopefully be implemented in several languages, platforms, and environments (desktop/web).

    My project, Double Choco Latte, will be ported to work within the phpGroupWare environment later this year. I think it is very important to provide the basics of groupware along with more specialized applications like project and task management.
  • This google search [google.com] lists a bunch of DCE-RPC projects for Linux. I have never understood why Samba was such a big deal on Linux but DCE-RPC never was talked about as much.
  • emacs reportedly has email, calendaring, newsgroup reading, and a text editor (the only part I've used). What part of this relates specifically to software development or limits it to that one use?

    It's not that you CAN'T also use emacs for all those tasks, but it's that only developers (1) know how to use emacs or (2) are likely to be ABLE to learn emacs (i am a relatively smart guy, with experience coding, and i still haven't figured out how to use emacs, mostly from trying it a few times and deciding it was too much trouble).

    groupware means EVERYONE in the GROUP uses it. managers, secreteries, marketing people, coders, designers. everyone. gotta be easy to use/learn.
  • The open source community needs to do their best to work together and create standards such as this. It is only because of standards that our community can actually survive. The internet itself exists due to the widespread use of open standards.

    I'd love to see this project become so popular that microsoft themselves are forced to adopt the standards for interoperability. Hrmm.. that'll be the day I guess, even when customers request their products on other platforms - they still refuse to do so.
    --
    Twivel

  • SOAP is interesting, but getting bloated. There's no reason to use something that heavy for simple messaging. XMLRPC [xmlrpc.org] (from which the SOAP bubble formed) would probably work just as well.
  • Yup, millions of dollars in free advertising spouting about how good the "Old" Coke was. People cheered when they brought back "Classic Coke." Absolute brilliance. How often are people excited to have the SAME OLD PRODUCT THEY'VE ALWAYS HAD!? "Now Classic Windows 98! The same as old Windows 98!" YAY!
  • The Exchange data stores are based around modified versions of the Access/Jet DB code.
  • Very insightful thoughts there.

    Building on top of a sql-database seems like the logical solution.
    Once they have decided on what data is needed and how to structure it, it's "just" a matter of designing a userinterface (read: Client) that will communicate in a proper way.

    Doing that part through apache would circumvent the need to make lots of ports too.
    At work we use Outlook Webaccess, and I think that's the best way of doing it.
    You loose a little speed, but you gain a lot of flexability.
    It's great to be able to use your calendar, mail, etc, from anywhere in the world with only a netconnection.
    If it would be possible to make a WAP interface too, that would *really* rock!
    Groupware via mobilephone. =-)

  • I do believe that you can tell the difference... but then, i order mixed drinks, and i've been out drinking with you.

    so go figure. ^_^

  • better, but you need to make the URL a little more random, and perhaps post from a real account.
  • So what? Don't run the script. Ootlook is great, except it has TOO MANY fetaures,some of which are turned on by default, which they shouldn't. But other than this its fine, or do you disagree?


  • Just to get the fud going here, I suggest we forever after refer to .NET as the .NET offensive.... As in the
    TET offensive [aol.com] during vietnam. Whoops. I forgot who won that thing. Nevermind.



    Seth
  • Hah! SOAP only fixes the data transfer/formatting problems. It doesn't do anything to help interact with the user/servers.. (ie. an actual program).
  • Well, because you said "hackers can write worms using LotusScript", I chose to explain Notes client's security capabilities. Probably you should know that LotusScript can only run on Notes client, not run on web browsers...
  • > And I don't see how using Domino is supposed to
    > lock out script worms. OK, there don't seem to
    > be a lot of worms written in Lotus Script,
    > but hey, the hackers are always looking for a
    > challenge.

    The default ECL (Execution control list) security on the client is set up such that no script can make any harm on your system. You can easily write a malicious LotusScript function, but:

    1. You cannot launch it automatically, unless you design a forged memo form, even in which case if the client mailbox does not allow stored forms, it will not work.

    2. You can do little on the client, actually you cannot even *read* from a database without user's approval with the default security settings... It also shows the digital signature of the creator of the script. Of course, the user may allow the script to work, but this is something else.

    You can have no definitive way of completely stopping malicious code in a programmable environment, and Domino security model does its best.
  • Still, there is no Domino client for linux. There is a 4.x for Solaris, but that is 4.x not 5.x. Unless you convince IBM to invest in a good Domino client for Linux, being able to run the server on Linux is just worthless. I mean, who cares what platform the server is, if you are still restricted to WIndows as a client. I realize that Domino has a web interface and a Mac client, but they are not very good.

    -matthew
  • It looks great if you want to use aolserver, PostgreSQL and TCL. One of the things I like about PHPGroupware is the ability to use several webserver/database combinations (PostgreSQL, MySQL, Oracle, Apache, IIS, Unix, OS/2, Win32, etc.) . It's good to see several projects that are having some good success so we can find the project(s) that fit our particular needs.
  • As someone mentioned earlier, there already is a groupware product for Linux. It's called Lotus Domino.
  • I think I have to agree with you, unless, (and I am not a programmer here) they can do it in a secure manner. I really don't see how that's possible though I doubt M$ has ever tried.
  • Pine is the Yugo. Yeah, it can get you from home to work but there isn't much dignity along the way. The Concorde, on the other hand, might burst into flames every few years but there is no more enjoyable way to travel.

    It isn't a question fo wether or not the Concorde will burst into flames, but that the security around it is so piss poor, anyone could attach and explosive to it and blow it up at will.
  • Like I said, I run Outlook and I have no problems with it. I know what to look for though. It's the uneducated or foolish users that make the job of an internal IS person horrible but gives the unexperienced hacker something to boast about. I guess it depends on your point of view.
  • I think that this is necessary if the open source community expects to be a major player in the business world. The "managers" of most companies (you know them, the old guys in suits who always forget your name) don't really care what's running their e-mail/project/calandering/whaever software, they just want it to do what they need, and they want to pay as little as possible for it. Until this project is finished, we have nothing. I know that you will want to come back with "What about the places where Linux is used like web servers and the such. Remeber, this is a discussion about Group Ware. I have heard of no international company that is using sendmail because it's more stable. They all want Exchange/GroupWise/Notes because they offer the functionality businesses want. Of course, that's just my opinion, I could be wron Copyright Dennis Miller)
  • I would love to see a piece of software that could replace the bug-riddled Outlook/Exchange/IE/whatver_else_exisist_on_your_c omputer. If they can pull this off while keeping it secure from the most novice of hackers, I will definitley be into it.

  • Jabber fits nicely here (Score:2)

    by Anonymous Coward
    Sounds like a perfect place to use Jabber for distrubution and transport. It will provide an open, mature and extremly well designed transport layer based on XML to connect clients and servers.

  • Let's separate the issues here (Score:2)

    by Anonymous Coward
    I am a messaging guru with 8 years of experience, and have worked with everything from Lotus Notes, cc:Mail, Exchange, MS-Mail, and *nix (sendmail/qmail/POP/IMAP). I think we should separate this into front-end and back-end systems.

    On the back end, there are a number of commercial and non-commercial solutions available. Exchange and Notes are both excellent enterprise-class messaging systems, provided you have the time and the staff to keep them running. HP OpenMail is also a very nice, but lesser-used solution, and is one of the few non-Micro$oft products that includes MAPI support. And I've already mentioned sendmail/POP/IMAP.

    The back end system needs basically three things: a directory, Message Transfer Agents (MTAs) and a database (mailbox storage engine). MTAs for Linux are free and mature (sendmail / qmail / procmail) and most POP/IMAP servers maintain their own database. Yes, mail can be stored locally, but if you don't sit at the same computer all the time (or you need to access your mail via the web) the mail must be stored on the server. Directories are a must for enterprises. Reasonable solutions already exist for these functionalities.

    However, my biggest concern is on the client side. Other than Evolution (which is still quite beta) I'm not aware of a *free* mail reader / PIM that combines everything that Notes or Outlook has: seamless calendaring, nice address book / contacts / directory / mailbox organization / rules / etc. I really do believe Outlook is the best-of-breed in this regard, but it only runs on Micro$oft OS's. I would be happy to pay $50 to run Outlook on Linux, but that isn't aligned with Micro$oft's goals AFAIK (although it might be if the apps and OS were held by separate companies (hint,hint DC Appeals Court)).

    So, folks, the server pieces are already out there, although there is no fully integrated (ala Exchange / Notes Domino) solution available with free software that combines the directory, MTAs, and mail storage database :-( which are necessary for enterprise adoption. And on the client side, Evolution looks like the best bet, but it's not ready yet.

    As Open Source marches onward, I am confident we'll see better and better solutions emerge that offer integration and full client/server choice (how about Exchange back end, Evolution front end, with all the Calendaring / Contact Management goodies working in enterprise fashion) for servers and clients.

    "That'll be the day" -- Buddy Holly
    "Mistakes are the portals of discovery" - James Joyce
  • I think it could be done properly given a lot of work and good design, but I'm still not a big fan of Java. I guess it'll take a few years for the applications to get there; I suppose the performance will catch up for a word processor, but it'll still burn a lot of cycles.

    However, using CORBA to tie it all together would be interesting. Then the Java could really be more of a glue language, and maybe we could re-implement parts of it natively for extra speed or efficiency.
    ---
    pb Reply or e-mail; don't vaguely moderate [ncsu.edu].

  • Sounds great -- when will we be getting a generic SQL interface?

    Unfortunately, the time required to abstract out the DB is significant enough that it's better to just pick a DB and go from there. Arsdigita [arsdigita.com] made this decision and went with Oracle. Slashdot made this decision and went with MySQL.

    Although there is a SQL "standard", not many DB vendors adhere 100% to the standard (Oracle being the #1 culprit), or only implement 70% of the standard. You can only do so much with SELECT and UPDATE queries -- eventually you really need something like PL/SQL triggers.

    Plus (just to rain on your parade a little more), which DB you choose makes a difference. Go with MySQL? Well, now you have to work around the table-locking problem (a HUGE problem if you're dealing with 100s of users). Go with Informix? You've got a different CHAR limit than Oracle.

    Abstraction is a neat idea, but unrealistic. By the time you've worked around the abstraction problem, Outlook is on version 1000 and runs circles around your Free implementation.

  • I sure hope so; I'm deeply interested in trying to apply groupware to some of my client's needs; but I'm unable to actually contribute anything, because I can't program and I'm not entirely sure what-all groupware can/should/might do... :-(

    --
  • ...at developing an open-source groupware app, that I'll believe it when I see it. Sad to say, but none of the half-dozen I've investigated over the past three years ever made it past the "talk about" stage. :-(



    --
  • A: Microsoft is not a brand in Office. The idea was not even originally from M$.

    B: The question is not who wins but if we get a damn market. M$ destroyed every Office concurrent it could. And please note that Excel was synomin of suxxx before QuattroPro and Lotus123 went into oblivion. And the reason was far from being a market one. I was a Quattro user and had a fair knowledge of the power of this spreadsheet. Yes scripting language was a misery but it was much more powerful and exact than Excel. But this was the only minus. However I saw Quattro dying because of a cascade of growing incompatibilities with Windows95. Every time M$ changed DLLs in its upgrades, new programs or patches, we got Quattro hanged for good. This general phenomena caused by the ill-famous Microsoft Foundation Classes and a few other trash, brought many programs to their death by the end of 1996. By that time, I noted that more than 60% of shareware and free software I used on Windows since 95 was completely unusable.

    So here i see only one problem. That M$ will not start implementing linux apps.

    C: by linux users for linux users. Because we don't have M$... Thanks God...
  • It may be History for you. The fact is that after a large timebreak, due to incompatbilities with Linux/Solaris systems, we are returning several services to Novell servers... Anyway we never stopped using Novell with Windows workstations.

    However Windows, as a server, IS History. Even the experimental 2000 server didn't make its third month. RIH...
  • Java 1.0 tech had too many limitations when Corel tried to build an office product around it.
    Now, however, Java 1.3 has addressed many of these deficiencies. Printing support is there, performance is there, garbage collection, threading, and the graphics libraries are mature. I'd like to see someone give it another go, if not with Sun's jdk one of the others.

    SOAP or CORBA could allow other languages to interface nicely.

  • It's kind of fun to figure out what Novell coulda/shoulda/woulda done to actually own the Groupware market.
    • NDS-Groupwise integration NDS and Groupwise were never actually integrated per se, only meshed. The actual Groupwise directory was totally seperate from NDS, along with any Groupwise properties. There are several schema extensions for NDS that address Groupwise properties, but the application doesn't use them. NDS Groupwise integration is largely a myth, at least compared to ADS/Exchange integration.

    • Not dropping Mac/other support Say what you will, but we got into GW initially because it was the ONLY cross-platform email/scheduling program worth a damn. After 5.2 Novell walked away from the Mac (as they did with Netware) which only pushed users into MS arms. Novell USED to provide clients for Solaris and SCO (which would actually run under Linux with iBCS emulation). My understanding of this is that the client end went through a lot of "What do we do next????" at Novell. First there was the Web/Java fad, then the XML fad (which may still be popular) and who knows what fad now.
    • Failing to open their APIs and Database This is why you see Groupware integration products for loads of products and almost none for Groupwise. Novell doesn't want to give away the magic to their proprietary database ("security" of the "encrypted" database store is the usual excuse).
    My personal feeling is that if GW5.2 had been client server based on IMAP, with well-documented Groupwise-specific IMAP extensions (either message content, server commands, or both) and a SMTP-based MTA (again, with documented content or command extensions) we'd be in great shape. A server that could talk to any other server via SMTP, and a client that can talk to ANY IMAP server. With the extensions to IMAP and SMTP opened and documented, loads of clients could have talked to the Novell server and loads of other compliant products could have been written.

    But instead, they went with proprietary stores, protocols and a half-integrated directory. Now they're falling into the grave..
  • If you want to have some fun, you should write to Coke and Pepsi and tell them about the bars that are serving Pepsi when you order Coke. When a waitress asks you "Is Pepsi OK?", that's coming down from the soft drink manufacturers. They are all about brand, and hate the thought that their products might be considered interchangable. This probably won't get the bars to stock Coke, but it might make them ask "Would a Jack and Pepsi be OK?"
  • Hmm, I just don't have the time know to find out what this MS DD really is, but take a look at zope [zope.org] (the look should last a little longer, zope is very powerfull).
    Zope provides object serialization with various methods, one of that is xml. Objects build web pages in zope (in fact, everything in zopes object database is an object/method).
    It also does SOAP/xmlrpc/DAV, has session-management (as of zope 2.3) and - to get ontopic again - it's IMO a perfect platform for developing a groupware on. One "just" needed to write a dedicated client in order to surpass any limits which a normal browser might have for that task.
    Search for zopeGUM, it's a groupware in development.
  • iCalendar is the common data exchange format you're talking about. See RFC2445 [ietf.org] for the details.

    Evolution's calendaring facilities speak iCalendar, as will the tools that Reefknot is building. Reefknot [sourceforge.net] is a toolkit client/server project that speaks iCalendar. I hear the Evolution folks are planning a calendar server as well.

  • Exchange and Notes are both excellent enterprise-class messaging systems, provided you have the time and the staff to keep them running.

    I'm just curious -- what system doesn't take time or staff to keep them running?

    I can't think of a comparably powerful system to Notes that is anywhere as easy to administer.

    There are some new concepts for admins to learn, mostly around issues of managing trust, but none of it is is particularly complicated.
  • Nothing will protect us ... from idiots and those who take advantage of them..... people can't be bothered to set there security settings and everytime they get ANYTHING, they just double-click it, infect the file servers, and infect me even though I'm careful...
    ---
  • No, it wasn't absolute brilliance, it was when the company discovered that it wasn't the product that made them the biggest, it was the brand. They brought the old brand back.
    ----------
  • This post is absolutely true. Pepsi actually DOES beat Coke in taste tests. I don't drink much soda, so it doesn't matter to me, but I've been part of an initiative at my company in which we learned brand is everything.

    Right now, Microsoft is the Coke to our generic cola. Doesn't matter how good or cheap it is - even if it's free.
    ----------

  • That's right. Perhaps YOU'd like to train Susie Secretary to use emacs and cvs.
  • Another developer is writing an iCalendar-based scheduling system for it, too.

    You mean two other developers. :-)

    The planned feature set will allow Citadel to share iCalendar objects through Citadel's native transport as well as through iMIP to interoperate with other calendaring systems, and it will be fairly easy to add other iTIP-based transport protocols as they are developed.
    ---

  • The default ECL (Execution control list) security on the client is set up such that no script can make any harm on your system. You can easily write a malicious LotusScript function, but:

    Not relevent. As I said, most new Domino users won't use the Notes client. They'll access Domino through the web or through other email clients.

    The whole Notes model of groupware assumes you do all your messaging with Notes. That was reasonable 10 years ago. Now, you might as well tell people they have to use typewriters.

    __________________

  • Are you going to back up all of the PCs on your network ...?

    Naw, backing up PCs is for wimps. It's OK to back up servers, but only if the archives are inaccessible.

    __________________

  • NFS in no way compares to the text database capabilities of domino/notes...

    Never mentioned NFS. I referred to NSF files. If you know anything about Domino, you should know what those are!

    __________________

  • What is Domino? It's just a DBMS with a web server grafted on. And is it a relational DBMS? Object-oriented? No, it's just a collection of data blobs. It is good at some things (especially data replication) but these are not things everybody needs.

    Notes/Domino isn't really a groupware app. It's a pre-internet mail/news app. You can use it that way (as most early Notes users did), but the same can be said for any discussion program. OK, you can use it to create groupware apps, but I don't see it as any better that way than half a dozen other application servers.

    And I don't see how using Domino is supposed to lock out script worms. OK, there don't seem to be a lot of worms written in Lotus Script, but hey, the hackers are always looking for a challenge. And mail routed through Domino is only as resistent to JavaScript and VBS worms as the mail client used to open it. I don't know if the latest Notes client does JS or VBS. But it doesn't matter -- most new Domino users will access through the web, or through non-Notes email clients. So we're back to Outlook!

    __________________

  • No, Domino is a workflow / text database / collaboration tool...

    No, you're confusing Domino with the apps that have been written using Notes/Domino as a platform. When it was introduced Lotus Notes (and its CDC predecessor [thinkofit.com]) were the only game in town for ad hoc informations sharing. That was cool in 1990 [kappa.ro], but nowadays there are lots of ways to pass information back and forth.

    Come to think of it, I was very enthusiastic about Notes when Lotus first released it. Only the initial high cost kept me away. But now that I can afford it, I find that most of what I wanted to do with Notes can be more easily done with common internet tools.

    Date check: 2001. Using today's standards, Domino simply doesn't stand out as a platform for workflow, textbase, or collaboration apps. The feature set is no longer impressive, the learning curve is too high, administration is too difficult. Time to move on.

    IBM has had some luck pushing Domino as a general-purpose app server. I'm no expert, but I imagine an NSF file is a fairly efficient way to serve up huge gobs of not-very-dynamic content. A long way from what Ozzie & Co. designed it for, but that's life.

    __________________

  • The key concept is the storage engine driving the groupware server - all of the messages and data need to be stored somewhere.

    Well, a storage engine is important. But why does it have to be a server? Notes: The Next Generation (well, the official name is Groove [openp2p.com]) uses a P2P model.

    Come to think of it, Domino also uses a P2P model to keep a network of servers in sync. It's a feature I find pretty impressive -- and I'm not a big Domino fan. In these days of powerful workstations and fast networking, all that storage and synchronization can just a easily occur on the desktop, eliminating most of the server's functions.

    __________________

  • Sure, I'm off-topic, but that was spoken like a true non-alcoholic, holier-than-thou person.

    I am God Damned tired of this lacsadasical attitude of "all colas taste the same". NOTHING mixes with Jack Daniels like Coke does. Admittedly, RC Cola isn't bad and will do in a pinch, but it's not Coke. And don't get me started on Pepsi... too late.

    Living in the middle of nowhere now (Decatur IL) every damned bar for miles serves Pepsi products. HOW CAN A BAR NOT STOCK COKE? How many liquors do people order with Coke every damned day. This is driving me nuts. And unlike in a restaraunt, where the waitress will ask you, "Is Pepsi Ok?", like she could do anything about it and it doesn't frigging matter anyhow, when you're order a drink, they try to sneak it on past you. And if you don't believe that I can tell the difference, you obviously don't drink many mixed drinks, and you've certainly never been out drinking with me.

    Sorry, I'll leave now.

    -Tommy
  • Check out http://www.phpgroupware.net in case .org gets /.ed . We where not expecting this :)
    until (succeed) try { again(); }
  • So you're saying they've taken and copied the functionality of emacs and cvs?
  • bzzt! wrong! Although I was joking, now I shall have to elaborate... from dictionary.com:

    groupware n : software that can be used by a group of people who are working on the same information but may be distributed in space.

    emacs reportedly has email, calendaring, newsgroup reading, and a text editor (the only part I've used). What part of this relates specifically to software development or limits it to that one use? CVS stands for concurrent version system. Again, nothing to do with source code per se. You could just as easily organize your recipes, project plans, websites, or little black book using both of the aforementioned tools.
  • It's interesting that you should have this insight about the store subsystem right now, because the buzz over at Microsoft is, "Let's move all this over into SQL Server." So they're essentially headed in that same direction, as you say. But from what I hear, some of the old-timers over there are rolling their eyes--apparently they've tried it before, and it didn't work out so well. Not sure why, or when... but it would be interesting to find out.

    So, I'm not vouching for any of this particularly, it's just bits and pieces I've picked up from friends who work for da' Man.
  • But some people in the UNIX world just want a small mail client! In the perfect UNIX world, there should be many robust and stable versions of an outlookesque mail client. At the basic level it should have:
    1. Support for all standard mail protocols, IMAP, POP, etc.
    2. Address book for emails
    3. Folders and filters.

    At the next level it should add:
    1. Advanced "crap" like LDAP and weird advanced authentication.
    2. Encryption

    At the most complicated it should get to the Outlook stage and have all the fun "features" of Outlook and Exchange. I am of the opinion that mainstream adoption of UNIXes will be helped by a robust Groupware package like this. Some companies don't want to deal with different programs.
  • hope there is some good security implemented w/ this or it'll open the door for vbs style virus'.
  • Free Software and OpenSource Software wouldn't be anywhere near where it is today were it not for the Internet

    And the Internet wouldn't be anywhere near where it is today were it not for Free Software and OpenSource Software.

    Just an observation.
  • As a GroupWise admin, I say it's about time Linux got a groupware solution. It's not about Outlook or Exchange or even more basically the integration of those components within Linux, as many have discussed before.

    If Linux is to ve a viable business platform, then Linux needs the tools to allow users to communicate and collaborate. This is the purpose of groupware. If Linux is to survive as other than a niche product (albeit a large niche), then it needs to survive in business. Hence the need for a groupware solution.

    Frankly, it'd be nice if the Linux solution worked and played well with others (GroupWise, please?), but there is a need for this application. The only part I would want it to NOT work well with others (Exchange/Outlook) is in propagation of viruses!

  • Nonsense. First of all, Outlook is more than just an email client. It not only integrates calendaring and contacts into the email client, but also allows you to schedule meetings, do things like polls over email, task lists, and project management. Outlook 10 (Outlook XP) will also have instant messaging built into it. It is quite slick.

    You might think that Outlook is bloated then. You'd be wrong. All of this is done using COM components with well-defined interfaces so that integrating all of these is easy.

    Evolution by Ximian [ximian.com] is a free software alternative to Outlook and it is coming along quite nicely. It follows a lot of the same methodology: the application is built using Bonobo (the GNOME component model) components, and since the source is available, it is surprisingly easy to write your own components for Evolution. It does many of the things that Outlook does, although it doesn't (yet, anyway) integrate with MS Exchange. And Ximian, although all of their software is free, is a commerical entity and their software is of pretty high quality.

    There is a ton of work involved, both coding and even more importantly in the design. The Evolution people are spread too thin as it is right now to take care of this, so it is nice to see some other developers making this a priority. It's important to keep a communication channel open between the client guys, though, so make sure you get their input on your designs!

  • Hey, how about Lotus Domino? (Score:3)

    by Anonymous Coward on Tuesday February 13, 2001 @10:30AM (#434769)
    *Sigh*

    Lotus went to some great lengths in helping spread the word that Linux was ready for prime time by porting the Lotus Domino server to this flavour of Unix.

    It is secure, it provides excellent groupware services, it is not prone to .vbs kiddie-scripted viruses, it is scalable and permits you to store tons of documents, images and any other type of data you can think of.

    Please consider that if Linux is indeed ready for prime time, it will have to host non-open source software. It is a fact of life. So, while it is too bad that Domino is not open source, be glad that you have an option in the groupware arena. As well, as Domino evolves, so will the services that Linux users will get and the better off they will be.
  • Specifically, support for vCard aka iCard [ntlug.org] servers and vCalendar aka iCalendar.

    This already provides a set of protocols and data formats standardized under the auspices of the IETF [ietf.org]. There's an XML encoding under way as well as an OMG committee working on CORBA IDL.

    There are already applications that know how to use these protocols/formats, including the GNOME and KDE calendar programs.

    Build a "calendar server" that knows how to store appointments for a horde of users, and a "vCard" server that can accept address info for hordes of users, and use the existing standards to try to build in further sorts of useful interactions.

    This would make the existing tools vastly more useful. It doesn't fundamentally matter whether this involves XML, CORBA, MySQL, or LDAP; those are all implementation details that can probably vary a whole lot without breaking the fundamental idea, which is to build standards-compliant servers.

    That was the whole point to defining these calendaring and scheduling and address standards, namely to provide a standard way of doing the sorts of things that Microsoft built proprietary interfaces into Outlook for.

  • I have to make this obligatory comment every time someone mentions groupware: we are writing exactly what you are asking for.

    The Citadel [citadel.org] project aims to be the "Exchange killer" of open source. SMTP and POP3 are working, IMAP is in development, and we already store user information in vCard format. Another developer is writing an iCalendar-based scheduling system for it, too.

    Our high-performance multithreaded server will be the platform required to build really great groupware applications. At first we'll just use existing clientware, but eventually we'll be looking into writing client drivers for Camel (the API used by Evolution) and MAPI (so the Outlook droids can connect as well). The aim is no less than cross-platform groupware, including shared address books, shared calendaring and scheduling, etc. without the side effect of making Linux users second-class citizens (as is the case when you connect to Exchange server using anything other than Outlook).

    Check this project out. It's exciting.
    --

  • Groupware is empowering (Score:3)

    by pmancini ( 20121 ) <pmancini@ y a h o o.com> on Tuesday February 13, 2001 @10:40AM (#434772) Homepage
    Groupware is not just useful, it is empowering. I have worked in companies that have groupware (Lotus Notes) and I now work in one that doesn't. It is like night and day. I was much more effective in the company with groupware. I think that if the system were to use Interbase at it's core (as I am not overly fond of MySQL) they have a good chance at being very competetive. The big problem I see is that a lot of companies and even a lot of tech geeks don't get groupware - they don't see the benefits of it. This is a shame because it makes all the difference in the world when it comes to software design. It also reduces the number of meetings people have to have. Praise the Lord for that one.

    Overall I am super glad this thing is going to take off.

    --Peter

  • And RC Cola is the bomb. (Score:3)

    by Xiphoid Process ( 153566 ) on Tuesday February 13, 2001 @10:26AM (#434773) Homepage

    You can't mess with a food that has Royal Crown as its title. But seriously, RC Cola has been around for decades in the margins, but is available in most grocery stores. And that is ok. I don't care if it is dominating that market, just that it tastes good. I feel the same about linux, it will always be here, and i prefer its taste.

    One thing to consider, people don't really have reason to hate coke, or at least really arnt aware of why they should. On the other hand, MS is the company everyone loves to hate. I think that as Free Software continues to match and excel in every area that is spills into, there is a very real chance that many people will start to look up to the Linux brand, once all the fear of the new has passed.


  • Coke vs RC Cola (Score:3)

    by Ars-Fartsica ( 166957 ) on Tuesday February 13, 2001 @10:08AM (#434774)
    People don't care if it tastes nearly exactly like Coke at a lower price - they want Coke. Branding matters. Microsoft is the brand in Office software. That doesn't mean OpenOffice isn't worth pursuing, but don't expect it to win over current Office users or any serious potential customers - this is going to be like most other open projects - by linux users for linux users.

  • Re:Here's my part of the discussion (Score:3)

    by micromoog ( 206608 ) on Tuesday February 13, 2001 @10:28AM (#434775)
    Is it possible to implement a solution built on top of MySQL or Postgres, or something else that might scale well?

    Even better: why not implement it with a truly open, generic SQL interface (with options for hand-tailored optimizations) so you could use anything as a backend? This way, users of this software could involve the DB backend they already have (commercial or otherwise). Scalability then becomes an external issue, if the interface is strong and generic.

  • Good but... (Score:3)

    by Bug2000 ( 235500 ) on Tuesday February 13, 2001 @10:21AM (#434776)
    What about XML-EDI [xmledi.org], UDDI [uddi.org], EbXML [ebxml.org] (nice little article [xml.org] about the 3 initiatives)? Ok, it is not specifically aimed at groupwares but rather at distributed applications. But, on the other hand, are groupwares aimed at staying localized in just one area ? I'm not too sure. I believe groupwares will slowly mutate to an application server-like architecture where different parts will be build by different companies. Well apart from MS I mean...

  • Outlook for Unix is betrayal (Score:3)

    by Urban Existentialist ( 307726 ) on Tuesday February 13, 2001 @10:04AM (#434777) Homepage
    Why do we want to emulate Microsoft in this area? The last thing Linux needs is a fully integrated mail client. Such things are best left to the commercial world, where they are done well and with skill and talent. The only Open Source projects that work are the ones that can be broken down into simple components, and reused, according to the typical Unix and Linux philosophy. Something like Pine works just fine, we do not need a bloated and useless client.

    Another problem is that mail clients of that sort tend to hegemonise. Before you know it, non-standard mail formats are proliferating and everybody has to use the same mail client. Look at Outlook on windows.

    We should not emulate this on Linux. We would be killing ourselfs, and strangling the Linux desktop at its birth.

    You know exactly what to do-
    Your kiss, your fingers on my thigh-

  • Good idea. (Score:4)

    by pb ( 1020 ) on Tuesday February 13, 2001 @10:01AM (#434778)
    I remember that Corel already did some work on this, and decided that Java wasn't the answer. PHP might be ok for the Server-side, but personally I'd just want to see more speed...

    I hope we have a free alternative before the .NET initiative gets off the ground; I don't want to see how that gets licensed. One of the big things in the .NET project is the common language runtime they worked on; I'd love to see an open answer to that.

    Why doesn't anyone make a JIT C Compiler, and maybe specify a small API with multiple platforms in mind; it seems to me that this would be much easier to implement efficiently than Java, and could probably support a lot of legacy applications with a little porting, if done correctly...
    ---
    pb Reply or e-mail; don't vaguely moderate [ncsu.edu].

  • Workgroups (Score:4)

    by Ektanoor ( 9949 ) on Tuesday February 13, 2001 @10:58AM (#434779) Journal
    I would like to add some pepperspray flame here. Frankly Workgroup idea was a great idea. I mean "was" because Microsoft demolished the whole thing into a cartoon.

    In the beginning of the 90's there was a big trend on software developers for the creation of Workgroup application packets. The Office suites were a result of this trend. I would like to note that, by that time, almost everyone was going on the correct path, even Microsoft. However it was Novell who did a real step into this world. They had the most complete conception of workgroup by uniting three elements into one - user management, office apps and communication systems. This resulted in the NDS + WP Office + Netware. Note that Novell didn't put too much emphasis on creating a whole world of himself. Anyway they based their most of their work on Windows. And this was their error.

    Microsoft NEVER achieved the level of perfection Novell did. N-E-V-E-R. Frankly, by the beginning of 1995 Novell did have a working horse capable of working. However most of it was based on 3.11 and when 95 came into the market, most apps didn't work. By that time I was working in an office mostly Novell based and was amazed to see how "unfriendly" was Windows95 to Novell. QuattroPro 6 a spreadsheet that was much more superior to Excel95, hanged miserably on 95. Paradox which cannot be compared to Access also suffered a lot of crashes and utterly died. and this was a big gamer on small office databases by that time. WP was probably the looser but it was more a problem of esthetics as the program was much more professional than Word.

    By that time Novell already hd started to integrate this office system with NDS. M$, until now does not have an equivalent (don't tell me about -2000, that's not a server OS). And that was the core of the workgroup system. NDS divided people by groups and resources over a whole tree and provided rights to access such resources. Anyone who worked with NDS knows that there is practically no equivalent to it. Under such system it is possible to easily manage thousands of resources from one location. And easily provide resources in a congruent form.

    These things were the true core of the workgroup system. Today most people consider workgroup most as mail exchange + office apps. Sometimes conferecing is added to this. However a much larger segment of workgroup system is completely ignored or sent into backstage. To remark this I would like to point some important points of these segments:

    Admin functions - Worksation control. User "travelling" between workgroups, resource containers, offices. Interaction between workgroups and large corporate resources.

    User functions - Documentation versioning, Flexible messaging among workgroups with a large number of users, Flexible resource sharing with a capable ACL system, advanced conference systems concerning not only the use of multimedia but also an easy managing of other resources (ex. disk space) for temporary purposes. Dynamic, stable and rapid distribution of resources on very large scale and not depending exclusively on the hardware basic units.

    And many more. M$ does this. I didn't say it didn't. I only said it is just a cartoon of a real workgroup world...

  • Groupware could be a killer app. (Score:4)

    by hey! ( 33014 ) on Tuesday February 13, 2001 @12:00PM (#434780) Homepage Journal
    If groupware is defined as software which helps groups collaborate. Most people don't work in isolation.

    Having dones some work with Notes, the stuff that is being put together open source falls pretty far short of what groupware could be. It seems that open source groupware in practice boils down to: e-mail (which for some reason is called messaging), calendars, and group discussions. These are valuable applications, but they aren't anywhere near what people really need to really collaborate.

    For most people collaboration is about the management of documents.

    For example, many large organizations have approval processes for certain kinds of actions: approval of a loan application or insurance claim for example. A particular document needs to be routed to a specific persons who can approve them in a verifiable way (through a signature -- ink or digital).

    The kind of address books that people are putting together fall far short. I'd like to be able to look up ACME Co., then see all the telephone calls, correspondence, proposals, documents related to them. Likewise when I look up information on a widget, I might want to navigate to ACME Co.'s information if they are a supplier or if they are user with tech support problems.

    I'll give you a concrete example. My boss organizes client files into different places depending on whether they are "hot" or "cold". This perfectly meaningful and clear to him, and helps remind him who he needs to be working on. However, I have no idea who he considers hot or cold, so I'd be happier with a system that organizes clients alphabetically. In fact I may have my own hot and cold lists that are different from his.

    What makes a relational database a win over flat files? The ability to reorganize and combine data with great flexibility.

    This is kind of a meta-design pattern. It's a win when you can use a technology to reuse a piece of data. There needs to be a way in which documents (defined) can be created, stored and indexed in a more flexible way. This means you need some kind of database metaphor, some kind of compound document representation mechanism, and some kind of user interface.

    Oh, and it should be cross platform.

    Notes with OLE2 is pretty far down this path -- much farther than the open source stuff I've seen. You can create documents with OLE containers and Notes will happily select and sort them different ways and index them by direct attributes and by OLE contents. Notes has a number of inherent limitations though. They tried to bridge the gap with Domino Doc, but last time I looked at it, it was very kludgey and complicated, probably due to new capabilities being bolted on top of legacy technology. Things may be better now.

  • I've been lurking here for a while, and just couldn't hold back from
    joining in the discussion.

    My .02 follows

    Dan Kuykendall wrote:
    >
    > Yes, most are all dead because they couldnt build a solid foundation to
    > work from. Running the phpGroupWare project, along with being a
    > GroupWise and then Exchange and now Notes admin has taught me a
    > considerable amount about groupware systems. I feel like I can build a
    > design with the help of a few others with experience writing and
    > maintaing groupware systems. With this small group we can get something
    > done faster and then can open up for public discussion/critisism.
    >
    I used to be an admin for this sort of thing. I was at one time a certified engineer and instructor for WP Office
    (when it was an email product - before Novell bought it and turned it into GroupWise) so I understand something about
    the architecture of a product like that. I was a Notes admin briefly, too, and managed to escape prior to having to implement Exchange.

    Today I'm an exchange user - and a fairly hefty one at that. Exchange holds my corporate database - tasks, calendar and contacts as well as records my communications with others. I depend greatly on this database.

    The key concept is the storage engine driving the groupware server - all of the messages and data need to be stored somewhere.

    As I understand it, Microsoft is kicking themselves now for the Outlook/Exchange architecture - sync is a real hassle, and of course RPC
    over NetBIOS over TCP/IP is a lousy solution anyway.

    They are in the process of moving to a new infrastructure using http as the transport, XML as the data format, and relational DB technology on the client. Their ost and pst solutions are terrible at handling large qualtities of data!

    If we can implement something similar to what MS is starting to build today - starting with the back end and progressing to having a service on the client providing sync and archive services, we'll have something worthy of competing with Domino and Exchange.

    The primary consideration is determining the architecture and the engine that will drive the technology.

    I'm no DB geek by any definition, but has anyone thinking about this considered what/how the database ought to work? Is it possible to
    implement a solution built on top of MySQL or Postgres, or something else that might scale well?

    Once we've defined the back end, it should be as simple as building a wrapper around the technology that we select. (I know that's a major
    oversimplification.)

    Realistically, whatever engine is selected will determine the architectural limits of the size of implementations. Ideally we could pick something that would scale at least to a mid-size business, and while data storage capacities will increase dramatically as we move forward, we need to consider user data sizes in excess of 2GB. While most users don't need that kind of capacity, many do.

    We've seen talk on the evo list about scalability issues between maildir and mbox, and unless we account for that in terms of user data needs, the open solution will have real scalability problems.

    Additionally I believe strongly that we should not re-invent the wheel on this one. The good news for us is that the base protocols are
    already defined, and the problem is one of data organization rather than message flow. We can leverage open standards like http, ssl, xml in the process, and leverage open source engines to help read and write the data.

    There are some things for which there are not open protocols - for example, tasks (AFAIK) - but that need not slow down the vision or early
    versions.

    What's it going to take to get others of you involved in this? To add some detail to the picture of a truly open groupware server platform?
    Surely you have needs that aren't met by existing products....

    > > I'm all for getting gung-ho and putting fingertips to the keyboard, but
    > > it's wasted effort if you don't have a coherent concept. I'm not
    > > advocating committee paralysis, just some simple discussion over what
    > > will / will not be addressed in the project and setting some priorities.
    >
    > I agree we need the concepts first, and I fully plan to work that way.
    > but I dont plan to have every tiny function decided before I start
    > hacking.
    >
    Plan the work, work the plan.

    Let's pick an attainable scope of features, determine minimum functional requirements for those features, and then get started. We need not
    define a huge feature set initially, but we need to understand the architectural consequenses of decisions made when implementing those
    features.

    The scope of features for version, say 0.1 will tell us when that engine has everything that it needs, and the functional requirements define the minimal quality requirements for those features - the features are done when the quality requirements are met.

    Thanks for letting me get this off my chest.

  • Good idea, but... (Score:5)

    by dialect ( 75360 ) on Tuesday February 13, 2001 @10:28AM (#434782)
    Whenever groupware is discussed, the capabilites get tied to implementation specifics apps. I would be happy if we could just get some standard data exchange formats defined so that I can share appointment/contact/planning data between my PDA, desktop (linux/MS), web interface, etc. without hassling too much with data formats for application settings. Get that working, then start discussing more sophisticated group ware.

    PS. iCAL and reefknot look like interesting projects

  • Communication is The LifeBlood of Free Software (Score:5)

    by LionKimbro ( 200000 ) on Tuesday February 13, 2001 @10:19AM (#434783) Homepage

    Free Software and OpenSource Software wouldn't be anywhere near where it is today were it not for the Internet. The only reason Linux progresses as it has, I believe, is because we've had the Internet. It just wouldn't work with people mailing each other back and forth.

    I believe that the next big steps in communication will come through groupware, and that groupware is the #1 thing that we can invest our time and energy in to, to receive maximal payback in the form of OpenSource and Free Software.

    It needs to be dirt simple for us to create and destroy projects, set up mailing lists, votes, build databases collaboratively, vote, instant message, chat, etc., etc. When it's fluid, we'll reach a new level of community building and communication, which will redouble our ability to work over the Internet with one another.

    We need to be able to easily embed groupware into our standard applications. It needs to be easy for a user to look something up in the documentation, note a minor bug, (spelling error? incompleteness? technical error?) make the adjustement, have the adjustment sent and approved by a moderator, and then applied to the text. All software should be able to easily manage docs like this.

    We need to be able to say, "I need help," after looking through the docs, flag our ICQ or IM or whatever as "I am someone who needs help using THIS tool," and someone from the dev mailing list for that tool who has the "I am someone who can help you with THIS tool" flag set put in contact with you. It needs to be seamless, it needs to be easy, and it needs to be ubiquitous.

    Another breakthrough will arrive when we can seamlessly communicate with audio-video over the web, between countries, and hold group meetings over the web.

    Whenever you want to learn something, someone will be ready to teach you, face to monitor to camera to face.

    Again, I think that the best thing you could work on if you want to improve OpenSource and Free Software is GroupWare.

    The major changes we've seen coming from Open Source and Free Software are just the tip of the iceberg, and I think it's something that we should all be excited about and proud of.

  • Re:Outlook for Unix is betrayal (Score:5)

    by NineNine ( 235196 ) on Tuesday February 13, 2001 @10:19AM (#434784)
    You've obviously never used Outlook. Outlook isn't about email. Outlook, when used in combination with Exchange, is GROUPWARE. It integrates (pretty well, in my opinion), email, calendar/scheduling/meeting schedules, contacts, task lists, basisc notes, newgroups (both public and private) and jounaling. Outlook + Exchange, when used correctly, is an integration of what most offices currently kludge together: email clients, various contact lists, meeting room and meeting schedules, Rolodexes, newsgroup clients, random phone calls, and lots and lots of Post-it notes. Outlook isn't jsut a bloated email client. It's a front end to Exchange.

Slashdot Top Deals

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (1) Gee, I wish we hadn't backed down on 'noalias'.

Close