alt.bbs.elebbs

Long-form reference · 8,465 words · about a 37-minute read

The paperwork: created and un-created inside the hour

A Big-8 newsgroup arrives with a dossier. There is a Request for Discussion, a Call for Votes, a published tally with the voters' names in it, a result, a waiting period, and only then a control message. For a group in soc.* or comp.* that paperwork is usually complete enough to reconstruct the argument years afterwards. The alt.* hierarchy keeps nothing of the kind. There is no ballot, no votetaker, no quorum and no result to archive; the customary airing in alt.config is advisory and binds no one; and the only durable record a given alt.* group leaves behind is the file of control messages that passed across the network in its name, which the Internet Systems Consortium mirrors group by group. The origins of that arrangement belong to the alt.* hierarchy page and are not retold here.

For alt.bbs.elebbs the ISC control archive holds exactly two messages, and they are dated the same afternoon. The first is a newgroup control message timestamped 28 March 1999 at 21:12:55 GMT, cross-posted to control.newgroup and to the new group itself, and issued by Sean Rima. It carries the three things an alt.* creation notice conventionally carries: the line to paste into a news server's newsgroups file, a charter, and a justification.

alt.bbs.elebbs Newsgroup for the BBS package EleBBS by Maarten Bekers

The charter beneath it ran to a single sentence, and it is the whole of the group's constitution:

Charter: for discussion (unmoderated) about EleBBS BBS Package and any third party utilities

The description line is worth one remark, because it is unusual. Newsgroup descriptions name subjects. They say what the group is about — Computer BBS systems & software, RemoteAccess discussion, Bulletin board system add-on executables, or "doors" — and they very rarely name a living human being. This one names its author in nine words. The scarcity is measurable rather than impressionistic: of the roughly 45,000 lines in ISC's current newsgroups file, fewer than forty descriptions contain the word by followed by a personal name, and almost all of those belong to groups about a novelist, a photographer or a teacher, where naming the person is the entire point of the group. Among groups devoted to a piece of software, alt.bbs.elebbs stands very nearly alone in naming the programmer. The line has never been revised: the same string sits in that file today, twenty-seven years after it was written.

The justification is the more revealing document, because it is an argument about market position dressed as an argument about namespace. Its author held that alt.bbs was too general to serve, being about all BBS software rather than this one; that discussion of EleBBS in alt.bbs.ra was "frowned upon" because that group belonged to a different program by a different author; that EleBBS was "a RemoteAccess clone" which nonetheless "has far more to offer than RA"; and that a power search of Deja News for the string elebbs between 1 October 1998 and 22 March 1999 had returned 351 messages. It named the competitors that already had groups of their own — RemoteAccess, ProBoard, MajorBBS, PCBoard and Telegard, the last of them misspelled in the original — and ended on the flat assertion that EleBBS would be discussed more if there were a proper newsgroup for it.

That last claim, at least, checks out and still does. ISC's newsgroups file continues to carry alt.bbs.ra, alt.bbs.proboard, alt.bbs.majorbbs, alt.bbs.pcboard, alt.bbs.wildcat, alt.bbs.renegade, alt.bbs.wwiv, alt.bbs.telegard.moderated and a dozen more package-specific groups, alongside alt.bbs.doors for the add-on programs and alt.bbs.doors.lord for a single door game. The bulletin-board corner of alt.* was organised the way a software catalogue is organised: one group per product.

The second message in the archive is an rmgroup for the same name, timestamped 21:59:43 GMT the same evening — forty-six minutes after the first — issued by Jay Denebeim and cross-posted to alt.config. It quotes the entire proposal back, line by prefixed line, and appends a short objection.

This group *was* discussed in alt.config. The proponant was specifically told by several people that there was insufficient quantities of traffic for the group. Note that he can't even document 2 messages per day on the topic.

The arithmetic is closer than the objection allows. Three hundred and fifty-one messages spread across the 173 days from 1 October 1998 to 22 March 1999 is a shade over two a day rather than under it. The stronger objection is the one not made: the figure came from searching for the string elebbs anywhere on Usenet, not from measuring traffic in any group, so it was never evidence about how busy a dedicated group would be. Procedurally none of it made the slightest difference, and that is the part of the story which explains why a page about this group can be written at all. The reference control.ctl distributed with news server software — the same file ISC mirrors — sets the conventional alt.* policy as accept every newgroup and drop every rmgroup, in two lines that read newgroup:*:alt.*:doit and rmgroup:*:alt.*:drop. A removal request for an alt.* group is, on a default configuration, discarded unread by the software. The same file is disarmingly candid about the standing of its own advice, observing that there is no official, generally accepted alt.* policy and that all available information about alt.* groups is essentially someone's opinion, including those comments.

