Xooctory is an open source continuous integration server, aiming to provide the following features:

• Open Source
• Massively scalable
• Flexible
• Build dependency aware
• Instant and rich feedback
• Secured

You can get a good introduction to Continuous Integration principle on Martin Fowler Blog.

Here is his definition:
Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly. This article is a quick overview of Continuous Integration summarizing the technique and its current usage.

Xooctory is not only a continuous integration server, it's also a project meant to experiment with top notch technologies.
As mostly Java developers and fellows, xooctory is java based, and tries to leverage the latest open source components and libraries.
As such, it can also be used only to see how the technologies we chose work together, and maybe how they could improve your own projects.
Here is a short list of some of them we are proud to use in xooctory:

• Java 6
• Spring 2
• Hibernate 3
• Mule 1.3
• Wicket 1.3
• Derby 10.2
• ApacheDS 1.0
• Logback 0.9
• Jetty 6
• Ivy 2

Xooctory has been started in early 2007, so this is a very recent project, still in early phase of development.
Nevertheless xooctory is self hosted since its 0.1 version. This means that you can easily check how it looks like, and even maybe use it now if the rudimentary features already implemented fulfill your needs! But prepare to be quickly frustrated if you expect all the outstanding features which are in our road map: Paris hasn't been made in a day!

The continuous integration servers landscape is already crowded with a lot of good products, open source and commercials. So why create a new one instead of using or improving an existing one?

The first reason is because at the time we started the project we didn't find a server fulfilling all the requirements of xooctory.

You can find very good commercial products fulfilling almost all these requirements but the first one: they are not open source.

You can find very good open source servers fulfilling some of these requirements, but some of them are seldom implemented. Moreover, two of these requirements at least need to be considered from the beginning: scalability and build dependencies.

Indeed, to achieve massive scalability you need to consider this issue from the beginning. Scalability with xooctory means dealing with large number of projects, large number of users, and large number of builds. This means that the architecture needs to be designed accordingly. This also means that the user interface need to be adapted.
Furthermore build dependency is not easy to plug in an existing system, especially a distributed one.

The second reason is simply because we wanted to start a new project, web based, with challenging features and making heavy use of latest technologies. Because we love technology. Because the market is asking for talented web and server developers, and what's better to improve your skills and recognition than to work on such a project?

There are already several continuous integration servers, both open source and commercials.

For an interesting and wide comparison, you can check the continuous integration server matrix:
http://damagecontrol.codehaus.org/Continuous+Integration+Server+Feature+Matrix
This matrix is a little bit outdated though, and does not consider some servers like hudson, bamboo or xooctory :-).

For the moment it's difficult to compare xooctory to other software, since it's still in early stage of development. So if you're looking for a continuous integration server usable right now, we recommend using another one (and if you really ask, we recommend hudson in most cases).

So right now we can also talk about the others by explaining what we found was missing, which can also help you understand better why we have started the xooctory project:

• cruisecontrol
very flexible, but with a really poor web interface, not scalable (based on files only), and no proper way to handle build dependencies, bad support for distributed builds

• luntbuild
database based, with a real build management system, but no support for pluggable build dependencies (loaded from an ivy file or a pom for instance), no instant feedback, no support for distributed builds as far as we can see

• continuum
Very good integration with Maven 2, simple to setup with maven projects, but no distributed build management ATM, even though work has been done by GBuild. The problem is that distributed build is not easy to plug into an existing CI server when you want to support build dependencies properly (which continuum does, but it doesn't seem that the distributed build part is constrained by the build dependencies (to avoid failed builds when you commit changes on two modules, on depending on the other). Other problems raised by distributed builds is how feedback on the build is provided to the core system: some features like working copy browsing, or instant feedback (view build log during build progress for instance) are not easy to implement in distributed builds if this hasn't been designed from start. Another problem with continuum is its pour integration with Ant (eg no integration of unit test results as far as I can see, even build failure is not properly reported)

• hudson
this is probably the closest to what xooctory intend to be.
The main difference is that hudson data is file based, and therefore not very scalable, and thus far from the massive scalability we want to provide.
Moreover build dependencies cannot be derived automatically from project files (ivy file or pom), and they do not provide much security features.

Xooctory is licensed under the Apache Software License 2 (ASL 2), which is very business friendly.

Xooctory is the contraction of Xoo Factory. The Xoo prefix is used to recognize a set of projects developed within xoocode.org, and has no particular meaning.
Factory is used because one of the aim of continuous integration server is to provide frequent builds of the source code base, thus being used as a software factory.

Xooctory is an open source project following an open development, so any help is welcome. Since it is still in early stage, it's very easy to catch up with the current developments. So if you're interested in joining a enthusiast community, check how you can get involved