Domain: citadel.org
Stories and comments across the archive that link to citadel.org.
Comments · 184
-
Re:If that's the case...
Naw, try Citadel instead. It has some really nice features and is still maintained. With all of the lawsuits, privacy problems, spam, and governments fighting for control (of both the Internet and it's users), it's something I've considered.
-
IMAP is...
It's good that we have a standard protocol that all mail clients can use to access all mail servers. It's good that the protocol is open and unencumbered. It's a shame, though, that the protocol we standardized on was IMAP.
IMAP is an ugly, convoluted mess. And as I tend to rant about often, overly complex protocols encourage buggy implementations. "Keep it simple, stupid." If something like POP4 had become the standard, there would be a better selection of quality, non-troublesome email clients out there.
Although, with an increasing number of richly functional webmail systems out there now, perhaps the email fat client will become less relevant anyway. Of course, email clients will never go away entirely: you still need text-based access (pine and elm), and non-interactive clients such as Fetchmail...
Oh hell, I'll just come out and say it... anything is better than Outlook. :) -
IMAP is...
It's good that we have a standard protocol that all mail clients can use to access all mail servers. It's good that the protocol is open and unencumbered. It's a shame, though, that the protocol we standardized on was IMAP.
IMAP is an ugly, convoluted mess. And as I tend to rant about often, overly complex protocols encourage buggy implementations. "Keep it simple, stupid." If something like POP4 had become the standard, there would be a better selection of quality, non-troublesome email clients out there.
Although, with an increasing number of richly functional webmail systems out there now, perhaps the email fat client will become less relevant anyway. Of course, email clients will never go away entirely: you still need text-based access (pine and elm), and non-interactive clients such as Fetchmail...
Oh hell, I'll just come out and say it... anything is better than Outlook. :) -
There are several projects like this.
If you like the idea of an open source collaboration suite, you might also want to check out Citadel, which has been around for quite some time and offers many of the same features. It's very easy to install (doesn't require any manual mucking about with database servers etc.) and has mail, calendaring, address books, bulletin boards, real-time chat, instant messaging, IMAP/POP/SMTP, GroupDAV, and an attractive web front end with an increasing amount of AJAX functionality.
As I said yesterday in another comment, there won't be just one open source replacement for Exchange. Everyone will end up selecting the one whose features fit their organization best, rather than Microsoft's "one size fits all, and you have to use Exchange if you want to use Outlook" approach. -
*cough* whoopedoo *cough*
Citadel has been around for years (isn't/wasn't vapour) and is trivial to setup, and supports basically every mail protocol in use (add NNTP to the list once I'm finished developing the code for it) and a full GroupDAV implementation (last time I checked no one else has that yet).
Citadel is driven more towards online communities than small workgroups though, but it works. Apart from maintaining a patch to use bogofilter instead of spamassassin, I rarely touch the install now.
Disclaimer: Very happy Citadel user. And amateur code hacker. -
This will take a long time...
...but it will be worth it. The goal, of course, is standards-based functionality for PIM (Personal Information Management) software. Yes, people really do want a replacement for Outlook, and the open source community would do well to offer complete, end-to-end solutions. Combine the Lightning client with standards-based servers and you've got a good shot at finally getting people to dump Outlook and Exchange.
Here's the thing, though: everyone seems to assume that we need an "Outlook Killer" and an "Exchange Killer." This is, in fact, not true. "One size fits all" only works for Microsoft because Microsoft forces that model. In an ideal world, everyone will select the products that fit them best, and those products will all work together. That means some folks might choose Lightning, some might choose Aethera instead, and they'd still be able to interact with each other's calendars. On the server side, the dozen or so open source groupware servers such as Kolab, OGo, Citadel, and PHPgroupware would all be able to speak common protocols with Lightning and other clients. Users would choose based on other features; for example, one organization might want strong support for forms-based workflow, another might want rich real-time communications, another might want a large selection of third-party plugins. The idea is to allow people to choose their software based on the feature set, rather than by being locked into one choice because, for example, only Exchange supports all the features of Outlook.
It's going to take a lot of cooperation but we'll get there. -
This will take a long time...
...but it will be worth it. The goal, of course, is standards-based functionality for PIM (Personal Information Management) software. Yes, people really do want a replacement for Outlook, and the open source community would do well to offer complete, end-to-end solutions. Combine the Lightning client with standards-based servers and you've got a good shot at finally getting people to dump Outlook and Exchange.
Here's the thing, though: everyone seems to assume that we need an "Outlook Killer" and an "Exchange Killer." This is, in fact, not true. "One size fits all" only works for Microsoft because Microsoft forces that model. In an ideal world, everyone will select the products that fit them best, and those products will all work together. That means some folks might choose Lightning, some might choose Aethera instead, and they'd still be able to interact with each other's calendars. On the server side, the dozen or so open source groupware servers such as Kolab, OGo, Citadel, and PHPgroupware would all be able to speak common protocols with Lightning and other clients. Users would choose based on other features; for example, one organization might want strong support for forms-based workflow, another might want rich real-time communications, another might want a large selection of third-party plugins. The idea is to allow people to choose their software based on the feature set, rather than by being locked into one choice because, for example, only Exchange supports all the features of Outlook.
It's going to take a lot of cooperation but we'll get there. -
Re:It looks impressive
I own a small hosting company,and wanted to see what web-based mail clients were out there that I could use for my customers. Squirelmail and TWIG looked pretty ugly in comparison.
There are lots of good ones out there now. If the customer doesn't already have an email infrastructure, you might also want to have a look at Citadel, which has all of its data stores and protocols built in (even its own HTTP engine so you don't have to integrate it into your Apache server). It has an attractive web UI with a small but growing number of Ajax-style features, as well as an address book, calendar server, a simple instant messaging server, and a real-time chat server.
(Disclaimer: I am a developer on this project so I'm admittedly a bit biased towards it. But, the hosting company I work for has committed to offering it as its standard mail server package in the near future, so I think it's worth something.) -
Why would we want to lock-in to Microsoft again?
Microsoft isn't the sweetheart of the developer universe anymore. Anything they offer now is too little, too late. Nobody trusts Microsoft anymore. And besides, would you want your "Web 2.0" apps to depend on Microsoft products and services? It doesn't take a rocket scientist to figure out that if you use Microsoft tools and API's, you're not going to end up with "web applications" -- you're going to end up with "Windows applications that are delivered via the web."
Around the turn of the century, the phrase everyone was spewing was "whoever controls the browser, controls the Web." Microsoft proved that this isn't true. They had a near-monopoly on browsers for years, and they blew it. They just let the browser stagnate while they went back to focusing Bill Gates' pet projects, like tablet computing and putting a database in the filesystem. Now Google is finally realizing the Netscape dream of turning the web into a pervasive computing platform, and suddenly Microsoft has to go into react mode again. Microsoft does not innovate. Microsoft reacts. And Microsoft gets pissy whenever someone other than them starts succeeding in the technology world. They're a bunch of spoiled brats. Is it any surprise that those of us who are building the next generation of applications are hesitant to go anywhere near Microsoft? -
Can you split the users up?
If you can split the users up, perhaps by suborganization or by geographic area, you might (and I say might because no one answer is right for everyone) be well served by having lots of different servers handling email for each group, and then aggregating it all together with a head end that handles email routing and directory services.
If you're putting more than a few hundred users into an Exchange environment, that's how Microsoft would have wanted you to do it. Although notoriously unreliable, the concept is sound. In the non-Microsoft world, you could build each area as a subdomain, deploy the usual tools (such as the SMTP and IMAP daemons of your choice), and then use OpenLDAP to tie it all together, and add some sort of Postfix or Sendmail routing system to make the subdomains invisible to the outside world.
Some organizations might even consider an open source email/groupware system like Citadel that can handle a distributed network like this; it can tie together lots of servers using its own peer-to-peer protocol and share a global address book without the need to use subdomains (and any individual server is capable of being an MX for the whole network, so you might not even need a hub server at the head end -- although you might want to use one anyway in order to centralize your border services like spam/virus filtering, archival for Sarbanes-Oxley auditing, etc.).
In summary, if you distribute and/or federate the email services, you gain the benefit of removing the single points of failure, and you can potentially put the servers closer to where the users are, reducing your bandwidth expenses. -
AJAX will stop XAML dead in its tracks.
I can't believe nobody has mentioned XAML yet. Doesn't anyone remember hearing Miguel de Icaza ranting and raving about how XAML was going to spell the end of cross-browser, cross-platform web applications as we knew them, because everyone would be writing stuff that requires a browser that has the entire
.NET API embedded inside it?
It's becoming very clear that AJAX is going to stop XAML dead in its tracks. Microsoft was pushing this whole "rich vs. reach" thing, but with AJAX you really can have it all. No need to restrict your user base to Windows XP or Vista in order to get rich controls in your web apps.
I think that's the more interesting story here. The monopolistic Windows desktop isn't going to disappear overnight, but the continued existence, improvement, and increasing pervasiveness of web applications will continue to make the non-Windows desktop more viable and widespread. (Click on the link in the previous paragraph to read a longer piece on why this is the more interesting story.) -
Speed vs. functionalityThe speed of any MTA is going to be determined largely by how much work is being performed when each message is submitted. The fastest MTA, therefore, is going to be the one that does the least amount of processing.
- How about that spiffy big Postfix or Sendmail box you've got sitting out there, whose sole purpose in life is to act as a relay? Sure, it'll process millions of messages per day. It doesn't have to do much.
- What if you're running a virus checker like ClamAV or a spam checker like SpamAssassin? Those take up CPU cycles. Sure, delivery is slower, but value was added.
- What if your back end mail system is something like the Citadel groupware platform, where MIME content drives an event handler system? Again, delivery is impacted, but the functionality of the system depends on it.
- What if your org has a global directory and your mail hub is responsible for making complex routing decisions for each message? Again, delivery is impacted; it'll be slower than the mega-fast-box, but mail won't be delivered correctly otherwise!
:) -
For open source groupware, try Citadel.
These articles always seem to leave out credible open source groupware systems such as Citadel. It's a wonderfully complete system that does all of the usual tasks (mail, calendar, contacts, tasks, etc.). It also has a knack for connecting people together in real time, and includes a mini instant messenger and a chat system. One of the nice things about Citadel is that all of the data stores are built-in; you don't have to configure an external IMAP server and an external database server. It's very easy to install.
-
Hula isn't even finished yet.
Why bother with Hula when it isn't even close to being finished yet? If a standalone open source groupware server is what you want, try Citadel, which does today much of what Hula is only promising to do at some arbitrary point in the future.
-
Re:Things are Better Now
Things are definitely getting better as a result of the global communications revolution.
And yet, the folksy local spirit of old-style BBS's doesn't exist in places like Yahoo Groups (or even Slashdot, which although it is basically a BBS, is way too big for that "get to know the regulars" type of community a BBS fosters).
Nope... to revel in the spirit of a BBS environment, you have to log in to a real BBS. There are still plenty of them out there (such as this one), and they're on the Internet now so you don't have to worry about the phone bill anymore. I would encourage everyone to go visit some BBS's on the Internet -- find a few that you like, that fit your personality, and get to know the people there. You'll find it's so much more folksy and social than a big faceless mega-forum-site could ever be. -
AJAX will stop XAML dead in its tracks.
I can't believe nobody has mentioned XAML yet. Doesn't anyone remember hearing Miguel de Icaza ranting and raving about how XAML was going to spell the end of cross-browser, cross-platform web applications as we knew them, because everyone would be writing stuff that requires a browser that has the entire
.NET API embedded inside it?
It's becoming very clear that AJAX is going to stop XAML dead in its tracks. Microsoft was pushing this whole "rich vs. reach" thing, but with AJAX you really can have it all. No need to restrict your user base to Windows XP or Vista in order to get rich controls in your web apps.
I think that's the more interesting story here. The monopolistic Windows desktop isn't going to disappear overnight, but the continued existence, improvement, and increasing pervasiveness of web applications will continue to make the non-Windows desktop more viable and widespread. (Click on the link in the previous paragraph to read a longer piece on why this is the more interesting story.) -
Appropriate by whose standards?
I really don't see an opportunity for objectivity here. Who decides whether a particular open source package is worthy?
For example, I maintain a project that often competes directly with software produced by Carnegie Mellon University. How could it possibly get a good rating?
Ok, ok, RTFA and you'll see that everyone contributes, you say. Yes, but then you have the groupthink effect. Slashdot is the perfect example of this, where the level of groupthink and popularity contests are surpassed only by high schools. How can a high quality but relatively unknown software project possibly survive that kind of intellect-free non-scrutiny? -
A message to our new buddies at Microsoft
Since you folks are our friends now, would you mind documenting and publishing -- unencumbered, of course -- the parts of MAPI that will allow Outlook to connect to third-party groupware servers? The rest of the world is getting a little tired of trying to reverse-engineer it.
Sincerely,
random members of the open source community -
Re:This has huge potential
Now, if someone would slurp up Netscape Calendaring Server and release *that* under the GPL.. If the Netscape SuiteSpot Server suite still existed and was under the GPL, there's your Exchange-killer right there.
Perhaps you might consider combining the now-open Netscape Directory and combining it with something like Citadel which can do mail, calendars, and a bunch of other things, and is designed to plug into an external LDAP directory.
That would give Exchange a run for its money, except for the same problem that plagues all non-Microsoft servers: people still want to use Outlook. Hopefully the next generation of upcoming open source client products will change that, though. -
Re:History and continuing history
It's still fairly extensive, you just have to know where to look.
You could of course start here. -
History and continuing history
I was one of the people interviewed in this documentary. One of the things Jason always found interesting was that I was the one who at every phase of production was constantly reminding him that BBS's are not in any way a thing of the past. Dialup is dead, but BBS's live on. I haven't seen the final product yet, but I hope he's managed to convey this message successfully.
Those of us who still frequent BBS's know that it's still the best way to stay in touch with groups of people. BBS's are still home to some of the best online communities on the Internet, and now the BBS tradition is even providing an unconventional but surprisingly effective solution for groupware applications.
For those of you who aren't currently part of a BBS community, I'd strongly urge you to go out there, find one that you like, and make some friends. Log in every day. Keep the discussions going. The "modern" Internet has been trying (unsuccessfully) to re-create for a decade what the BBS has always provided. It's the people that matter most, and nothing connects people to each other better than a BBS. -
History and continuing history
I was one of the people interviewed in this documentary. One of the things Jason always found interesting was that I was the one who at every phase of production was constantly reminding him that BBS's are not in any way a thing of the past. Dialup is dead, but BBS's live on. I haven't seen the final product yet, but I hope he's managed to convey this message successfully.
Those of us who still frequent BBS's know that it's still the best way to stay in touch with groups of people. BBS's are still home to some of the best online communities on the Internet, and now the BBS tradition is even providing an unconventional but surprisingly effective solution for groupware applications.
For those of you who aren't currently part of a BBS community, I'd strongly urge you to go out there, find one that you like, and make some friends. Log in every day. Keep the discussions going. The "modern" Internet has been trying (unsuccessfully) to re-create for a decade what the BBS has always provided. It's the people that matter most, and nothing connects people to each other better than a BBS. -
History and continuing history
I was one of the people interviewed in this documentary. One of the things Jason always found interesting was that I was the one who at every phase of production was constantly reminding him that BBS's are not in any way a thing of the past. Dialup is dead, but BBS's live on. I haven't seen the final product yet, but I hope he's managed to convey this message successfully.
Those of us who still frequent BBS's know that it's still the best way to stay in touch with groups of people. BBS's are still home to some of the best online communities on the Internet, and now the BBS tradition is even providing an unconventional but surprisingly effective solution for groupware applications.
For those of you who aren't currently part of a BBS community, I'd strongly urge you to go out there, find one that you like, and make some friends. Log in every day. Keep the discussions going. The "modern" Internet has been trying (unsuccessfully) to re-create for a decade what the BBS has always provided. It's the people that matter most, and nothing connects people to each other better than a BBS. -
Re:Lousy Submissions
- If a standard, everyday IT geek can read your submission without clicking on any links and be able to understand what's in store within those links, you've done a good job.
Agreed.
- This particular submission is not an example of this.
Yes it is. For the sake of Captain Crunch, it's a PBX! Go learn something if you consider yourself a geek or hacker!
-
Abandonware. Try Citadel instead.
I'd like to remind everyone that the Citadel project has a complete, robust, flexible open source groupware server that, unlike Hula, is not abandonware. And, it works today, has developers actively working on it, contains a high-performance standalone messaging engine, does IMAP, calendaring (with support for upcoming versions of Kontact and Evolution built-in thanks to GroupDAV), a nice web-based front end, and all the other stuff you expect. Go check it out.
By the way, CalDAV is starting to become widely regarded as too cumbersome to implement properly. GroupDAV is the upcoming standard -- not only is it simpler to implement (resulting in fewer buggy implementations) but it also supports all the usual groupware object types -- not only calendars, but tasks, contacts (using vCard), etc. GroupDAV support is currently in beta for Kontact, Evolution, Citadel, and OpenGroupware.org. Go check that out too. -
Open source groupware standardsThe problem we've been failing to solve for way too long is that there's no standard access protocol for open source groupware clients to talk to open source groupware servers. Fortunately, this is about to change.
GroupDAV is a subset of DAV designed to handle this task. The draft version of the spec is available already, and unlike most new protocols, its primary goal is to be simple enough for widespread implementation. GroupDAV uses the vCalendar/iCalendar and vCard standard data formats, and a simple HTTP-based transport with some DAV-like methods to allow searching and updating.
GroupDAV is being implemented by (at least) the following projects:- Citadel (open source groupware server)
- OpenGroupware (another server)
- Kontact (and KOrganizer, et al) (the KDE groupware client)
- Evolution (client)
- There is a Sunbird implementation rumored to be in its beginning stages as well.
It's probably only a matter of time before some third party ties Outlook into GroupDAV as well.
I've been advocating the idea of open source groupware since 1998. Fortunately, some concensus is finally starting to form about how everything is going to interoperate. Exchange is one of the most heinous Microsoft products out there and it's about time we displaced it. -
Citadel BBS?
Does anyone remember what happened to the outlook killer being written by the guy that wrote the Uncensored BBS?
-
Re:Killing Outlook
What you're describing is Citadel, which can be installed in its entirety with one command. I think it's more complex than that, though. We don't need an Outlook replacement, and we don't need an Exchange replacement. We need an end-to-end, open-source, cross-platform groupware solution. Citadel is the server portion. Let's get Moz Calendar and other clients working with it.
-
Re:Killing Outlook
What you're describing is Citadel, which can be installed in its entirety with one command. I think it's more complex than that, though. We don't need an Outlook replacement, and we don't need an Exchange replacement. We need an end-to-end, open-source, cross-platform groupware solution. Citadel is the server portion. Let's get Moz Calendar and other clients working with it.
-
Re:Calendar server
Are the citadel protocols the same as any other open source groupware servers? And what protocols are you using?
Citadel implements the most open, simple, straightforward calendar store possible: each calendar item is stored in vCalendar format as a MIME-encoded message in the user's calendar folder. Address books work the same way, with each contact being stored as a MIME message containing a vCard. Free/busy is generated automatically from each user's calendar and can be fetched via HTTP (again, in industry-standard vCalendar format). Meeting invitations -- you guessed it, sent and received via ordinary email using vCalendar format.
In my opinion this represents the most simple, optimal standard for open source calendar clients to use, and it should be pursued aggressively by all such projects. There is a pipe-dream IETF protocol called CAP which attempts to do the same thing, but it is so mind-bogglingly complex (XML over BEEP over MIME over more XML with a pseudo-SQL layer for querying) that there are exactly zero implementations of it out there.
Go check out the Citadel system and give it a test run. It's insanely easy to install, doesn't require a bunch of manual integration the way most unix solutions do, and has a complete, integrated web interface as well as support for all of the usual mail protocols. This is the complete solution others have attempted to build, only to end up with half-built rollups. All we need now to achieve an end-to-end open source groupware solution is for the client programs to be integrated with it. -
Calendar server
The sooner the open source community develops a calendar client that is fully integrated with an open source groupware server, the sooner we will be able to mount a credible challenge against Outlook.
Reduce people's dependency on Outlook and it'll become much, much easier to topple Exchange. Topple Exchange and you've got a good chance at completely removing Microsoft from the server room! -
Re:I write OSS for Linux
So, where's my check?
:)You need to go get your product into wide use now. On one project I'm involved with, we're working with a certain
.com on a project I can't say much about yet, but we're going to give a certain Microsoft product a run for their money, using open source software. I don't expect any of us to see money from the project for at least two years, though you can bet you'll see the product -- when it's ready -- on the front page of slashdot. :)In the meantime, keep maintaining your software, and keep getting the word out. If it's good stuff, someone will take notice, and an opportunity to make money off it will come your way.
-
Re:Don't just take this lying down, IMOIndeed, don't take this lying down. Has anyone considered the possibility that the software in question only had 44 security holes to be found between them? (Or, at least, 44 that we could reasonably know about right now.) It would be impossible for anyone to pass this assignment in those circumstances.
It sounds like the assignment was utterly unfair. I don't think I could find 10 security holes in the project I code for at this point; it's been fairly well audited both by us and by others. A few days ago I just patched what I think is the last one; of course, I should know better by now...
-
Re:ReactOS?
if you aren't impressed that it has taken 7 years to get where they are, why don't you help out and do some coding?
Mainly because I'm too busy contributing to other projects and trying to occasionally get out of the house once in a while and chase down that elusive thing I once heard about called women.
Besides, I want Windows to die a horrible death.
-
PIM features?
I think the next important step for Thunderbird would be to allow it to be installed (via extensions and such) as a full PIM suite. Calendar, address book, etc. are features people look for, and if these were available, Thunderbird would start converting Outlook users at the same rate Firefox is converting IE users.
Adding in the existing Calendar extension would be a good start. Adding in connectivity to an standards-based open source groupware server would create the end-to-end solution we've been looking for all these years. -
Re:History is great and all...
BBS's are not dead. Dialup is dead, but the BBS lives on. BBS's have moved to the Internet, where they are still some of the most close-knit online communities you can find. What some people don't seem to realize about online communications is that it's the people that matter. Not files, not banner ads, not warez, not even most of what passes for "content" on most big commercial sites these days.
No other environment is quite as "folksy" as a BBS. Why do people post in the comments section on Slashdot? Because it's people reaching out and connecting with other people. We in the BBS community have never lost sight of that basic tenet, and that's why we log on to our favorite boards, day after day, year after year, decade after decade. To talk to real people. -
We need a standard.
All these different projects trying to come up with an end-to-end solution, and none of them really getting anywhere. We need a standard.
A few months ago, the folks at the Citadel project took notice of the specs for the Kolab project, and began promoting its storage and network formats as a proposed standard for open source groupware. It was a nice, simple, elegant design, using vCard and vCalendar formats. Others shared the same view: for example, the Aethera people joined in, and made their client Kolab-compatible. We at the Citadel project made our server Kolab-compatible. This was shaping up to be something good.
So what did the Kolab people do? They designed "Kolab 2" which uses data formats that are neither forward nor backward compatible with Kolab 1. They completely disregarded not only their installed base, but other projects that were working towards compatibility. The new format is proprietary (documented and unencumbered, but proprietary) and gratuitously abuses XML instead of following the industry-standard vCard and vCalendar formats.
The Aethera and Citadel projects are currently in discussions to work together to create a true. open, standards-compliant, cross-platform, end-to-end groupware solution. We invite others to participate as well -- we won't ignore you the way the Kolab people have.
As for OpenXchange? As others have suggested, this is really just a couple of bells and whistles glued onto someone else's IMAP server. It's not really a true solution. -
We need a standard.
All these different projects trying to come up with an end-to-end solution, and none of them really getting anywhere. We need a standard.
A few months ago, the folks at the Citadel project took notice of the specs for the Kolab project, and began promoting its storage and network formats as a proposed standard for open source groupware. It was a nice, simple, elegant design, using vCard and vCalendar formats. Others shared the same view: for example, the Aethera people joined in, and made their client Kolab-compatible. We at the Citadel project made our server Kolab-compatible. This was shaping up to be something good.
So what did the Kolab people do? They designed "Kolab 2" which uses data formats that are neither forward nor backward compatible with Kolab 1. They completely disregarded not only their installed base, but other projects that were working towards compatibility. The new format is proprietary (documented and unencumbered, but proprietary) and gratuitously abuses XML instead of following the industry-standard vCard and vCalendar formats.
The Aethera and Citadel projects are currently in discussions to work together to create a true. open, standards-compliant, cross-platform, end-to-end groupware solution. We invite others to participate as well -- we won't ignore you the way the Kolab people have.
As for OpenXchange? As others have suggested, this is really just a couple of bells and whistles glued onto someone else's IMAP server. It's not really a true solution. -
Still a rollup
It's still a rollup and/or a partial solution. OGo doesn't even have an email system in it. OpenXchange rolls in a bunch of existing packages and puts a custom Web front end on it, just like Kolab and Bynari do.
Those interested in a true ground-up implementation of an open source groupware server might want to check out the Citadel project. It's got all the usual email stuff (IMAP, POP, ESMTP), a web front-end written specifically for it, shared calendaring/scheduling, instant messaging, and a database-driven message store (which unlike Exchange, can be backed up hot). -
Citadel BBS
Without a doubt, nothing brings people together like a Citadel system. Since it's focused on people and not file leeching, you get a stronger sense of community.
What's more, modern Citadel systems give you telnet and web-based access, so the old-skool BBS'ers can have their 80x24 fun while the newbies can partake of the community from the comfort of their favorite browser. The e-mail system is built-in, sporting SMTP/POP/IMAP, and you get an instant messenger and a chat system completely integrated. It's a totally self-contained package that gives you the community-oriented site you're looking for.
If you want to see one in action, just click on the BBS link in my signature. I've been doing this for 16 years and loving it. BBS's are not dead, by any means. -
Re:Wonderful, wonderful - alll we need is a server
You could write the server-side of the protocol this client expects for instance. That should not be too hard.
Sounds doable. I'm a developer on the Citadel project, which has an open source groupware server. Now that the Connector is open source, we might give some serious consideration towards implementing the required WebDAV API in our web service. -
Re:He's got a point
From what I've seen, most linux users are always comparing linux to windows 95 and 98...most of them having bailed out of using windows around then...and they basically are fighting against the ghost of windows past. Whereas I don't see many of these people ever saying "yes, I use winddows xp / server2003 almost constantly in an attempt to understand what I'm up against here."
I switched to Linux once and for all in 1995, after trying out a beta copy of Windows 95 (on 13 floppy disks!). Since then I've been exposed to Windows NT, Windows 98, Windows 2000, Windows Me, and Windows XP. For the most part the useful changes in Windows are in the user interface. There's less "configuration" of hardware devices with each iteration of Windows, and the interface itself gets "prettier." (Except for XP, which reminds me of Fisher-Price toys.)
Microsoft has incorporated good ideas into Windows, such as autoconfiguring hardware, automatically recognizing file types on removable media and launching the appropriate program, etc. But for someone for whom the computer is a tool to accomplish work, Windows is, at least for me, a royal pain in the ass in other ways: I can't configure it to my personal tastes. I can't customize it to work the way I want to work. This is where Linux is a big win: it lets me work the way I want (or need!) to work.
Case in point: Even when I'm managing files in Nautilus, I frequently find myself sliding the mouse over to a terminal and running a command on the files. It's easier for me. It's very difficult to manage files with CMD.EXE, however, as anyone who's tried can attest.
As a developer, I'm comparing Linux to (now) Windows XP, and yes, it has some shortcomings that will have to be addressed, and in each case I've found a shortcoming, I've also found a project working on addressing it. So I have nothing to do.
:-) (Not exactly true; the project I'm working on aims to replace Exchange and possibly Active Directory.)It still remains, though, that my productivity drops sharply on a Windows platform, simply because the tools available do not lend themselves well to efficiency and productivity. They do, however, look really pretty.
-
Citadels were the best!
I, too, loved Citadels. Something about the no nonesense approach, just text messages will all those lovely, lovely ROOMS to explore. You can, of course, still find them around today. Whether they have the same feel/flavor is an entirely different subject, of course. Check out the Uncensored! BBS at uncensored.citadel.org. It is running Citadel/UX on a Linux system so you can still feel proud to check it out, even if you're too young to have experienced BBSing the first time around.
-
Re:buying e-mail client ???
Yes, there are some OSS solutions out there as well, but they're not up to the same level in functionality as Outlook/Exchange. And that's a pretty sad statement.
True, but we're working on it.
-
Remote calendar support?
Evolution is truly a first class application. Polished, debugged, good-looking, and professional.
That having been said, though, I am still disappointed by the fact that they are not supporting remote calendars out of the box. Sure, you can buy plugins to connect it to Exchange, or Netscape/iPlanet/SunONE/JES calendar server (whatever they're calling it this week), and presumably Groupwise (soon) ... but where's the built-in support for remote calendars using an open protocol? Folks like me who are developing open source groupware servers are anxiously awaiting good clientware to connect to. How about putting WCAP in the standard build? It's well-documented and much simpler than the disgusting mess the IETF is proposing (CAP has the dubious honor of being the one protocol even uglier than IMAP).
So how about it, codemonkeys? The sooner we get some real open source calendaring going, the sooner we can start to make a real challenge to Outlook. Microsoft loves the Outlook/Exchange lock-in. They love it so much that they're trying to do the same thing across their entire product line (Office 2003 has many ties to SharePoint server). The window of opportunity is open, but it won't be forever. -
Re:The one "feature" that holds me back
Mozilla Calendar really needs to be folded directly into the Thunderbird system. People want a calendar in their email client, and that's that. The sooner this is done, the sooner Thunderbird can start kicking Outlook's butt.
The place where Mozilla Calendar is a bit weak right now is its server support. Sure, you can publish and subscribe using WebDAV, but that's not the same thing as having a true server-side calendar. And you still can't send and receive meeting invitations, or check other users' free/busy times.
Fortunately, there is a group at Penn State working on fixing this. They're writing a new calendar API that can be used to hook into arbitrary servers. That means that modules will be able to be written for any back end, such as Citadel, Sun calendar server, Kolab, or whatever else appears out there in the future. -
Re:"My" sensible date format is an ISO standard!Yeah, thanks to Citadel, which used YYmmmDD dates, I've been using year-first for nearly two decades. But when I heard about the actual ISO 8601 standard, instant switch. Yay!
BTW, FWIW, I agree that you got a raw deal on that Flamebait moderation. I'd considered the sun to be non-renewable, but not using that specific term, only that it has a limited (albeit L-O-N-G) lifespan. I can only speculate that the moderator didn't read past your first line and treated the first line as representative... ouch!
-
Not just another rollup
Here's a project worth checking out: Citadel/UX. Admittedly it's only about 80 percent of the way there, but the thing that makes Citadel stand out from its open source brethren is that it's not just another Cyrus/Postfix/OpenLDAP/etc. rollup with some loose stiches put in to make them act like a single system.
We're actually taking the time to build something good from scratch. We've got a true journalling database oriented message store (thanks to Berkeley DB) including single-instance store (a message sent to 100 users doesn't get saved 100 times). Built-in IMAP, POP, SMTP protocols. A nice calendar service, and a Web interface. It's even got its own instant messenger.
The thing that's important, though, is that it's designed to be easy to install. One of the very few things that Exchange 5.5 had going in its favor was that it was relatively easy to install. Citadel aims for that as well -- plug in the RPM's or tarball, run the setup program, and you've got a basic server up and running. Inexperienced admins might be scared by editing /etc/mail/complicated.cf and /etc/init.d/S90scary.sh, but they don't mind running a "setup" program and then customizing with a web browser.
Where we really need the extra development work right now is to start writing some connectors for popular client software. Currently we are aiming for 100 percent compatibility with the Kroupware project (so you can use the Kontact client without having to install the clunky Kolab server) and eventually Evolution (which has a 'connector' architecture). Eventually we'd prefer to do everything in Mozilla (using Mozilla Mail and Mozilla Calendar), since it's cross-platform.
Again, it's not a drop-in Exchange replacement today, but it's a project worth watching, or better yet, helping out on. -
Re:no.Citadel solves this problem by requiring that all users log in to the SMTP server, and secondly by rewriting the From: address to the user's actual address. This violates the RFC, but it makes spoofing the From address impossible, and the responsible user very easy (for the Citadel sysadmin) to find.
(And yes, you can turn this off if you really want to.) -
BBSing never came to an end.
Once again, the editors of Slashdot want you to think that the BBS is a product of days gone by. I'm here to remind everyone that those days never ended.
I've been running UNCENSORED! BBS since 1988 and it's still a hip, hot, totally-whats-happening hobby. The community is still there. The fun is still there. The comraderie is still there.
The only thing that isn't still there is the modem.
Slashdot likes to position itself as "what came after the BBS" but with the amount of volume a zillion users generate, you just can't replace the "folksy" feel of your favorite BBS. Get out there and BBS, folks!