So the group was created by one man's control message, disowned by another's forty-six minutes later, and carried by the network regardless. It is carried still: the current ISC newsgroups file lists it with its original description, and the current active file lists it as unmoderated and open for posting. There is even a second entry in the namespace — free.elebbs, described as Discussion of EleBBS, in the free.* hierarchy — which means the Usenet name space contains two standing rooms for a bulletin-board program that one person wrote in his spare time.

What a bulletin board actually was

Anyone arriving at this page from a search engine may need the shape of the thing established before the software makes sense, because a bulletin board system has almost no structural resemblance to a website. A BBS was one computer. It usually sat in the operator's house — on a desk, in a spare room, in a cupboard with a fan pointed at it — and it had a modem attached to a telephone line. To use it you told your own modem to dial that telephone number. If someone else was already connected, you got a busy signal and tried again in ten minutes. That was the whole architecture: a single machine, reachable by one caller per line, over the public switched telephone network.

Boards with more than one line existed, and they were the ambitious ones. A second caller required a second modem, a second telephone line with a second monthly bill, and some way of running two copies of the board software at once — a DOS multitasker such as DESQview, later OS/2 or Windows, or in larger installations several computers on a local network each answering its own line. Every one of those things cost money that came out of the operator's pocket. The system operator, universally the sysop, bought the machine, bought the disks, paid the line rental, wrote the welcome screen, validated new users, arbitrated arguments and read the mail. Boards were not businesses. A minority charged subscriptions, mostly the large file-download systems; the overwhelming majority were hobbies that a household subsidised.

What callers found once connected was a text interface, navigated by single keystrokes, offering four things in varying proportions. There were message bases: topic areas in which you read what other callers had written and wrote a reply, all of it stored on that one machine's hard disk. There were file areas: directories of programs and documents to download, with descriptions, upload-to-download ratios to discourage pure consumption, and a convention by which an archive carried its own description inside it, in a small text file named FILE_ID.DIZ, so that a board could catalogue an upload without the uploader typing anything. There were doors: external programs the board would hand your connection to and then take back afterwards, of which more below. And there were the incidentals — bulletins, questionnaires, a page-the-sysop key that rang a bell next to the operator's desk, and on multi-line boards a chat facility for the rare luxury of two callers at once.

Almost all of it was rendered in ANSI: the IBM extended character set's block graphics combined with the escape sequences that let a remote program set colours and move the cursor. Elaborate ANSI welcome screens became a competitive sport and eventually a subculture of their own, so that a well-dressed board opened on a full-screen colour illustration drawn one character cell at a time by somebody who signed it.

One distinction deserves stating plainly, because the two things are constantly conflated and this directory documents the other one. A BBS was a destination: you called a specific machine and read what was on it. Usenet was a distributed system: articles propagated between thousands of servers so that the same discussion appeared everywhere at once, and no one machine held it. The two worlds overlapped heavily in personnel and hardly at all in architecture; the explanation of what Usenet was belongs on its own page.

The scale, before the collapse, was substantial. The first public dial-up board, CBBS, went online in Chicago on 16 February 1978, built by Ward Christensen and Randy Suess after a blizzard gave them the time. Sixteen years later InfoWorld estimated 60,000 boards serving 17 million users in the United States alone — collectively a far larger market than CompuServe. A trade press grew up around it, and early-1990s issues of Boardwatch were thick with advertisements for single-click packages aimed at people setting up as sysops for the first time. Then, between late 1994 and early 1995, inexpensive dial-up internet accounts and a graphical web browser arrived together and the market crashed: a single call to an internet service provider reached every service in the world, where a call to a board reached exactly one board. Over the following year the leading BBS software providers went bankrupt and tens of thousands of systems disappeared. The technical superiority was not close, and nobody in the surviving scene pretends otherwise.

EleBBS, the subject of this newsgroup, was begun in September 1996 — that is, some eighteen months after the crash.

Store and forward: how boards were joined together

Isolated boards would have been a much smaller phenomenon. What connected them was FidoNet, begun in 1984 by Tom Jennings, and the trick that made it affordable was store and forward. A board's ordinary business ran during the day; at a fixed hour of the night the BBS software shut itself down and handed the modem to a separate program, a mailer, which called the other systems it had mail for, exchanged compressed bundles of messages, and handed the modem back. The exchange window was set for the small hours, normally around four in the morning, precisely because long-distance telephone charges were lowest then. It was first called national mail hour and later Zone Mail Hour, and it is the single fact that best conveys what these networks were made of: the constraint that shaped the design was the telephone bill.

