bitweaver and TikiWiki

Created by: DennisDaniels, Last modification: 26 Oct 2008 (09:33 UTC) by laetzer
Bitweaver was a originally derived (forked) from an application called TikiWiki. However, after tens of thousands of code changes, the differences between bitweaver and TikiWiki are numerous to say the least.

Key differences

We have completely encapsulated all the TikiWiki features into their own self-contained feature, what we call a bitweaverPackage.
we are focused on high speed and high performance.
TikiWiki seems more focused on addon-like features. Bitweaver has chosen to deprecate many of the more obscure features of TikiWiki. However, because bitweaver has completely modularized the TikiWiki feature set into packages, it is possible to bring any of the TikiWiki features into bitweaver. If you are interested, get involved!


TikiWiki is a Content Management System (CMS) and portal application. Bitweaver started out as an experiment to modularise TikiWiki and allow admins to remove features they didn't need - not just disabling features but actual removal of the code. Bitweaver has broken TikiWiki's features into individual packages. This new modularity allows bitweaver to be an ideal Web Application Framework which is extremely customizable and ideal for integrating all kinds of other applications - proprietary or open-source.

Bitweaver supports many databases on Linux, Macintosh and Windows. Bitweaver has added modularity, scalability (speed!), data integrity, and stability to the original TikiWiki engine. This makes bitweaver much more suitable for enterprise or large scale, high traffic websites. Its ease of use makes it ideal for small sites as well. Bitweaver will still have all the great features that made TikiWiki famous, but has made the integration of applications much easier.


bitweaver ReleaseZero

Bitweaver ReleaseZero uses the identical schema as TikiWiki 1.8, and should be schema interoperable with a TikiWiki 1.8 install. ReleaseZero has all features of TikiWiki 1.8 working, and was an interim step between TikiWiki's all-in-one approach and bitweaver's modular framework. See bitweaverUpgrade and bitweaverFAQ

bitweaver 1

Bitweaver ReleaseOne introduced massive improvements in many aspects of the original schema, and ground breaking advancements in the CMS engine. This resulted in many schema changes, however we have created upgrade scripts that will eventually update the schema's of previous bitweaver and even TikiWiki releases. See bitweaverUpgrade and bitweaverFAQ

bitweaver 2

See bitweaverUpgrade and bitweaverFAQ

Neglected features

From ReleaseOne forward, not all TikiWiki features may get updated for future releases. Support for features is dependent on the interest of the community. Being an application framework, bitweaver considers each feature as a small application inside of it - what we call Packages. Not all code is good code, and we don't want poorly written or neglected code to slow down the advancement of the most important features.

In the beginning

As is tradition in the open-source world, bitweaver was forked from a predecessor. Begun in 2003, a few developers began to try to extend the TikiWiki portal application to support enterprise class websites (millions & millions of rows) by integrating custom functionality and existing open-source projects. While this was possible to do, it upset the goals of the TikiWiki project as an all-in-one portal application for smaller, simpler sites. And thus fork began.

TikiWiki was chosen as a starting point because of its many brilliant software designs, is loaded with features, and is very neatly organized. Unfortunately, TikiWiki has all of its features glued together. To begin a metaphor, TikiWiki is like a deck of cards. The numeric value represents a feature (blog, wiki, photo gallery), the suit represents a functional piece (template, library, logic). Now imagine the deck sorted by suit, and glued together. It makes a powerful feature set, but unfortunately it is a all or nothing proposition.

bitweaver developers decided that they did not want to even know about code they which they had no interest. In fact, they did not even want it on the server. The encapsulation normally reserved to software design was extended out to the feature set itself. So began a basic rule that any feature should be able to completely removed from the server, and no trace of that feature should be present in any of the remaining source code. This rule is what led to the development of "Services", as you will see below.

Following this rule, the developers unglued the TikiWiki source code deck, and arranged all the cards by suit. This left 13 piles, and thus each feature set nicely in one folder. This created a core notion of bitweaver, the "package", which at its simplest form is just a directory in the application root direction with a little or a lot of code. The word package was chosen as opposed "plugin" because bitweaver uses large grained modularity. Enormous amounts of code can exist in a package. In fact several packages contain their own plugin architecture.

A few of the piles, or packages, were crucial to the running of the system, the face cards following our metaphor, and those were dubbed the "bitweavercore". These are the packages that are required to install bitweaver, and login. There is not functionality beyond users and the main content engine. This is a great place to start writing your own application. You can checkout the bitweavercore with "cvs co bitweavercore" and you are ready to go!

Once the bitweavercore was settled, bitweaver began to actually simplify and remove features. A central content engined was added, called Liberty, which moved object oriented princples into the database tables directly. It evolved from a portal, to CMS, and finally today as a true framework with an extensive built in feature set.


God bless TikiWiki

by Kozuch, 11 Feb 2007 (22:41 UTC)

by Unknown, 03 Sep 2007 (05:00 UTC)
  Page 1 of 1  1