incubator-alois-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Urs Lerch <>
Subject Comparision OSSIM - ALOIS / roadmap suggestion
Date Fri, 05 Nov 2010 16:05:53 GMT
Hi all,

I promised to do a comparison between Apache ALOIS and OSSIM as a basis
for a roadmap. Here it is:

The functionality of OSSIM is really overwhelming. Therefore, from this
point of view it wouldn't be a good idea to compete with OSSIM. Rather,
it can serve as a target. Nevertheless, there are, at least in my
opinion, a few weak points in OSSIM where ALOIS could be positioned very

First, OSSIM is totally controlled by the company AlienVault. As far as
I have seen you can't be a committer, unless you are a staff of the
company. Interesting functionality, especially in respect to
performance, are due to commercial licencing. Therefore, the goal of the
project Apache ALOIS must be to be company independent and open to all
interested developers and companies. Furthermore, all functionality has
to be free. Possible business models should be based on services and not
on complementary closed code.

Second, OSSIM is not platform neutral, but depends highly on Debian
Linux. By supporting ALOIS on as many platforms as possible, we could
attract a comunity that is excluded by the project OSSIM. Therefore,
Ruby might be a better choise of programming language than I originally

Third, OSSIM (as well as ALOIS up to now) is a monolith. Although it is
well modularised and therefore scales well with load balancing, the
single components are highly dependent on each other and can't be simply
replaced by a better tool. Therefore, ALOIS should not only be modular,
rather the individual components should be interchangeable. This opens
the possibility to use highly specialised open source tools in various
spaces. This helps not only to reduce the further own effort, but in
every domain we can use the best tool there is.

As a result of this comparison, I'd suggest the following roadmap for
the months to come:

1. Making the code available
2. Support an online demo installation
3. Reference Installations incl. install documentation of as many
   platforms as possible
4. Define and implement interfaces between the modules
5. Optimize module for module and discuss the possibility of replacing
   own code by third party open source tools


View raw message