Every participating system kept a nodelist: a text file, updated weekly, listing every other member system with the name of the board, the name of its operator, its geographic location, its telephone number and its software capabilities. When the flat list of node numbers hit its ceiling of 250 in the spring of 1985 the network gained network numbers, patterned on the idea of area codes; in October 1986 it gained zones, corresponding roughly to continents, and points, for individuals who wanted mail delivered to a personal machine that was not itself a public board. The resulting address form was zone:net/node.point. Zone 1 was the United States and Canada, zone 2 Europe and the former Soviet Union, zone 3 Australasia, zone 4 Latin America, zone 5 Africa and zone 6 Asia; zone 6 was removed in July 2007 and its remaining nodes moved to zone 3. Zone numbers from 7 to 4095 were left free for othernets: independent networks running the same software and conventions without answering to FidoNet's coordinators.

Private mail between systems was netmail. The thing that mattered was echomail, which grew out of a program introduced in February 1986 by Jeff Rush and let a message posted in a public area on one board propagate to the same area on every other board carrying that conference. A scanner collected new public messages, compressed them, and attached the archive to a netmail message; a tosser on the far side unpacked it and filed the contents. Each system the message passed through added itself to a growing path header, and a seen-by header prevented it from looping around the network when routing was misconfigured. It was, functionally, a poor man's Usenet running over dial-up telephone calls between hobbyist machines, and it grew far larger than the private netmail it was built on top of. For a great many users echomail simply was FidoNet; person-to-person netmail was comparatively rare.

The numbers followed the same curve as the boards themselves. FidoNet listed a hundred nodes at the end of 1984 and over 20,000 by April 1993, at which point each node was reckoned to average about 200 active users — four million people in total, of whom around two million read echomail and around two hundred thousand used the private netmail system. At its peak the nodelist ran to approximately 39,000 systems. It then shrank steadily wherever internet access became easy, and levelled out at an estimated 2,500 or so nodes, which is approximately where it remains. It never stopped entirely.

All of this is background to the software, but it is load-bearing background. A DOS bulletin-board package in the 1990s was not a self-contained product. It was one component in an assembly that also included a mailer, a tosser, a nodelist compiler, a message-base format shared with other tools, and a shelf of utilities — and a new package that could not slot into an existing assembly had nothing to offer the people who already owned one.

Doors, drop files and the FOSSIL layer

A door is the interface between the board software and an external program, and by extension the external program itself. When a caller chose a door from a menu, the BBS wrote a small file into a known location containing everything the external program needed to know — who was connected, at what security level, with how much time left, on which serial port and at what speed — then launched the program and got out of the way. These drop files came in several incompatible flavours, which is why door authors shipped support for a handful of them and sysops learned which one their package produced. When the door exited, the board resumed.

Until the arrangement was standardised, the door had to drive the serial hardware itself, which meant every door needed to know about every serial card. The fix was the FOSSIL layer — the acronym expands to Fido Opus SEAdog Standard Interface Layer, after the FidoNet software, the Opus-CBCS board package and the SEAdog mailer — a resident driver whose specification dates from 1986 and whose standards document is maintained by the FidoNet Technical Standards Committee. With a FOSSIL driver loaded, board and door alike talked to the same set of interrupt calls and neither had to care what hardware was underneath. X00, written by Raymond L. Gwinn between 1989 and 1993 and ending at release version 1.50, and BNU were the common DOS drivers; SIO served OS/2, and NetFoss later served Windows. The layer turned out to have a long afterlife, because a driver whose whole job is to make something else look like a modem can equally well make a Telnet connection look like one.

The doors themselves were mostly games, and they were the reason a great many people called a board at all. Legend of the Red Dragon, written in Pascal by Seth Robinson of Robinson Technologies and released in 1989, is the best known: a text role-playing game whose author deliberately restricted the number of turns a player got each day, so that the way to advance was to call back tomorrow, which is exactly what a sysop wanted. TradeWars 2002, Barren Realms Elite, Solar Realms Elite, Usurper and Operation: Overkill occupied the same shelf. Boards published high scores to stoke rivalries; inter-BBS leagues let players on different systems compete through the mail networks; third parties wrote in-game modules that bolted new content onto games they had not written, and enough of these circulated that the best-known game acquired a small secondary economy of them. Not every door was a game — time banks let callers hoard their rationed minutes, and offline mail doors packaged a board's new messages into an archive to be read at leisure and answered in a single later call.

The commercial consequence is the one that matters for this article. What a sysop bought into when choosing a package was not the package. It was the doors, the utilities, the message-base tools and the accumulated configuration, and every one of those attachments was written against a particular board program's conventions. Changing packages meant rebuilding the whole assembly. That is the fact EleBBS was designed around.

RemoteAccess, and why compatibility was the product

RemoteAccess — RA to everyone who used it — was written by Andrew Milner and published by his company Wantree Development in Australia. It began in 1989 as a clone of QuickBBS, which Adam Hudson had introduced for MS-DOS in 1986, and it was released as shareware in 1990. It was written in Turbo Pascal with some assembly-language routines, and its early advantage over its parent was that it would run several nodes at once under Windows, DESQview or OS/2, or across a network, or a combination of the two.

