You are highly encouraged to visit our home page to see this information formatted and to get up to the minute news and information. The launchpad page is strictly for developers. To get more information on releases, documentation, and news, please visi the homepage.

About:
--------------------------------
This is an open-source project to recreate the Telegard BBS from scratch into a modern, internet ready, and standardized system.

Language Selection:
--------------------------------

Ruby has been selected as the primary language for this project. This was chosen for several reasons. Ruby offers portability to multiple CPU platforms and operating systems, has an extendable set of gems (libraries), is relatively easy and faster to write than other more complex languages, is completely object oriented , and has support for a majority of the design goals out of the box. The original Telegard (among other BBS systems) were written primarily in Pascal. This project originally started with FreePascal, but found it difficult to introduce modern concepts easily using the codeset provided.

License Selection:
--------------------------------
OpenTG is developed and released under the GNU GPL v3 license. Although other licenses were evaluated, the GPL provides the greatest level of protection and compatability with other free software projects. The CDDL, OSL, and BSD licenses were also considered.

Current Design Goals:
--------------------------------
Here are some of the key target items:
* Target operating systems: Linux, FreeBSD, OpenBSD, NetBSD
* Store all data file data in SQL databases.
* Provide database abstraction for RDBMS flexibility (ex: MySQL, PostgreSQL, Firebird, Sqlite)
* Utilize XML for configuration data storage (easy to work with and manually change)
* Administration tools should be both extendable and API based to allow for add-on tools.
* NCURSES & X-11 interface to administration & WFC
* Web Interface to Administration & Status information
* ANSI & AVATAR support, also fix for non-msdos terminals with character support detection

This is by no means an exhaustive list, and additional management and tracking tools will be in place soon. In the meantime, please email me if you are interested in participating with this project (chris.tusa _at_ opentg.org).
Coding Standards

To keep the project clean and organized, we ask that developers follow some coding standards.

Best Practices:
--------------------------------
* Always start new source code files with the provided ’srcheader.txt’ template.
* Maintain code cleanliness: Proper spacing, capitalization, and comments.
* Comment each function & complex section with detailed descriptions.
* Comment each Variable, Objects Classes, and Types with descriptions.
* Place all files in the proper location based on the directory structure specification (see below).
* When in doubt, ask a fellow developer or post in the forums.

Current Directory Structure:
--------------------------------
This will expand as the items develop for things such as wbem, or X11 GUI, etc.

opentg/ - Main trunk of the source code
opentg/conf - Location where the program’s configuration files are stored.
opentg/core - root directory of the CORE source code.
opentg/core/deps - Additional pascal units (libraries) that are dependencies.
opentg/core/deps/ncurses - Ncurses library unit for handling CLI design.
opentg/core/deps/sql - Database libraries for various supported database engines.
opentg/core/deps/xml - Library for reading/writing XML files.
opentg/dbms - SQL structure files and queries.
opentg/docs - Documentation to distribute with the source code and program.

Here are some of the key target items:
---------------------------------------------------
- Target operating systems: Linux, FreeBSD, OpenBSD, NetBSD
- Store all data file data in SQL databases.
- Provide database abstraction for RDBMS flexibility (ex: MySQL, PostgreSQL, Firebird, Sqlite)
- Utilize XML for configuration data storage (easy to work with and manually change)
- Administration tools should be both extendable and API based to allow for add-on tools.
- NCURSES & X-11 interface to administration & WFC
- Web Interface to Administration & Status information
- ANSI & AVATAR support, also fix for non-msdos terminals with character support detection

This is by no means an exhaustive list.

Developer FAQ

* Why have you selected Ruby?

Ruby is not only a great, object-oriented language, but it is also very extendable via gems. The resulting code is also concise when compared to other languages. Additionally, it is portable to other languages. Since this is an open-source project, it doesnt really matter if the code is included. It will also make customization for the end-users very flexible.

* Why have you abandoned Pascal?

Pascal is a tried and true language. Several languages were evaluated for the primary codebase. In particular, we looked closely at C++, Ocaml, Python and Java. We initially selected a compiled language for some of the slight performance advantages over scripting. Additionally, scripted languages and Java have dependencies on interpretters or virtual machines which have both advantages and disadvantages. We also compared several Pascal compilers, such as FreePascal, GNU Pascal, as well as Borland/Turbo, and several others. FreePascal was preferred : 1) its availability across multiple CPU platforms and operating systems, 2) It has been updated more recently and rapidly than GNU Pascal, and 3) Many function units (libraries) have been contributed which provide support for some of the projet goals.

In the end, there were difficulties getting the Pascal code to work as expected. Although many of the addon packages such as fpc-xml, and fpc-db were there, they were not well documented and often caused unknown errors to occur.

* Can I add modules in other languages?

There is certainly a need to have developers contribute code in other languages. For instance, as we build upon the API and management framework, we want to take advantage of WBEM, XML, SQL, PHP, Rails and possible others. We may also find that Java may play a key role in building administration tools.

* I am not a programmer. What other ways can I get involved?

There are other items where this project will require help in the future. Things like Documentation, Graphics (ANSI, Avatar, etc), Forum Moderators, Alpha/Beta testers, or just making suggestions or helping spread the word. This is an open-source project by and for the community. Please participate to help make OpenTG a success.

* Are you using any source code from the original Telegard BBS?

NO. Although a leaked copy of the source code is floating out in the wild, it is old and its state is unknown. Please do not contribute any original telegard code into this project. If you have a copy of it, consider it un-useable as the Copyright and authenticity is in question. Although WWIV was recently open-sourced, Telegard was written at a time when source code was not. Its original authors may not approve, nor is it the purpose of this project to start a code base from the original. This is a rewrite project to recreate the look and feel, while enhancing and modernizing the functionality.

* Do you have plans to make a Windows port?

Because Ruby is portable, it is certainly possible to build a binary release for Windows. At this time, we are primarily targeting *NIX.

* What about a MacOS-X port?

Since MacOS-X is based on BSD, it should be relatively easy to create a release. The challenge for this platform will be the GUI tool set. There are no initial plans to build native tools, however testing will be performed to ensure it works in the CLI and under X11.