Slashdot Log In
Making The Case For Open Groupware
Posted by
timothy
on Tue Feb 13, 2001 02:53 PM
from the gotta-have-connections dept.
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
|
Log In/Create an Account
| Top
| 141 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
|
2
(1)
|
2
Hey, how about Lotus Domino? (Score:3)
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
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.
What's needed is servers for existing protocols (Score:3)
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.
We're writing exactly what you're asking for. (Score:3)
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)
Overall I am super glad this thing is going to take off.
--Peter
And RC Cola is the bomb. (Score:3)
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)
Re:Here's my part of the discussion (Score:3)
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)
Outlook for Unix is betrayal (Score:3)
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)
I hope we have a free alternative before the
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)
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)
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.
Here's my part of the discussion (Score:5)
joining in the discussion.
My
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)
PS. iCAL and reefknot look like interesting projects
Communication is The LifeBlood of Free Software (Score:5)
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)