RA then out-grew QuickBBS comprehensively. It was the first BBS package to support the JAM message base format, which Milner had a hand in conceiving — JAM stands for Joaquim-Andrew-Mats after Joaquim Homrighausen of FrontDoor, Milner himself, and Mats Birch and Mats Wallin, and the format was first released in 1993. It was the first shareware board package to keep its file catalogue in a database rather than in the files.bbs text files scattered through the download directories. It interfaced with the FidoNet world through third-party mailers and tossers — FrontDoor, MainDoor, FastEcho — whose authors mostly ended up on its beta team. And it accumulated, on the standard count, more than 1,500 third-party utilities, more than were written for any other shareware BBS package.

Then it stopped. Milner released version 2.50 in May 1996 and ceased development; like a great many sysops of that moment, he had moved on to running an internet service provider instead. In April 1997 he put the rights and the source code up for sale to the highest bidder, and in December 1997 they were bought by Bruce Morse in the United States. Morse issued minor updates including a Year 2000 fix but added no new features; his final version, 2.62, appeared in August 2000, with a 2.62.2 build recorded in October of that year. Two facts about that ending shaped everything that follows. First, an installed base of boards, configurations and utilities was left with an upstream that had changed hands and stopped innovating. Second, RemoteAccess was never ported to 32 bits. It remained a 16-bit DOS program to the end, at a moment when its own users were migrating to OS/2, Windows 95 and Linux.

That gap is the entire commercial logic of a compatible clone. A package that could read an existing RA configuration, an existing RA user base and an existing RA message base, and run the same doors and the same utilities, offered a sysop a 32-bit future at the price of unpacking an archive rather than the price of rebuilding a board from scratch. Two projects took the opportunity, and the standard reference account of RemoteAccess names both: EleBBS in the late 1990s, with DOS, Windows, OS/2 and Linux builds, and MBSE a few years later, aimed chiefly at Linux.

EleBBS: the package itself

By the author's own later account, EleBBS was started in September 1996 as a spare-time project, and it was and remained the largest programming project he ever worked on. The site as it stood in 2000 credited the work to "The Elevator Software Productions" and described the product in one sentence as a RemoteAccess v2.5x compatible BBS program available for DOS, OS/2, Linux and Windows 9x/NT/2000, adding, with a directness the modern web has lost, that if you did not already know what a BBS was, the site was probably of no interest to you.

The first public release was announced for Friday 17 July 1998. The announcement is precise about what compatibility meant: EleBBS was "a completely independent BBS system fully compatible with an existing RA v2.50 configuration", this first gamma would ship platform-native versions for DOS, OS/2 and Windows NT/95/98, and — a detail that mattered to anyone who had been running a keyed beta — the released builds were fully functional and required no key file. The release contained native versions of the programs EleBBS, EleFILE, EleNODE and EleUSER, with the configuration program ElConfig included in the DOS and OS/2 packages.

On the question every clone gets asked, the project's FAQ was unambiguous. Asked whether EleBBS was based on someone else's code, the answer given in 2000 was that it had been written from scratch by its author about three or four years earlier and contained absolutely no code from other BBS packages — a claim about provenance, not about behaviour, since behaving exactly like RemoteAccess was the point. The same answer, restated two years later, put the interval at four or five years, which is the ordinary drift of a FAQ entry that nobody re-dates.

The language was Pascal, in the specific and slightly baroque sense that the DOS-to-32-bit transition demanded of Pascal programmers. The published source tree runs to some three hundred and fifty Pascal units. Its build instructions tell the builder to install Free Pascal and compile with the ppc386 compiler, note that the AsyncPro communications library for DOS is required to build the whole tree, and give the unit and include search paths as literal command-line files. The shared compiler include file branches on Free Pascal, on Delphi, and on Virtual Pascal — the last being the freeware Turbo-Pascal-compatible 32-bit compiler for OS/2 and Windows, begun in 1995 by Vitaly Miryanov and later maintained by Allan Mertner, which was the standard route by which a 16-bit Turbo Pascal codebase acquired 32-bit lives. The separately published communications library, EleCOM, was offered as the complete Object Pascal source of an object-oriented serial I/O unit for DOS, OS/2 and Win32, and its author noted that this was exactly how it was used inside EleBBS.

Multi-platform, in this project, was not a marketing adjective. On 5 March 2000 the download page offered five separate builds of version 0.07.g1, all dated that day: a DOS version of 770,119 bytes, a 32-bit DOS version of 1,193,480 bytes, an OS/2 version of 1,479,668 bytes, a 32-bit Windows GUI version of 2,016,084 bytes and a 32-bit Windows text-mode version of 1,676,421 bytes, offered from the Netherlands and mirrored in the United Kingdom, the United States and Germany by named members of the beta team. Linux took longer. A first Linux beta was released on 27 June 1999; the author had earlier written frankly that porting to Linux was proving harder than porting to Windows NT or OS/2, because of the case-sensitive filesystem, the directory separator and his own lack of experience with the system, and had recruited a separate alpha team for it. Linux was folded into the main release line at version 0.09.g1 after, as the release notes put it, more than two years of development — and even then without the TCP/IP features the Windows and OS/2 builds already had. A native FreeBSD version arrived in 0.10.

