Marcus D. Hanwell | Marcus leads the Open Chemistry project, developing open source tools for chemistry, bioinformatics, and materials science research. He completed an experimental PhD in Physics at the University of Sheffield, a Google Summer of Code developing Avogadro and Kalzium, and a postdoctoral fellowship combining experimental and computational chemistry at the University of Pittsburgh before moving to Kitware in late 2009. He is now a Technical Leader in the Scientific Computing group at Kitware, a member of the Blue Obelisk, blogs, @mhanwell on Twitter and is active on Google+. He is passionate about open science, open source and making sense of increasingly large scientific data to understand the world around us.
Authored Comments
Thanks for putting this together, it was great to see some of the highlights for you as a kernel developer. The success of the kernel is certainly something many of us aspire to, and want to learn from.
As I said in the article in an ideal world APIs would be stable forever, but the reality is that this is rarely possible. New technologies are developed, better ways of batching commands, composing data, etc. If you don't evolve your API to take advantage of these things then people will often move on to libraries that do, and this is why most libraries have used version numbers to signal what might have changed - major version could be API changes, minor version is usually additions to API, bug fix release just fixes bugs/issues. There is an implicit promise, but there is also an implicit promise to continue developing the library, adding features, and taking advantage of new technology/approaches/ideas.