Ex-Google Chief's Venture Aims To Save Neglected Science Software (nature.com) 23
David Matthews writes via Nature: See whether this sounds familiar: you build a piece of software to solve a research question. But when you move on to the next project, there's no one to maintain it. As it ages, it becomes obsolete, and the next academic to tackle a similar problem finds themselves having to reinvent the wheel. [...] Now, a funding initiative hopes to help ease that burden. [...] In January, Schmidt Futures, a science and technology-focused philanthropic organization founded by former Google chief executive Eric Schmidt and his wife Wendy, launched the Virtual Institute for Scientific Software (VISS), a network of centers across four universities in the United States and the United Kingdom. Each institution will hire around five or six engineers, says Stuart Feldman, Schmidt Futures' chief scientist, with funding typically running for five years and being reviewed annually. Overall, Schmidt Futures is putting US$40 million into the project, making it among the largest philanthropic investments in this area. The aim is to overcome a culture of relative neglect in academia for open-source scientific software, Feldman says, adding that support for software engineering is "a line item, just like fuel" at organizations such as NASA. "It's only in the university research lab environment where this is ancillary," he says. [...]
Those setting up VISS centers say Schmidt Futures' steady, relatively long-term funding will help them to overcome a range of problems endemic to academic software. Research grants rarely provide for software development, and when they do, the positions they fund are seldom full-time and long-term. "If you've got all of this fractional effort, it's really hard to hire people and provide them with a real career path," says Andrew Connolly, an astronomer who is also helping to set up the Washington centre. What's more, software engineers tend to be scattered and isolated across a university. "Peer development and peer community is really important to those types of positions," says Stone. "And that would be extraordinarily rare in academia." To counter this, VISS centers hope to create cohesive, stable teams that can learn from one another. [...]
Dario Taraborelli, who helps to coordinate another privately funded scientific-software project at the Chan Zuckerberg Initiative (CZI) in California, says that such initiatives fill a key gap in the scientific-software ecosystem, because funding agencies too often fail to prioritize crucial software infrastructure. Although there are now "substantial" grants dedicated to creating software, he says, there's precious little funding available to maintain what is built. Computer scientist Alexander Szalay, who is helping to set up a VISS centre at Johns Hopkins, agrees, noting that very few programs get to a point where enough researchers use and update them to remain useful. "They don't survive this 'Valley of Death,'" he says. "The funding stops when they actually develop the software prototype."
Those setting up VISS centers say Schmidt Futures' steady, relatively long-term funding will help them to overcome a range of problems endemic to academic software. Research grants rarely provide for software development, and when they do, the positions they fund are seldom full-time and long-term. "If you've got all of this fractional effort, it's really hard to hire people and provide them with a real career path," says Andrew Connolly, an astronomer who is also helping to set up the Washington centre. What's more, software engineers tend to be scattered and isolated across a university. "Peer development and peer community is really important to those types of positions," says Stone. "And that would be extraordinarily rare in academia." To counter this, VISS centers hope to create cohesive, stable teams that can learn from one another. [...]
Dario Taraborelli, who helps to coordinate another privately funded scientific-software project at the Chan Zuckerberg Initiative (CZI) in California, says that such initiatives fill a key gap in the scientific-software ecosystem, because funding agencies too often fail to prioritize crucial software infrastructure. Although there are now "substantial" grants dedicated to creating software, he says, there's precious little funding available to maintain what is built. Computer scientist Alexander Szalay, who is helping to set up a VISS centre at Johns Hopkins, agrees, noting that very few programs get to a point where enough researchers use and update them to remain useful. "They don't survive this 'Valley of Death,'" he says. "The funding stops when they actually develop the software prototype."
Start with documentation (Score:5, Insightful)
Bad or non-existent documentation makes it hard for others to use software. If others cannot understand it they may find it easier to write something new. Three different types are needed:
1) Internal, ie comments within the code. It will need maintenance: fix bugs; adapt to external changes (eg operating system); enhancements.
2) user manuals. How others use it, the API, command lines, file formats, etc.
3) searchable public index, good keywords. If no one knows that it is there then no one will use it.
Programmers hate writing documentation but it is as important as the code.
Finally (Score:5, Funny)
Thank god those hundreds of thousands of Matlab and Python scripts that implement elevator logic will be saved for future generations of scientists.
Re: (Score:3)
Re: (Score:3)
Sometimes you need some software for something and find that someone else already wrote nearly what you want, but it's such a mess that you just start from scratch again. It would be nice if you could ask someone to maintain that code and make it usable... But it's a horrible job and as a coder you would have to pay me A LOT to do that.
Re: Finally (Score:1)
Re: Finally (Score:5, Informative)
It's been a long time, but when I was in grad school, there were some open publishing platforms like PLOS ONE that required people publishing papers to store their code and data in an open repository. This doesn't mean github; there was some related science data publishing platform. They further recommended writing any software using open source languages, packages, libraries, etc. so that it's easier for other researchers to reuse (no licensing fees).
I thought all of that was really smart. It's not to the level of funding ongoing support, but it's a start.
PLOS ONE also required paper authors to write down their full methodology in detail, including replicating portions that they obtained from other referenced works so that anyone reading their paper could replicate the study without diving down a trail of references, some of which might be hard to find. And they didn't have a page limit.
At the time, all of this seemed so enlightened to me, and it still does. It's like proper science. Every single time I tried to replicate a method from a paper I read, at least one detail was missing that I had to figure out somehow. Usually it wasn't too bad, but it was annoying.
Re: (Score:2)
That's all well and fine, but it's what led to the curre
Re: (Score:2)
Re: (Score:2)
Indeed. I have written both single-use and a bit more long-term use science software. The longer-term was basically for myself to be used a bit longer and for students doing thesis work for me. In both cases, documentation was in the code and essentially not sufficient to use it except with explanations from me. Now, I always got good feedback from students as to they were surprised how clear and easy to use my software actually was. But "releasing" it would have take a lot more work and maintaining it even
Re: (Score:2)
. At least that seems to be the situation in the CS field, but my guess is things are about as defective and broken in other disciplines as well.
Well, at least in the social sciences/learning sciences, you'd be right.
Re: (Score:2)
What if you want to repeat the analysis again with current data? Perhaps the paper was written 20 years ago, and 20 year of t
Re: (Score:2)
That's exactly the problem. In academia, software is seen as something written by amateurs who do it in their spare time with no plans to support it once they're done with the project.
It doesn't have to be that way. We could have a career path for software engineers in academia. Funding agencies could demand long term support plans for software and provide money to pay for it. We could decide that research software should be real software.
That's what he's trying to do. It's a tiny first step, but I'm g
Re: (Score:2)
Anything coming out from Google and Facebook (Score:3)
Anything coming out from Google and Facebook cannot be trusted not to send all data to the mothership.
Re: (Score:1)
I can't lie, whenever I see an article like this I put on my tinfoil hat and think it's just some stealth google PR campaign.
Re:Anything coming out from Google and Facebook (Score:5, Funny)
Money and Oversight (Score:1)
Without oversight I could see extremely bored maintenance programmers deciding to add features and needlessly upgrade components using very thin justifications, in the process making the software perform more poorly than if they hadn't touched it at all. Since they're getting paid anyway to do a job, one might as well roll up one's sleeves and "do it right" this time.
It's not hard to imagine, since I've seen it happen with coworkers: programmers specifically tasked with maintaining other people's code get f
Re: (Score:2)
I've seen this at my workplace as well and am thankful that I'm now in hardware instead of software. It seems there's nothing worse than someone else's code.
Is that because there's so many ways to do things in code, or so many styles that have changed over time? Or maybe it's easy to get something that mostly works but hard to get something good. What's your take?
Re: (Score:1)
Yeah, you raise a good point.
The people you hire for this kind of work need to be mature developers (as in: self-discipline and self-restraint). They should be people who can keep themselves from rewriting code because it's hard to read it. They absolutely, positively, must understand the importance of functionally neutral code transforms (they should understand that phrase, which I think I made up, without having it explained). They must be people who never, ever boil the ocean and start over, thus tra
Science & engineering software on Solaris and (Score:2)
If this is such a great idea, why's Eric paying? (Score:1)
Personally, I think this is a good idea. Question I have is, Why is Eric paying for it? Other than NASA, all of these institutions are sitting on piles of cash. $40M is a rounding error for some of them. If I were them, I'd build the consortium completely within academia and national science labs (NIST, Oak Ridge, Fermi, Argonne, JPL, etc.). I'd also make it part of the grant and budget process to help fund this. That part of the monies is to document and package the software tools for submittal to th