The feature list, as the package's own documentation gave it in 2000, is a fair portrait of what a late bulletin-board program was expected to do: up to 65,000 separate message areas, file areas, file groups and message groups; up to 65,000 security levels, each with its own online and download limits and its own access to menus and to file and message areas; up to 250 language modules; up to 250 lines; internal Zmodem, Ymodem and Xmodem transfers; ANSI and AVATAR supported locally as well as displayed to the caller, with RIP graphics supported remotely; internal archive viewers for ZIP, ARJ and RAR; a scripting language for writing door-like utilities such as a split-screen chat; lightbar menus driven with the cursor keys; and — marked in that listing as available on the Windows and OS/2 builds only — an IRC client that connected the board's users to any standard server on the internet, a facility for reading and posting to newsgroups from inside the board, and a built-in Telnet server. The source tree carries message-base drivers for the Hudson format inherited from the QuickBBS and RemoteAccess lineage and for JAM; Squish support was added in 0.10, with JAM still the recommended format.

That last cluster is the part worth pausing on. A DOS-lineage bulletin-board package released in 2000 shipped with a Telnet server, a newsgroup client and an IRC client built in. The software was not resisting the internet. It was annexing it.

The release chronology

The project's news page, preserved in web archives, gives a dated release history of a kind that is rare for hobby software of this period, and it is the densest checkable material this page has. The pattern it records is regular gamma releases roughly every four to six months from 1998 to 2001, followed by a stall.

• 17 July 1998 — first public gamma release, announced for that Friday, with native DOS, OS/2 and Windows NT/95/98 versions.
• 8 September 1998 — v0.02.g1, adding internal lightbar support for menus and an extended questionnaire scripting language.
• 25 October 1998 — v0.03.g1, adding the EleMGR user and file database manager, an installation batch file promised to produce a running configuration within ten minutes of unpacking, and a waiting-for-caller screen for the Windows GUI build.
• 28 February 1999 — v0.04.g1, the date set in the announcement of 17 February, which also trailed the built-in Telnet server and a newsgroup importer and exporter.
• 27 June 1999 — v0.05.g1; the same day saw the first beta of the Linux port. This is the release the FAQ identified as the first fully Year-2000-ready one.
• 28 November 1999 — v0.06.g1.
• 5 March 2000 — v0.07.g1, in five platform builds.
• 29 October 2000 — v0.08.g1, after a gap the announcement described as more than six months and the longest since v0.01.g1.
• 30 September 2001 — v0.09.g1, introducing the EleXer scripting language and folding in the Linux port.
• 18 May 2002 — release notes posted for v0.10.g1, which added Squish message bases, a native FreeBSD build, logging of the originating IP address of Telnet callers, and EleServ, a single server program replacing the separate Telnet, news and ident servers.
• 9 June 2002 — v0.10.RC1, a public release candidate.
• 6 April 2003 — the source released under an open-source licence; nightly snapshot builds followed from 11 April.

Two things stand out. The first is how much of the work between 1999 and 2002 was internet plumbing rather than bulletin-board features: a Telnet server, then IP logging for Telnet callers, then a consolidated server process, then TCP/IP socket routines added to the scripting language. The second is the shape of the ending. When the author wrote his open-source announcement in April 2003 he stated the position himself: there had not been a full release since September 2001, that was almost a year and a half, and in that time not much had changed in the codebase.

The satellites: EleCOM, EleXer, EleWEB and a FOSSIL

Around the board program the same author accumulated a small constellation of related products, and the newsgroup's charter — "about EleBBS BBS Package and any third party utilities" — explicitly covered them.

EleCOM was the serial communications unit factored out of EleBBS and published as Object Pascal source, providing serial I/O for DOS, OS/2 and Win32 from one body of code. Version 1.1 was released on 25 November 1999, 1.2 on 13 August 2000 and 1.3 on 9 March 2003. Its release was directly motivated by the door problem: on 20 March 1999 the project announced that because there were major problems supporting doors in the Windows and GUI builds, and because there were no Telnet-specific doors to be had, it would publish the communications library it used, compilable under Turbo Pascal, Virtual Pascal 2.0, Delphi 2.0 and Free Pascal, with full source. The announcement added that the author of Mystic BBS had agreed to join the effort, so that instead of a bare communications library the two projects would produce a single door library with the most-used routines built in — a small but real instance of two competing BBS packages cooperating on infrastructure while the market underneath them was disappearing.

