Slashdot Mirror
Making The Case For Open Groupware
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.
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.
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.
:-( which are necessary for enterprise adoption. And on the client side, Evolution looks like the best bet, but it's not ready yet.
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
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.
pb Reply or e-mail; don't vaguely moderate.
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 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.
Potato chips are a by-yourself food.
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... :-(
--
--
Don't like it? Respond with words, not karma.
...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. :-(
--
--
Don't like it? Respond with words, not karma.
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.
- 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 (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.
Evolution's calendaring facilities speak iCalendar, as will the tools that Reefknot is building. Reefknot is a toolkit client/server project that speaks iCalendar. I hear the Evolution folks are planning a calendar server as well.
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...
---
DO NOT DISTURB THE SE
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.
----------
Stupid sexy Flanders.
Right now, Microsoft is the Coke to our generic cola. Doesn't matter how good or cheap it is - even if it's free.
----------
Stupid sexy Flanders.
That's right. Perhaps YOU'd like to train Susie Secretary to use emacs and cvs.
Ok my karma is maxed out. When do I become Enlightened?
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.
---
How am I supposed to fit a pithy, relevant quote into 120 characters?
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.
__________________
Naw, backing up PCs is for wimps. It's OK to back up servers, but only if the archives are inaccessible.
__________________
Never mentioned NFS. I referred to NSF files. If you know anything about Domino, you should know what those are!
__________________
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!
__________________
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) 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
"I got a half gallon of Jack, and 2 dozen Ant Traps. I'm about to get wild." -me
Check out http://www.phpgroupware.net in case .org gets /.ed . We where not expecting this :)
until (succeed) try { again(); }
until (succeed) try { again(); }
So you're saying they've taken and copied the functionality of emacs and cvs?
I do not have a signature
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.
I do not have a signature
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.
No relation to Happy Monkey
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.
Check out Althea for a stable IMAP email client for X. Now with SSL!
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!
Little girls, like butterflies, need no excuse. -- L. Long
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 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!
dude, assbarn it.
*Sigh*
.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.
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.
This already provides a set of protocols and data formats standardized under the auspices of the IETF . 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.
If you're not part of the solution, you're part of the precipitate.
I have to make this obligatory comment every time someone mentions groupware: we are writing exactly what you are asking for.
The Citadel 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.
--
Tired of FB/Google censorship? Visit UNCENSORED!
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
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.
got drum'n'bass?
http://mp3.com/vitriolix
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.
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.
What about XML-EDI, UDDI, EbXML (nice little article 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...
É que os desafinados também têm um coração
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-
You know exactly what to do-
Your kiss, your fingers on my thigh-
I think of little else but you.
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...
.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.
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.
pb Reply or e-mail; don't vaguely moderate.
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...
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.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
I've been lurking here for a while, and just couldn't hold back from
.02 follows
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.
But Herr Heisenberg, how does the electron know when I'm looking?
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
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.