But as we reflect on the past year and the amazing interest we've seen in 'nosql' and graph databases, it's clear to us that the world needs not only a very fast but also an amazingly simple graph database. And there's none out there today.
Now, don't get me wrong, I think Neo4j is very easy to use for a select group of people. In particular those highly skilled in Java or another language on top of the JVM.
But for example if you're a PHP hacker, or .NET programmer or if you prefer Java but don't find embedded databases fit well with your architecture -- in all these cases and more, getting up and running with Neo4j is a greater hassle than it should be.
We're significantly upping the ante on product usability and making this our number one focus area. Starting today, we're rolling out a number of changes that fall into two broad categories: quick releases of new features and improved feedback on whether those features were useful.
Changes so that we can quickly get new features in the hands of users:
- The most important change is that we're moving to a time-boxed, bi-weekly release schedule: every two weeks starting today, there will be a new publicly available Neo4j milestone release.
- This means that we will move to a layered release scheme where we provide three branches with different "velocity": daily snapshots, bi-weekly milestones and roughly twice-a-year stable releases. For more information, check out the release scheme on the wiki.
Changes so that we can get feedback on whether the new features work:
- As of this first milestone release, we include a component we call the Usage Data Collector (UDC). Inspired by Eclipse's Usage Data Collector, the Neo4j UDC sends a ping back home when users run Neo4j.
- Starting today, there will be a simple feedback form (powered by Crowdsound) on every Neo4j web page and in our web admin tool. From there you can easily suggest new features, vote on existing suggestions or just generally give us feedback.
- Not news, but it's worth mentioning that we always listen in on twitter (user @neo4j or tag it with #neo4j) and the community mailing list.
Immediate usability changes:
- We've been hesitant to make any changes without having a proper feedback loop in place. But we've taken an obvious step: the main download of Neo4j is now renamed from "Apoc" to, well, Neo4j. Hopefully that's a bit more intuitive!
- Furthermore, if you live in the JVM land you'll be happy to hear that the Neo4j artifacts are now published to the Maven central repo. This means that Maven users don't need to specifically add the Neo4j repository to the configuration any more when dependening on Neo4j releases. It'll Just Work(tm) out of the box. The same goes for other Maven-compatible tools.
The Usage Data Collector
A couple years ago Mike Milinkovich -- the Executive Director of the Eclipse Foundation -- wrote a blog post titled Collecting Usage Data in Eclipse. He wrote:
open source projects have a particular challenge in getting to know their users: we don’t ask people to register, and we don’t have even the most basic information we need to help improve our software. We lack the stats to make good decisions.
These "stats to make good decisions" is one of the traditional challenges of open source. In commercial enterprise software, there's registration forms and mandatory contact information and timed trials. In the consumer space, every successful web site known to man is measuring what features people use in order to prioritize development efforts.
With open source, it's harder to get real, quantitative facts on whether the features you roll out actually solve a real problem for your users. We normally rely on subjective perceptions of feedback from community mailing lists and similar forums. That feedback is great but also difficult to use as a reliable measure on whether we're actually progressing or just expending energy building features that provide marginal value at best.
UDC closes that gap by giving us the ability to not only get statistics on for example how many people downloaded Neo4j last week, but also how many of those people actually fired it up to try it out at least once. That's a huge improvement.
Technically, UDC is a separate component that is loaded as a kernel extension if it's available on the class path. Once loaded, it waits 10 minutes (to minimize noise from unit tests) and then sends a ping with very basic data (kernel and Java version, the store id and download site) once every 24 hours.
Furthermore, we've tried to make it as easy as possible to disable UDC. See the wiki page. In fact, since we've put all the "calling home" code in a completely separate component then removing that component will guarantee that UDC won't ever be activated. But we hope that most users will help us make better decisions by leaving it on.
We realize that any automatic data collection system is a huge privacy concern. And in the end if we get a strong negative reaction from our community we will remove UDC from the community download. But we strongly feel that it's crucial for us to have continuous feedback on whether the steps we take are actually moving us closer to building that amazingly simple graph database or whether we're just expending energy on features no one wants.
Other changes in 1.2.M01
On the kernel level, we've also worked a lot on lowering the memory footprint to minimize GC load. Neo4j 1.2.M01 also sports a new infrastructure for 'kernel extensions' that get automatically loaded during bootstrapping, which enables seamless integration of instrumentation and other non-core extensions. For more information, check out the Neo4j changelog here and the kernel changelog here.
All in all, we're very excited about the usability focus, the new release scheme and the first milestone in the 1.2 release. Please download and check it out for yourselves!