The related standard, DOOR32, was announced on the site on 29 July 2000 as a standard for creating 32-bit cross-platform BBS door games that would also work over both dial-up and Telnet connections. It outlived EleBBS: Mystic BBS still lists DOOR32 support among its features, alongside the older DOS door formats.

EleXer was the scripting language, first shipped in EleBBS 0.09.g1 and described in that release's notes as a subset of standard Pascal with a large library of EleBBS-specific functions and procedures added — enough to write door-like programs that ran inside the board rather than beside it. It later acquired TCP/IP socket routines and, by way of EleWEB, access to MySQL; by April 2003 the project's own website was being generated by EleXer and MySQL rather than served as static files.

EleWEB was the web interface: not a web server but a collection of CGI programs, driven by EleXer scripts and HTML templates, which read the same configuration, user base and message base as the board itself, so that a board could be reached either by dialling it or by browsing it. Development was announced on 14 October 1999, beta testing began in May 2000, and version 0.10.g1 was released on 20 May 2002, followed by 0.10.g2 on 15 September 2002 — which added a front page and, in the phrase used at the time, internet-style forums "which should feel familiar to most people" — and 0.10.g3 on 9 March 2003. It is a revealing artefact: a bulletin board growing a web forum out of its own message base rather than being replaced by one.

SyncFossil, released in versions 1.00 on 28 October 2001, 2.00 on 31 December 2001 and 2.02 on 18 May 2002, let the Windows build run DOS doors without a separate virtual-modem product, using FOSSIL driver code taken from Synchronet, which is where the name came from. By 2003 the product page had stopped recommending it, on the ground that NetFoss was a much better alternative — an unusually blunt thing for a vendor to print about its own software. eleIRCDOOR 0.01, of 10 November 2001, was the package's IRC client repackaged as a standalone door for any DOOR32-capable board, and its announcement told EleBBS sysops not to use it, since they already had the client inside the program. The board itself was by then only part of what the group's charter covered.

Licensing: undecided, then the Q Public License

For its first years EleBBS had no settled commercial model at all. Asked in the FAQ whether it was freeware, and how much it would cost, the project's answer was that whether EleBBS would be freeware or shareware had not yet been determined, and that therefore no pricing had been determined either. Full gamma releases meanwhile shipped without key files and worked completely. In a market where RemoteAccess was shareware with a paid professional edition, and where the eventual successor packages settled variously on proprietary freeware and open source, that indecision was not unusual; it was the ordinary condition of hobby software whose author had not decided whether he was running a project or a business.

It was resolved on 6 April 2003, in a message sent to the beta testers earlier that day and posted on the site. The statement is unusually plain about its own motives, and since the group existed to discuss this software it is worth quoting at the length the author used.

However, as many of you have noticed the true dedication to EleBBS has been gone. Where there were almost releases each 4 months in the past, there hasn't been a full release since September 2001. That's almost 1,5 years without a full release, and in those 1,5 years not much has changed to the codebase.

The reason given in the next paragraph was the least dramatic one available: his programming time had been "severely reduced due to a number of different reasons - having a fulltime job being the most important one", and managing three large projects at once had turned out to be impossible, with his main interest having shifted to the scripting language and the web interface.

The remedy announced was a CVS repository on the project's own newly dedicated server, into which the EleBBS, EleXer and EleWEB code would be placed, released under the Q Public License. The announcement was careful on two points: the author would keep full control of the projects and would keep developing them, and opening the code did not mean abandoning them. Nightly snapshot builds — binaries compiled automatically from the latest source, and explicitly not release builds — began five days later.

The licence choice is itself a period detail. The Q Public License was written in 1999 by Trolltech for the free edition of the Qt toolkit; it is approved by the Open Source Initiative and accepted by the Free Software Foundation as a free software licence, but it is not copyleft and it is not GPL-compatible, and the Debian project rejects software licensed solely under it — the objections being a choice-of-venue clause, a requirement to forward modifications to the initial developer, and a forced blanket licence back to that developer. The venue clause is not abstract: the licence text shipped in the EleBBS tree states that the licence is governed by the laws of Norway and that disputes shall be settled by Oslo City Court, which is where Trolltech was. For a project whose author explicitly intended to keep control while accepting contributions, those terms were features rather than bugs. The copyright headers throughout the surviving source read "Copyright (C) 1999-2003 Maarten Bekers. All rights reserved" above the Q Public License notice, and the tree includes the licence text itself.

That source tree still exists. A copy was published to a public code-hosting account in August 2013, comprising the EleBBS units, the EleCOM library and a copy of the AsyncPro communications library, with build instructions headed EleBBS v0.11.b1 — a beta beyond the last release candidate, and the furthest point the code is known to have reached. The project's own domain, by contrast, now serves an empty page: the frame and the coloured header are there, the navigation bar is gone, and a page-generation time in seconds is printed at the bottom of nothing.

