Image via WikipediaInteresting development today. Ruby on Rails and Merb have decided to merge rather than duke it out in the blogosphere as they had been doing? What does it mean? Well, Ruby and Ruby web frameworks are likely to be an increasingly visible part of the scientific software world in the coming years, so any news about the dominant Ruby web framework and a young hotshot alternative with some pretty smart people behind it merits attention. But I also found it interesting that two groups that seemed to genuinely get on each others nerves sat down together and decided to see how they could come up with a solution that should, hopefully benefit the general community.
The first thing that came to my mind was, why couldn’t AMBER and CHARMM have done this many years ago? They are similar enough in their history. Which also got me thinking about code in science. Wouldn’t it be nice to see the source for CHARMM or AMBER or NAMD on Github or someplace like that. You can have a core team managing patch reviews and formal point releases and then people forking out code to build their own specific apps. Given the history of that field and the kind of expertise required to develop such codes, perhaps the decisions made all those years ago were the right ones, and subsequent direction has been driven by a number of other reasons, but I’d really like to see scientific code on open code repositories. And wouldn’t it be nice to have something like the Apache foundation, where certain core projects could be brought to incubate and grow.
OK, it’s the holiday season. I am allowed to have my flights of fancy.
It's hard to say. A piece of scientific software has a much smaller niche than a web framework. The incentive to fork for the purposes of spinning off new directions seems much smaller, though forks for the sake of creating patches makes sense, and provides a chance to provide a patch for when the software maintainers are too slow to do it, fail to provide attribution to people providing bugfixes, or fail to acknowledge bugs exist at all. I have experienced each of these scenarios, and I have to say, this would quell those frustrations.
I was specifically thinking about algorithms in this case. New ways to solve a problem. Right now there is a formal process to do so, and it works and if you are an academic, no one stops you from implementing your own module, since you get the source code, but since everyone maintains their own flavor of the algorithm, its suboptimal.
But yes, there needs to be some discipline. Big projects like CHARMM have that. Others, I am not sure
License issues are typically a problem... social aspects too... such as understanding the source code, lack of documentation and unit tests to help with that, etc...
From merging rivals to code repositories
The first thing that came to my mind was, why couldn’t AMBER and CHARMM have done this many years ago? They are similar enough in their history. Which also got me thinking about code in science. Wouldn’t it be nice to see the source for CHARMM or AMBER or NAMD on Github or someplace like that. You can have a core team managing patch reviews and formal point releases and then people forking out code to build their own specific apps. Given the history of that field and the kind of expertise required to develop such codes, perhaps the decisions made all those years ago were the right ones, and subsequent direction has been driven by a number of other reasons, but I’d really like to see scientific code on open code repositories. And wouldn’t it be nice to have something like the Apache foundation, where certain core projects could be brought to incubate and grow.
OK, it’s the holiday season. I am allowed to have my flights of fancy.