Full disclosure: fishRman has been my first-ever paper, open-source project, and coding project at all, so these advices are really just things I knew, wish I had known, or known better, before this journey.
If someone had asked me, before fishRman even started, “Do you know GitHub?”, I would probably have replied, “I know about GitHub”. Sure, I knew a little more than just that, but nothing more than how to download mods, patches and videogames, which hardly qualifies as the level of knowledge the question implied.
Still, I went on and created a repository.
#1 Advice: Start your project and learn by doing.
You will hit a lot of roadblocks, and you will have to Google up your issue(s), but you will learn a new lesson, a new technique, a new skill, and take one further step in completing your project, every time you find the solution that works for you. I am not saying that you should jump in head-first without knowing anything, but do not wait until you know everything, either.
For me, it was code sharing and version control. I contacted a friend of mine, someone who actually studied this stuff, to ask him questions that I knew were basic, but I wanted to be 100% sure of what I was doing, and his presence made me feel safe as I took my very first steps, following GitHub’s documentation.
It was immediately obvious I was going to need to either learn Git or use a software that offered a user-friendly interface to achieve the same goals. I highly recommend GitHub Desktop for people with 0 prior experience who, like me, chose GitHub over other similar services because of its popularity. Now, with a bit more experience, I decided to move to GitKraken, a tool very similar to GitHub Desktop that is not tied to GitHub alone and offers many more options and commodities, with the drawback of appearing more difficult to use.
Whichever way you choose, read its documentation. Not all of it at once, of course, but do read about what you are about to do until it comes natural.
At this point, I had my idea and a repository for it, but no road map, no timetable, no standards to meet and exceed. The situation would have been just fine if I only cared about developing software and knew how to do so, but that was not the case. I wanted to develop research software, something that researchers could use and cite in their work, and the only way I knew to make something citable, given my background as a marine biologist, was getting it published in a peer-reviewed journal.
#2 Advice: Aim before you shoot.
Find the journal you want to submit your work to, and follow their instructions. Some journals prefer papers that tell a tale, some only accept works about a certain geographic area, many journals focus on some topics, others on the technical approaches used.
Navigate the internet, ask colleagues, look up articles that are similar to what you want to do, and write down where they have been published. Doing so got me to an interesting journal, The Journal of Open-Source Software (JOSS).
“The Journal of Open Source Software is a developer friendly, open access journal for research software packages.” their homepage reads and, elsewhere on their website, we can see “We recognize that for most researchers, papers and not software are the currency of academic research and that citations are required for a good career.”
There it was, a peer-reviewed Open-Access journal for Open-Source research software. This ticked all the boxes I cared for!
From there, it was only a matter of writing code, documentation, and paper, the best I could while following their submission requirements.
Fast-forward 8 months and the peer-review starts.
#3 Advice: Accept feedback gracefully.
It is hard to hear every thing that is wrong about the results of months of your work, and you might be inclined to defend your project against such “attacks”. You will have to learn that not every critique is an attack to your work or person. The editor and peer-reviewers, in representing the journal, share your very same interest to make your work meet certain standards of quality, clarity, and accessibility, to later ensure a higher chance of citation from other researchers.
Actually listen to their concerns, share ideas on how to improve, and make it a constructive experience not only for your present work, but for your way of working in general, so that you will not hear the same critique again.
I think I fared quite well in this regard, and I would definitely call my peer-review process at JOSS a pleasant experience.
And just like that, with a comment on GitHub, my first paper got published.
#4 Advice: Have a strong internet presence.
“Getting your paper published is only half the battle, now you have to make sure people know about it, or it will have been all in vain.” was a recurring sentence from professors and lecturers, who never fail to stress the importance of getting your paper known and cited, so I was kind of expecting this struggle.
What I was NOT expecting was how difficult it is to actually strengthen my almost inexistent internet presence. I wish I had started sooner!
I only started using my Twitter account after the publication of fishRman, and not even that much. More or less the same goes for Linkedin. Thankfully, I already used Reddit, where I received some great feedback on many different boards, and there seems to be genuine interest for the project. ResearchGate is also a must, not as a social, but because posting your work there increases its chances of popping up on a Google search.
Congrats, @Shyentist_Pico, for your first paper! (https://joss.theoj.org/papers/10.21105/joss.03467)
Tweet
Although many Altmetrics derive most of their values from Twitter, I see a level of involvement in the discussion that is far greater on Reddit, with equal visibility for everyone, given how people mainly follow boards, rather than other users. Also, considering the (mostly) entry-level target audience of fishRman, I believe Reddit, which has a younger userbase than the other mentioned social networks, will be the platform where this project in particular will fare better.
Beyond social networks, I am also glad I decided to start OSMOS’s webpage, since it works well as a showcase for the group’s milestones, achievements, references, and as an archive for past, present, and future projects.
This leads me to the last piece of advice.
#5 Advice: Ain’t No Rest For The Wicked.
You’re an independent researcher, now, you don’t get to rest!
As for many other things in life, you must always be on the move, progressing, improving, building on what you have already built. If, like me, you produced software, you should always make sure to check for bugs and issues, while also trying to add new features to give the best results and user experience. If you produced a classic paper, you should continue your work branching from there, to answer all the questions that arose as a result of your previous study, or to apply the answers you found to a different issue.
Because I trust that, as an independent researcher, you are researching out of pure curiosity, to solve questions you find interesting, and to improve your field of study in every way you see fit.
As far as I am concerned, fishRman’s future includes:
- Automated unit testing, to test software like the pros do, reducing the chance of bugs.
- Allowing users to access their own Google Account, to remove the 1 million rows cap.
- Release as a computer application, to lessen the weight on the server while also speeding analyses up, since it would use the user’s own RAM, rather than the sharing server’s 1Gb.
There they are. These are my advices peer to peer. I hope they help you, if you have read thus far. Also, if you have any question, you are most welcome to join us.
(Featured image by Avery Evans on Unsplash)
OSMOS 