Running a board after the web

The honest question about this newsgroup is why it existed at all. It was proposed in 1999, four years after the bulletin-board market collapsed, to discuss a program begun in 1996, eighteen months after the same collapse, whose whole purpose was to be compatible with a package whose author had already given up on it. The objection lodged against the group's creation — not enough traffic — was not obviously wrong.

The documented answer has three strands, and none of them is romantic. The first is that a collapsed market is not an empty one. Boards that had never been businesses had no revenue to lose, and a hobby that costs a telephone line and an old computer can be continued indefinitely by anyone who still enjoys it. Communities that had formed on particular boards — local ones especially, where the callers knew each other — had no reason to disperse simply because a better technology existed elsewhere. FidoNet's node count fell for a decade and then stopped falling at a few thousand, which is the statistical shadow of exactly that: the people for whom the network was the point rather than the means.

The second is technical, and it is the strand EleBBS embodies. A bulletin board is a program that talks to a caller over a character stream. It does not intrinsically care whether that stream arrives down a telephone line or a TCP connection, and once someone wrote the shim, boards could be reached over the internet like anything else. The shim came in several forms, all of them documented in the standard account of RemoteAccess, which never had internal Telnet support of its own: FOSSIL drivers that spoke Telnet instead of a serial port, virtual COM-port engines under Windows, SIO and VMODEM under OS/2. EleBBS did not need a shim, because it had a Telnet server compiled in from 2000. Its newsgroup and IRC support pointed the same way — a board that could pull Usenet groups into its own message areas and drop its callers onto an IRC network was no longer a walled garden reachable only by dialling. The standard reference account of bulletin board systems names EleBBS in exactly this company, among the packages that provide access over Telnet rather than dial-up.

The third is that the retreat bottomed out and then partially reversed. Most surviving systems migrated to Telnet or SSH during the 2000s, and from around 2014 a retrocomputing movement brought a slow increase in internet-connected boards and nodes, with Telnet, rlogin and SSH used between systems and long filenames added to newer BBS software. The standing directory of internet-reachable boards, the Telnet BBS Guide, listed 1,046 systems on the count reported in mid-2026, only a small number of them still answering an actual telephone. That is a hobby, not an industry, and it is roughly the same order of magnitude as FidoNet's residual node count.

What EleBBS represents in that story is the moment the transition was made deliberately rather than nostalgically. It is a 32-bit, multi-platform, Telnet-capable, Usenet-reading program written to be compatible with a 16-bit DOS package from 1989 — built, in other words, so that a sysop need not choose between the community he had and the network everyone else had moved to. The software's own trajectory then followed its author rather than its market: development slowed not because the boards went away but because he took a full-time job, which is the most ordinary ending a hobby project can have and the one the record actually supports.

What a sysop support group carried

No archive of this group's traffic has been consulted for this page, and no thread from it is quoted or described here. What can be said honestly is what the software's own documentation shows sysops needed help with, because a package's FAQ, its upgrade notes and its known-bugs list are a reasonably faithful negative image of the questions its support forum received. On that evidence, the recurring genres were these.

Configuration. The board was configured by a separate program, ElConfig, and misconfiguration produced symptoms rather than error messages. The published FAQ's answer to a Telnet server that would not start is a checklist of four items: whether the paths were entered correctly in ElConfig, whether the EleBBS environment variable had been set, and what the log file in the system directory and the log files in the individual node directories said. A later revision of the same answer adds a fifth item about the console window being too large on Windows 2000. Anyone who has run server software recognises the shape of the answer and can guess the shape of the question.

Menus and upgrades. Early Windows and OS/2 builds could crash or exit immediately on reaching the main menu; the documented fix was to create a global menu file with the configuration program, a file which might legitimately be empty. Release notes referred sysops to numbered upgrade files for behaviour that had changed between versions, and the FAQ answered at least one question by simply citing an item number in one of them. A package that read another package's configuration inherited that package's conventions, and inherited conventions are the classic source of support traffic.

Doors, drop files and the serial port. The hardest structural problem the package had was that doors were DOS programs written against DOS conventions, running under 32-bit Windows and OS/2 builds that did not share them. The project said so publicly in March 1999 when it announced the shared door library, and again in its own release notes, which advise that the Telnet implementation cannot support traditional doors and that an additional program is recommended for running them. The FAQ's flat answer that the GUI build cannot and will not use a FOSSIL driver is the kind of statement that only gets written into a FAQ after it has been explained many times individually. SyncFossil, two years later, was the attempt to make the problem go away.

