asoplata
I don't work in the science-fundraising space, but my gut tells me that now would be a good time to do the last option: with the Trump admin interested in trying to reduce the NIH's budget by 40%, researchers are increasingly looking to non-federal sources of money to continue doing their (expensive) research, like the private science-granting organizations mentioned above. At the same time, there's probably a lot of philanthropists who recognize how terribly shortsighted decreasing the NIH's budget is, and who are willing to contribute more to private science funders in an effort to fill the gap.
The paper alone is, almost always, never enough to fully reproduce the result. I've been bitten by this almost every time I've tried to implement someone else's computational model. It comes down to that only relying on your paper to explain your code leaves a LOT of room for errors. I've experienced all of these when trying to implement someone else's computational work without their code being published:
1. Despite your best efforts, you include fundamental, result-breaking typos in the equations you write up to explain the math of what you're doing. This WILL happen to you at some point in your career, and in my experience, it's a problem in >>50% of computational modeling papers.
2. There are assumptions in the logic of the code that you don't include in the writeup, since they're obvious to you, but you don't realize that someone else trying to understand your paper won't necessarily be starting with those same assumptions. This happens frequently with neural models that use complicated synapse-computation schemes.
3. Your codebase may be big enough that you think code part X works a certain kind of way from memory, but you forget that you changed the logic late in the project to work in a different way.
4. Publishing your code at the time of publication prevents "Which version did I use?" problems. It's very common for people to continue to work on their science code for new work, but they don't bother to save/tag a SPECIFIC version of their code that was used for the actual paper. This results in that even the author doesn't know what exact values were used for the results in the paper!
Any "competitive advantage" has to be weighed versus "positive exposure". If your code is the primary research object (as opposed to the data), then it's technically possible that someone may grab your code, extend it to do the next, interesting use of it, and then scoop you before you can do it yourself. However, even if this happens (which it probably won't), consider the following: 1. You can't build a successful career out of just small extensions to the same piece of code, and so that codebase won't be the main kernel of your career, but rather your understanding of it.
2. For every 1 person that tries to use that to scoop you, IMHO there's going to be at least 10 other people who see your code and reach out to you for help with it, or just to ask a question about it, or reach out for potential collaboration! In other words, depending on the field, if you publish the code, I think you're likely to gain new/future collaborators at a MUCH faster rate than people who compete against you. You'll be surprised at how many researchers on the other side of the planet are interested in your software!
3. Even if someone scoops you with your own code, if they give any indication it came from you, you still get to count that as a publication that built off of your software work when you're applying to jobs :)
4. At least with US federal government funding, it's gradually becoming required to do this anyways, and I believe/hope that it's going to become the standard anyways very soon.
Finally, don't fret about polishing/cleaning/organizing the code, especially style. For others trying to reproduce your results or just investigating how you did things, the main thing that matters is that your code runs "correctly", i.e. how you ran it to get the results that you did. One idea is to publish it "as is" for the CORRECTNESS of the paper, put a git tag indicating "original version", and THEN clean it up on Github/wherever. This helps prevent any new "organizing" of the code from potentially breaking something, which is counterproductive. This way, when people go to your code page, the first thing they see is a nicely-organized version, and gives you time to test that it works the same. Honestly, if you care enough about this at all, then your code is probably significantly more organized than 95% of research code out there; the standards of code quality in science are VERY low, which is completely different than private sector software engineering.* edits are for markup
Similarly, if those basic needs were met a la Universal Basic Income or a Star Trek society, there'd probably be less bullshit jobs of people doing something, ANYTHING, just to earn enough to live and provide for their family.
List of Open Computational Neuroscience Resources, contributions welcome!
List of Open Science Resources, contributions welcome!
Generally speaking, I find that the more expensive a rare academic tome is, the more likely there are legal/etc. versions online (PDFs, HTML, DjVu, etc.), indexed by Google. That seems to be much more true for STEM texts than those of the humanities, though.
(shameless plug alert) I wrote a super-simple Makefile script for using Pandoc, called acadoc [2]. It lets you call "make beamer", "make manuscript", "make html_presentation", etc., in a directory with Markdown files to turn them all into whatever presentation/manuscript/paper/etc. you want. The key thing, though, is that for LaTeX presentations/etc. it uses an intermediary "style/manuscript.tex" file to customize how you want your resulting LaTeX to look -- so if you want the same content, but decide the presentation looks better with white-on-black instead of black-on-white, you only need make a few changes and create a "style/manuscript_dark.tex", copy-paste that style in the Makefile, and now you can call "make manuscript_dark". It's meant to be quick and easy to use, and theoretically easy to add new recipes to.
If you want some more serious power about multiple document-type exporting, check out the links in the Acknowledgements section of Acadoc, shown here:
- https://kieranhealy.org/blog/archives/2014/01/23/plain-text/ - http://jeromyanglim.blogspot.com/2012/07/beamer-pandoc-markd... - https://github.com/timtylin/scholdoc - http://scholarlymarkdown.com/
(Yes, I know LaTeX styles/stylesheets are a thing, but I've never taken the time to learn them, nor figure out if they can do all the custom formatting a regular .tex stylization file can do.)
It's still completely possible to learn some of the outgoing connections or equivalences after a specific search of the internet, but the more things you spend time ruminating on, the more connections/realizations seem to almost "bubble up" out of your subconscious/whatever. I think this is what [inspiration](https://en.wikipedia.org/wiki/Artistic_inspiration#Ancient_m...) is: the result of subconscious processing or drawing relationships between thoughts in your head that are memorized. That, I think, is what you wouldn't have anymore if you were to completely outsource your knowledge to the Internet. I have witnessed some brilliant statisticians come up with completely new ways for researchers to think of their data/analysis, without ever consulting Google...though that's a relatively poor example, and more related to developed Mathematical Intuition than anything else. I would argue that said developed intuition is a perfect example of drawing underlying connections between things by letting them stew around in your brain, connections that would be very much harder to find overtly.
Facebook is blocking all mention of Tsu.co on every platform
I love this site for many reasons, e.g. searching "site:ycombinator.com <search term>" is one of the best sources of finding modern opinions on languages, libraries, the state of coding in certain places, and most of all some of the best opinions on what can act as good introductory materials on anything software/langs (in addition to stackoverflow).
It's nice to have a finger on different tech scenes and where people, sometimes, are willing to call each other on BS. Oppositely, it's cool to see posts about a product/service and see that the actual company actively responds to comments here in a lively fashion.
One of the biggest reasons for me has been seeing whenever's the occasional open academia article or movement starting to spawn, whether it be open access, open data (e.g. [dat](http://dat-data.com/)), or my favorite, open code. There's an unbelievable amount of reinventing the software wheel that goes on with a ton of PhDs, and the FOSS community proves that doesn't have to be the case. Trying to take the lessons it's learned to the sphere of science is something that an increasing amount of people are thankfully interested in, and this site is one of the only ways I've heard about initiatives in that regard - most notably, [Mozilla Science Lab](http://mozillascience.org/)