This is an attempt to give you an idea where Citadel came from, where it is today, and where it's going tomorrow. This is a project with a long history, and most likely a long future.
Back in October of 1987, the chance score of an Altos model 586 multiuser computer provided me with the opportunity to set up the BBS I'd long since wanted to operate. Having spent the last few years becoming a die-hard Citadel fan, I started out with the intention of porting the Citadel BBS code to Unix. Unfortunately, the compact, efficient design that allowed Jeff Prothero (aka Cynbe ru Taren) to fit his Citadel BBS into a 64k CP/M system, was compact and efficient that the effort required to make it run in a multiuser environment would have been greater than the effort required for a rewrite.
Version 1, which actually wasn't called Citadel – the system was initially dubbed 'UNIXrooms' – was implemented as a set of extensions to the Unix environment to add a Citadel-like messaging engine. The original plans were to never re-implement any services that were already provided by the underlying operating system. For example, new users at that time were actually added to the Unix password file, and the Citadel user database only served as supplementary data for new message pointers, etc.
Version 1 ended up serving more as a proof-of-concept implementation than as an actual working BBS. This was mainly because it took the phone company a whole six months to install a phone line, so there was plenty of time to evolve the software a bit.
Around the same time UNCENSORED! BBS went online – March 1988 – version 2 of Citadel came into existence. At this time, it had enough functionality to be truly called a Citadel, and so it was renamed to Citadel/UX (a suggestion from one of our users). We now had a user database independent of the Unix password file, several types of private rooms (and public rooms too, of course), a working e-mail system, somewhat stable multiuser access, and a bunch of other features that everyone expected in a BBS at the time.
Lots of formative things happened during the life of Version 2. Other sites began to run the code, and there were numerous success reports from people running it in many different environments, including sites that had multiple lines – one site had six phone lines, in fact. It was around this time that inter-node networking was implemented as well. Thanks to the disk-based nature of the databases and message base, this was written as a standalone program, and only very minimal changes were needed in the main Citadel program (displaying node names and the like).
The introduction of Citadel to large Internet BBS's provided the opportunity to test and tune the software to run reliably under heavy multiuser loads. Some of the forks of Citadel v3 are still in use today, such as DaveCode (which runs Quartz, the first site to make itself available via the Internet) and DOC (which runs ISCA, a site that is in somewhat of a decline today, but in its heyday was a simply massive Citadel installation). These systems successfully operated under extremely heavy loads – this was the time of the Internet just before the Web craze hit, and there were scads of people signing on to text-based services.
A little less than a year before UNCENSORED! BBS finally became reachable via the Internet, the Citadel software began to undergo an overhaul, becoming a fully distributed client/server application. Initially there was some interest in implementing something compatible with the DOC client protocol, but that turned out to be simply a modified version of telnet with a few bells and whistles thrown in. The primary design goal of the Citadel client protocol was to completely divorce the user interface from the server's back-end execution logic. It took months to separate the existing code into user interface and execution logic modules, but when it was done, we had a system that looked exactly like its predecessor… but was much more powerful and flexible under the covers.
It wasn't long before users who either had Linux systems at home, or access to a Unix shell on their ISP accounts, started downloading the client code and running it locally instead of telnetting to the host's copy. It was an immediate success. Users liked the performance improvement – no more character-by-character netlag while entering messages. They liked being able to choose their own local text editor, and they liked being able to print messages locally.
It was also now possible to implement user interfaces completely different from traditional Citadel, without interfering with the look and feel of the 'classic' client. And so it began. An early experiment with alternative clients was WinCit, a point-and-click frond end for the MS Windows 3.1 systems in use at the time. This project had a short life, but it was an excellent proof of concept.
One of the reasons WinCit died was because everyone was asking for something completely different: they wanted to access Citadel using a web browser. This gave rise to the WebCit project, a clever 'middleware' program that acts as a webserver (originally it required tying it into an existing webserver such as Apache, but now it contains its own standalone HTTP engine), and allows users to access a Citadel system from any web browser. Lots of people are using WebCit as their exclusive method of accessing Citadel systems now. The client/server architecture of the Citadel system makes this possible, and what makes this far more special than other web-based BBS's is that web-based users and text-based users can coexist on the same site without interfering with each other.
Extremely high performance and lots of other benefits were realized with the v5 server, because it was rewritten as a single, multithreaded server program. The v4 server was inetd-based - each session was run as a separate server process. In v5 we've utilized the POSIX Threads API to get everything running in a single server program. The core server program is really nice - all of the temporary files and pipes that we had to put on disk for things like instant messages and multiuser chat have been eliminated thanks to the new architecture. There were some initial problems getting things to work correctly, and the user community present at the time deserves a great deal of thanks for tolerating the occasional crash while the bugs were worked out.
And this time around, the installation and maintenance are much easier. Wherever possible, the editing of text files to make configuration changes was eliminated. For example, the configuration files to set up networking were replaced by command-line utilities in v5 (later to be replaced by built-in server modules in v6). Intuitive configuration screens replaced the need to use a text editor.
Version 5.50 brought with it a number of important changes. The most significant change wasn't technological at all: it was the addition of more developers to the project. This was a big boost, as it allowed the Citadel system to go in new directions thanks to the addition of new talent. The other big change was a total rearchitecture of the back-end data store. We finally abandoned the circular-file architecture originally created for the CP/M platform and floppy disks 17 years earlier, and moved to using the GDBM record manager for everything. It's far more flexible, and it allowed us to obliterate all of the system's arbitrary limits (messages per room, rooms per system, etc.) And it paved the way for some of the nifty groupware stuff you'll be reading about a bit later in this page…
Citadel v6 began our vision of the project as a universal messaging and groupware toolkit. We were not yet on par with some of the commercial products out there, but v6 was an impressive platform. We improved the database back end, by switching from GDBM to Berkeley DB. The latter is quite robust, supporting transactions and journalling, and is much more reliable. It's also very scalable.
The v6 development track was where built-in support was added for the three major Internet mail protocols: ESMTP, POP3, and IMAP4. Citadel clients and WebCit are still supported (and always improving), of course. The list of changes is too voluminous to reproduce here, but here are some of the highlights: full-screen mode in the text client, SSL support for all client protocols, improvements to the build system to make it more portable, and the open source community's first single-instance message store (deliver a message to 100 users and only one copy gets stored on the disk).
With this version, our vision of a messaging platform with all of the most commonly desired groupware functions (calendaring, group scheduling, task lists, address books, etc.) became feature-complete. With the solid platform we built, we were finally in a position to do this. At the same time, we've still moved forward in our primary goal of becoming the best and most powerful software package for running online communities.
We've also participated in the trend of making web apps richer and more responsive, by adding AJAX technology to WebCit wherever it makes sense.
As of this writing (early 2008) it is clear that the v7 system delivered on our groupware vision, because 2007 was a banner year for Citadel – we had a large amount of takeup and Citadel became quite popular. It was even written up in feature articles in at least three different magazines which cover open source software.
If you're a developer, or a Citadel site operator of any type, get involved in the Citadel project! There's plenty of room for lots of people to be working on lots of different things. Visit the home of Citadel, UNCENSORED! BBS, at http://uncensored.citadel.org (you can telnet there too, or point your favorite Citadel client at it, of course). We'd love to have you aboard. Let's introduce a whole new generation of online enthusiasts to the tradition of Citadel.