Modems. Every dial-up board rested on a stack of conventions a caller never saw: the Hayes command set, developed by Dale Heatherington and Dennis Hayes for the Smartmodem in 1981 and extended by each major vendor thereafter; the initialisation string that told a particular modem how to handle error correction, compression, flow control and result codes; the locked port speed; the FOSSIL driver underneath. Getting a specific modem to answer a specific board reliably was a matter of trading known-good strings with people who owned the same hardware, and that exchange is one of the things package-specific groups existed to carry.

Message bases and the mail chain. With Hudson, JAM and later Squish formats all in play, and a separate tosser writing into the same files, choosing and maintaining a message base was a live question — the 0.10 notes add Squish and in the same breath say that the recommended format is still JAM. Corruption of shared files is addressed directly in the documentation. The 0.09 notes explain how to force a complete rebuild of the user file and remark that this is also handy after corruption caused by utilities that were not properly enabled; the 0.10 notes record that programs which modify configuration files now write a semaphore file first, to stop two of them updating the same file at once. That is a fix you make after users report the symptom.

Where the questions actually went. The newsgroup was never the only channel, and the package's own pages name the others: a mailing list set up by one of the users and announced on the site in September 1998; a beta testers' list to which the author sent his major announcements, including the one that opened the source; an #EleBBS IRC channel advertised on the front page in 2000; and a separate third-party FAQ hosted by PC Micro, which the project's own FAQ recommended for anything more specific than generic setup problems. A package-specific newsgroup sat inside that spread rather than above it, which is one reason a support group can be real and quiet at the same time.

And the perennial one. A group attached to a single package, whose upstream goes quiet, faces the problem that every such group faces: the questions do not stop when the releases do. Here the record is at least explicit about the cause and the remedy. The author announced the stall himself, published the source under an open licence so that others could give the development a push, and said in the same message that he was not abandoning the projects. Whether that produced a maintained fork is not something this page can establish; what is established is that the code was placed where it could be picked up, and that a copy of it is still publicly readable.

What the record does not show

Almost everything specific to this newsgroup, as opposed to its subject, is missing, and it is worth listing the gaps precisely so that nobody mistakes the software history above for group history.

• No traffic figures. Nothing here counts the group's articles, posters, threads or years of activity. The only number in the administrative record — 351 messages between 1 October 1998 and 22 March 1999 — is the proponent's own count, taken before the group existed, from a search of Deja News for a string across all of Usenet rather than a measurement of any group.
• No participants. Two names appear in this article's account of the group's creation: the person who issued the creation control message and the person who issued the removal. Both are taken from the message headers. Nothing is known here about who read the group or wrote in it.
• No threads. The genres described above are inferred from the package's own documentation, not from postings. No subject line from this group is quoted anywhere on this page, because none has been verified.
• No end date. The group is still listed and still marked open for posting. That is a statement about news server configuration files, not about whether anyone has posted recently, and the two are entirely independent.
• No fork history. The source was released under the Q Public License in April 2003 and a copy was published to a public repository in August 2013 with build instructions naming version 0.11.b1. Whether development continued anywhere between or after those dates is not established here.

One further caution about the sources. The dated release history, the feature lists, the FAQ answers and the open-source announcement all come from the project's own website as preserved in web archives. They are primary documents and they are internally consistent, but they are the developer's account of his own software. Where they make claims that can be checked against independent references — the RemoteAccess lineage, the compatibility target, the platforms, the licence, the surviving source — those checks pass. Where they cannot be checked, they are reported here as what the project said about itself, and phrased that way.

Scope and limits

This page documents a newsgroup and the world its subject belonged to. It is not a manual, and nothing here should be taken as instructions for installing or running the software; the version numbers and dates are given because they are the checkable spine of the article, not because anything on this page constitutes support.

Neighbouring subjects belong to neighbouring pages. The origins and governance of the alt.* hierarchy, including why a group can be created by one person and ignored by another, are covered on the alt.* page. What Usenet was, and how it differed from every other network of its period, is covered in the introduction to Usenet. The telephone network the whole arrangement rode on has its own group in this directory, at the alt.dcom.telecom page. The computing hierarchy proper, where the formally chartered technical groups lived, is covered on the comp.* page — and it is worth noting that the DOS-era software groups sat on both sides of that line, with formally voted groups such as the one for the 4DOS command processor in comp.* and the bulletin-board packages almost entirely in alt.*. The complete index of groups in this directory is the all-groups list.

A final note on why a page like this is worth writing at length. A group with one subject and no surviving traffic archive looks, from the outside, like nothing. But its subject was a real piece of software with a public history running from 1996 to 2003, a named author, a dated release chronology, a specific compatibility target, five simultaneous platform builds, a licence change with a stated reason, and a surviving source tree — and it sat inside a technical world with its own standards documents, addressing schemes and economics. The newsgroup is the door. What is behind it is the last generation of a way of being online that predated the web, briefly outran it on features nobody expected, and then quietly kept going, at a size now best measured in the low thousands.