Sean from Intel has sent me this link together with the comment "This is why I think you will succeed. I see a lot of similarities."
Thanks Sean!
rapid release schedule
Yes, we release monthly. This is only possible because we always keep the code in our SVN in a state where it passes all regression tests. For big structural changes, like the one we just did, this may sound like a surplus in work, but it really isn't. Having a runnable state as a reference makes debugging so much easier when you wonder why new things don't work the way they should. We will be trying to engage our community to work with even more frequent versions than our monthly builds. For this purpose we are currently setting up a system for continous builds, to make a full set of all versions available every night.
regression tests
Yes, we do have a lot of them. We make all tests available with our download so anyone is free to take a look at how we ensure quality. For every new bug that we discover or that gets sent in we immediately create a regression test case if we do not have one already. Some of my favourite tests and switches:
- com.db4o.test.acid.CrashSimulatingTest
simulates writing all writes since the last flush in the wrong order, checking consistency after every single write, to make sure that db4o is safe when a system goes down and the OS file system cache has been partially written in reversed order
- com.db4o.Deploy.debug
makes the db4o file format human readable
- com.db4o.Debug.indexAllFields
creates an index for every single field in the regression test to make sure that indexing gets the maximum test load
- com.db4o.DTrace
is a very powerful internal logging tool that allows us to track defined events, i.e. "the fifth READ_ID event on ID 1654"
do one thing well
We store objects fast and simple.
In doing so we focus on the area where we want to be best: For embedded use of our product, where memory is scarce and low CPU speed requires maximum software performance. Our focus does make our product useable for other areas as well. Design and priority decisions are biased by our focus: "How will this work best for embedded use?"
avoid over-design
Right from the start of db4o it was headed for the simplest solution that could possibly work. Keeping nearly the entire codebase compatible to JDK 1.1 has really helped for the easy transition to .NET. Because the core of db4o has never been cemented in stone as the "one and final beautiful design", it has been constantly improving and we still have a lot of potential to make it even better, now that we have the experience, how to build an object database. It will be great fun to incorporate all the good ideas we have collected over time.
a central vision
db4o simply is the product we would always have loved to work with at the time we did development on top of relational databases.
documentation
Our runnable tutorial shows very well how important we consider documentation to be. We can still do better, that's why we are currently looking for people to help us to improve.
avoid standardism
We believe that the programming language is the best standard that we have. An object database should be completely invisible to a program except for one single area: Queries. Queries can also be expressed in terms of the programming language, by using Native Queries. Does a persistence standard need more? No.
up and running in 10 minutes or less
Sure. 5 minutes.
developer responsiveness
We certainly are very responsive in our forums. On top we provide professional support with a guaranteed response time of 24 hours. We could do better with some bug fixes than we are now.
Professional Open Source
Our vision will become more clear during the year. It's not "we" and "the community", it's not "we and them". We are working on making the community an integral part of our design, creation and distribution process. More will soon be visible here with a new interface of our community website that will allow us to collaborate even closer with our users...
easily update-able wiki pages
....and a Wiki will of course be part of the system.