Tomorrow it is 10 years ago that the CDK was founded.\nThe project has considerably grown and has a high impact on science.\nThe CDK code base did not start 10 years ago, but was founded on the code bases\nof CompChem, JChemPaint, and Jmol, but has seen several\nreincarnations since the start.
\n\nThe CDK project by now is so large, it is hardly possible to keep up, and I\nam very grateful to particularly Chris\nand Rajarshi for actively keeping the project going,\nto all those that submit patches and bug reports, and to all that use the CDK\nin their software. This created a healthy development and user community, as\nis visible from the blog aggregator Planet CDK.
\n\nBut, reflecting on the past, it is also clear where the project needs help.\nThe flow of CDK News papers is effectively void, the documentation\nneeds serious updating, we still need way more unit testing, as well as more\nin-depth validation of algorithm implementations. And we all know we are short\non code reviewers to control the flow of patches going into the library. There\nis also still some functionality missing, like a simple force field (the Jmol\nLGPL UFF code could be ported, doi:10.1021/ja00051a040)\nand support for popular file formats like Symyx V3000 molfiles and the ChemDraw\nCDX formats.
\n\nI am really positive about the future of the CDK project and the current future\nis mostly limited by the number of people working on maintenance, code quality,\nand releases. For example, I would love more frequent releases, but making a\nrelease takes about half a day. It is not merely creating the files to distribute,\nbut also to ensure that the branch is in a releasable state, that it has no\nimportant outstanding bugs and at least does not have more unit test fails than\nthe past release (preferably fewer…), and writing a release message.
\n\nThis maintenance also involves writing unit tests for reported bugs, and ensuring\nthat someone fixes the bug. This is a second important challenge to the project:\nhow to keep the original code authors involved, and make them feel responsible\nfor making bug fixes in the code they wrote. Cheminformatics is very much a\nfield of write once, go off to another job, and forget about it. This is why\nI am so strong on having unit tests, proper JavaDoc, and clean code, so that\nothers can do this required code maintenance.
\n\nIf we look at the current numbers,\nwe see about 170 open bugs out of 1115 ever reported, and 24 open patch reports\nout of 276 reported. Those are acceptable numbers, though they need to go further\ndown.
\n\nI really hope that 2011 will be the year that commercial CDK support is picking\nup, providing value for users by providing dedicated support. Right now, to\nget something fixed, you need to wait for someone to fix the problem; however,\nnone of the CDK developers actually is working solely on the CDK and many contributions\nare done in spare time. That nicely shows the power of Open Source, but also\nwell illustrates the need of proper funding. That said, this is merely limited\nby people actually willing to pay for such support, or even just to donate financial\nsupport to the project. If you are interested in that, please contact me offline,\nas we have the means in place to do this.
\n\nIn short, I have no clue where the CDK will go, except that it will continue\nto grow. This is another power of Open Source: the accumulated effort cannot\nbe lost. Seriously, back in 2004 I wrote a What’s 2004 going to bring?,\nand here’s a lousy attempt for 2011:
\n\nBut we will also have to overcome these issues, for which we need your help:
\n\n