One of the hottest areas of growth for Python is in the scientific and data science communities. But if that work is done in an academic or research setting, it can be very hard to get proper credit for it. You have to write full-on peer-reviewed articles. That's where Arvon Smith and Joss, or the Journal of Open Source Software, comes in. Here, developers, scientists, or other
research-oriented folks can submit their software as a brief paper. Join us on this episode to learn all about that and Arvon's work with some of the most cutting-edge projects in astronomy at the Space Telescope Science Institute. This is Talk Python To Me, episode 157, recorded April 6, 2018. Welcome to Talk Python To Me, a weekly podcast on Python, the language, the libraries, the ecosystem, and the personalities. This is your host, Michael Kennedy. Follow me on Twitter
where I'm @mkennedy. Keep up with the show and listen to past episodes at talkpython.fm and follow the show on Twitter via at Talk Python. This episode is brought to you by ActiveState and Rollbar. Please check out what they're both offering during their segments. It really helps support the show. Arvon, welcome to Talk Python. Thank you for having me. It's really wonderful to have you here. I'm super excited to talk
about Joss and this whole open journal of open source computing and scientific computing. I think what you guys are doing there is really wonderful, and I think it'll open up some possibilities and opportunities to a lot of listeners that maybe they weren't aware of. Great. Yeah. I mean, it's a fun project, and so it's always fun to talk about it with new people. Should be great. But before we get to it, let's start with your story. How do you get into programming?
Yeah. So I'm definitely not a professionally trained programmer. Let's put it that way. So I have a background in chemistry as an undergraduate, and then actually I have a PhD in astrochemistry, which is kind of like doing chemistry with big telescopes, so looking at gas and dust in space. You're one of these people that can look at stuff like 25 light years away or something, and go, oh, that probably has this element in the atmosphere. Yeah. Yeah.
Yeah. Basically, and basically I went to astrochemistry. I did a PhD, in fact, actually, because I really just didn't know what else to do, which sounds like an awful idea, but it's how it happened. And I also wasn't that interested in chemistry, so I decided to go towards astrochemistry, where you don't actually have to be that good at chemistry, it turns out, because most astronomers don't know anything about chemistry, so you can be quite successful with a little bit.
I absolutely love chemistry, but I'm scared of doing chemistry. Like when I pick up, say, benzene or something, and they're like, oh, yeah, that's carcinogenic. And if it gets on your skin, it'll soak through, so don't do that. I know. Yeah. This really freaks me out to do this stuff, even though it's cool. Yeah. So I had a lot of time in the lab as an undergraduate, and actually, it means I'm really averse to precision anything now. So precision baking, in fact, baking, which is really just
chemistry, I hate it, and it drives my wife crazy. I just don't like measuring anything. She's a very good cook and just won't ever have me in the kitchen, because I'm so averse to anything precise involving ingredients now. And I blame my undergraduate. Yeah. Yeah. So, yeah, sorry. So I did some Fortran programming. That was my first exposure to programming, was as an undergraduate Fortran, which is very popular in chemistry still, computational chemistry
especially, because it's got a lot of very fast kind of numerical routines. If you need to work out how an electron is interacting with another electron, you need fast maths to do that. And then during my PhD, like lots of people, I had to do some data analysis and had reasonable amount of data to process. So started with scripting languages. So first kind of language I really picked up was Perl. And that was really, you know, that was because that was what was on the shelf in
the office. And this would be like 2002 or something. So, you know, that was probably a reasonable choice then, I guess. And so, you know, mixture of sort of Perl, some C, some Fortran. And then I went to this live course run by the library, by what was called information services, which is library science, and did a web programming, as it was called course, and learned about HTML and stuff. And that thought that
was really exciting. And learned about iframes and then came back to my office and said, hey, iframes are really cool. They were like, never use iframes. I was like, really? Oh, they're so awesome. They seem amazing. Yeah, they seem amazing. And so then I started to pick up just had a very slightest kind of touch of PHP. But actually, that was at a time when this framework Ruby on Rails was actually sort of a sort of beta phase,
I guess, 2004 or five. And a friend of mine who was, who was actually a legitimately very talented programmer, I think, and, you know, coded since he was a kid, was like, oh, you should totally look at this Rails thing if you're interested in sort of web application development. Put down the PHP.
Yeah, yeah, yeah, for sure. So actually, you know, so I started using Rails, which at the time, I didn't really even know I was sort of using Ruby, I guess, and then had a few years just kind of building, toying around with stuff, and then read this book called Ruby for Rails, written by a guy called David Black, who's big in the kind of in the Ruby community. He's famously sort of, you know,
was on IRC when David Heinmeier-Hansen was learning Ruby and building Rails and stuff. And, and, and it's really just kind of explains how this sort of framework you're using is, is, is, is actually just Ruby syntax. And it's just a, you know, DSL. And that was really enlightening for me. And actually, that meant that by the end of my PhD, I realized I was much more interested in programming than I was any of the science I was doing. I took that as a strong signal I should get
out of academia. Yeah, I received the same signal, by the way. Yeah, well, it's just, you just start to realize that some people read the literature a lot more than you and just know more. And I was like, how do you know about that result? And they're like, well, I read papers. I'm like, huh, I'm not really doing that very much. And that seems like a bad sign.
But I was writing, reading a lot of programming books. So I just sort of gracefully exited with my PhD at the end of my studies and, and actually went and had a year working in bioinformatics, which is where Ruby is very big as well. So actually knowing Ruby there was actually kind of a big deal. That's kind of the go to scripting language for, for bioinformatics, certainly in the mid 2000s.
I think, you know, that, that sounds really interesting. And I think what you're doing today is actually, you know, I'm just so excited to be able to talk to you a little bit later at the end of the show about it. So tell people where you've gotten to today. Yeah. So today I work at a place called Space Telescope Science Institute, which is in Baltimore, on the US East Coast. And it, we run, we were actually set up to fly and operate the Hubble
Space Telescope. So that was something like 30 years ago that the Institute was created. And we're actually a nonprofit government contractor. So we get, you know, NASA still pays us to operate Hubble. And we're currently developing all the sort of ground systems, data management systems for the James Webb Space Telescope, which is the kind of next big flagship mission for NASA. And so we have a lot of, we do, we build a lot of kind of core infrastructure for data processing,
which is a lot of the work that I oversee here. We call it data management. And we also build a lot of community tools, which are all pretty much exclusively these days built on the sort of scientific Python. So position being in charge of lots of time and effort that we spend on scientific Python, but full disclosure, I have never written a single line of Python in my life. So that's kind of
interesting for me. But I know a reasonable amount about open source and that kind of stuff. So I feel qualified, but it's interesting that sometimes I write pseudocode, and I'm pretty sure it would never compile. In fact, I've been told as much. So, you know, yes, I'm not a Python expert by any stretch, although I should probably learn sometimes. Yeah, I think it's really interesting how Python is really becoming highly used in this open source
science space. And it seems to really be something adopted by the various telescopes, right? That was like a big theme at the conference last year. I think at PyCon last year, a guy called Jake Vanderplass gave a keynote. Yeah. Yeah, he gave a great keynote. Yeah. And it was something like the unreasonable effectiveness of Python for science or something.
It was it was kind of a fun title. And yeah, he just really sketched out what I would say now, which is just there's just this really deep set of libraries that you can use in sort of numerical scientific computing in Python. And then, of course, you can do things if you need to have C bindings or whatever you can do that, too. And so there's just really just about it goes very deep. And and really now there's just this sort of overwhelming quantity of of kind of core libraries out there.
So that then things like we have a we have a project where we have a lot of core contributors for a thing called AstroPy, which is a very popular library in astronomy and astrophysics. And, you know, that builds upon SciPy and NumPy and obviously Python and, you know, and so it's really, you know, where we're contributing to that ecosystem. We had people here a few years ago who were very active
on things like Matplotlib, that kind of thing. And so, you know, there's pretty the Institute's actual credentials in the sort of Python community pretty deep, actually. People like Perry Greenfield, who's still here, was really one of the key people that actually introduced the astronomical community to Python, you know, and that that, you know, it's kind of interesting to reflect on the fact that sometimes big changes come from just one or two people just deciding that they're going to
make a change. Right from the ground up. Yeah. Yeah. And so I feel very lucky that, you know, I can go and he's like four doors down from me. I can go and just ask him questions about, hey, why? Why is it this way? And he's like, let's talk about that. You know, he's got so much context. It's fantastic. That's probably a good segue to just talking about the journal that you're the chief editor for the journal of open source software, Joss.
That's right. Yeah. Yeah. So Joss is a, well, I'll give you the one line description. I'd like to call it a developer friendly journal, which and so we should probably talk more about what that what I mean by that. But Joss is a journal that tries to do all the right things in terms of being a legitimate academic journal. And it's surprising how the establishment, I would say at some level makes
that look very hard and very complex. And it's actually really not. You have to do some of the right things like register with the Library of Congress and get an ISBN number and things like that. I mean, there's weird stuff that you just genuinely wouldn't know. But it's not like it's like five things you need to do not 50. And we publish papers about open source software with a scientific goal, whether software is science or research focused, I should say. And so generally, that means
academics who are writing software submit to us. And there's a couple of things that are kind of important about it. One is we, we review, primarily for the quality of the software submission. So we're actually not doing a big review of a paper. The does need to be a paper, it's generally very short. In fact, we encourage it to be short. So just papers are generally less than two sides, a four or US letter,
however, you printed it out, they're really genuinely short. And they are submission format is marked down. And, and, and bid text that we use pandoc to compile the things. And the kind of submission and review, and kind of hold whole editorial process happens on GitHub, in public repository, so a lot in a public reviews repository. So it's kind of a, yeah, it's, it's sort of interesting and weird in some of the
things we do. But at the end, we sort of try and do all the right things in terms of we give a DOI, which is a kind of a weird URL shortener that academics use that mean that you can index, sort of citations to other work.
Right. One of the issues that runs around that comes up around that is, if I wrote, say, a paper published in a high end journal, and it references some package I depend upon that generated my results, the owner of that package could just be having a bad day and just go, I'm deleting this GitHub repo, and it's gone, right? And so this DOI is sort of a, almost like code in escrow type of thing, right?
Yeah, so we, there's sort of, there's actually two DOIs that get created when a JOS paper comes into, well, gets published. We make an archive of the software, or actually we request that the author makes an archive of the software. So there's, there's, there's tools, like a tool called Figshare, and there's another one called Zenodo that is run by the CERN, people at CERN, so people who do sort of the computing infrastructure
for the large Hadron Collider. And what they do is they, you, they actually set up a webhook. If you do this from a GitHub repository, they, you know, they, you basically configure this add-on. And when you do a release on GitHub, it makes an archive, it takes a snapshot of that code. And it actually doesn't include the Git history, which weirdly maybe you would want, you know, actually legitimately you might want,
but it, it takes it like a table from GitHub, archives it and gives it a DOI. So the DOI points to Zenodo then, but Zenodo then also has a copy of the code. So if yes, you or I decided to, you know, rage quit open source or something, or just get really burnt out, actually, that's not rage quitting at all. That's just
legitimately decided to disappear off the planet. We, we, the code is still available. So when, when you submit to JOS the last one of the last steps is when the review is complete and the changes have been requested and made to the satisfaction of the reviewer, then they take an arc, we ask the author to make an archive of
code. And then the paper also gets a DOI. So, so then when people cite, want to cite that package, we encourage them to cite the paper and then the paper connects to the archive of the code, if that makes sense. So there's sort of some guarantee that in the future, if you stumbled across this paper, then you should be able to still find the source code, even if it's not on GitHub or GitHub doesn't exist or
something. Right, right, right. You know, I think it's, there's a lot of stuff happening around there and I don't want to go too deep down the hole of, of that, but even if you have the source code, that doesn't necessarily mean it's saved for all, all time. Right. So maybe it runs on a certain flavor of Linux that has a certain version of some internal bits that it works on. And if that is gone, right,
there's like, there's layers outside just the software. There's the versions of Python, if it were based on Python, right, there's, there's whole layers of this and, you know, things like containers, like Docker and whatnot, are like interesting players in the space as well. Yeah. Yeah, for sure. And I think there's definitely more we could do there. One of the things that's come out of the work we've done on Joss is that we've got a sort of fairly generic
tool set of tooling now. So we've got a sort of a fairly lightweight web application that allows people to submit something for review. And then we've got an automated bot that's called Weeden. Some of us are Firefly fans, I guess, Joss Weeden. It is the Weeden handle on GitHub, which is kind of fun. And so that bot actually helps with a lot of the editorial management. So a lot of that is sort of chat ops kind of automated in GitHub issues.
And so that tool chain can actually be applied to other things. So one of the things that's coming up is that Joss has actually been forked to make a sort of sister journal called Journal of Open Source Education or Jose. And that's actually using exactly the same tool chain. It's literally just a fork,
the code base. And so we've generalized that. So you could imagine we definitely talked about containers as something that actually are interesting to think about reviewing and saving and having those as actually there's been the idea of the sort of Journal of Open Source Containers as a journal.
I'm not sure exactly what I think about that yet, because I actually think to your point, it might even just be better to say, well, if you've got a Joss submission, really, what we want you to do is have a supporting kind of infrastructure piece like container to make sure that that software has some chance of running in the future, some increased longevity. But we haven't, we haven't gone that far yet. But it's definitely interesting.
It's very interesting. I think it also may, it may put extra pressure and friction, though, on getting submissions. Sure. Yeah, I mean, we're definitely not short on submissions. We've been going for a little under two years now. And we're up to close to 300 submissions. That's awesome. Yeah, it's great. And it keeps me busy. And the editorial team, we've got a great team of editors. So part of me thinks, huh, if we could slightly reduce the number of submissions, that'd be kind
of cool. Let me help my Friday evenings. But no, no, you're absolutely right. It's not, we don't want to raise the bar too high. We feel like we've got a pretty good kind of quality bar right now. You know, it says it in the name, you have to use an open source license, not one that you've made up, you know, one that's approved by the OSI. An official one. Yeah, yeah. You pick one of these 300, it turns out, or whatever. But there are lots, but you
know, pick one. And then we, our review is primarily, you know, about the sort of usability of the software. We encourage people to have tests, ideally automated tests. Documentation is a must. Some, you know, we sort of have, you know, acceptable, better, best kind of categories.
And, you know, one of the reasons we set up JOS was to, that we felt like a lot of the software that's in the sort of academic literature, when people write software papers, which is a thing outside of JOS, like you write a paper about software to get some sort of career credit as an academic, give people something to cite. Nobody ever looked at the software. The review
was always about the paper and never about the software. So we've turned it on its head. Most of our review is about the software and not about the paper. Yeah, I think that's right. I think that's the right way to do it. And you, like you said at the beginning, the actual submission, what's your guidelines for the thing you accept is really simple. It's like an abstract and basically supporting materials and links to the software. Absolutely.
So maybe, maybe it's worth talking about briefly. Like, why does this exist? Because you mentioned there was these other software oriented journals. There's pick an industry. There's 50 journals in that industry. They're usually like expensive. You got to buy them. They're private. They go out to like university libraries and professors and stuff like that. For me, the number one motivation for JOS is to find a way to credit people in academic settings,
or in fact, research settings. The difference, I don't know whether it's interesting, you know, academic research being sort of public, not for profit. And, you know, commercial research is a more sort of general, you know, could include commercial activity, I guess. So people who are in a research setting, who are writing software as part of their job, who are struggling to get career credit for
that. And that turns out to encompass a lot of people that I know. I guess technically, it probably would have been me at one point, except I don't actually, I personally wasn't ever trying to sort of follow an academic career track, which resulted, you know, relied upon papers and that kind of thing. Right. But this is basically the currency of professorships and tenure track positions, right? Yeah, yeah. So the way that you get a job as an academic is you write papers, and then people cite
your work. And, you know, if you write enough papers, and you get enough citations, and then at some point, a group of people in a room, they're generally called like a tenure committee, tenure review committee will decide that you're, you can have a permanent job in academia. And that's like the golden ticket tenure.
And, and the sort of the problem with that is that it's primarily and in many universities, exclusively based on papers, it does not take into account whether you give really good public talks, which lots of universities would say is a good, like outreach is important, or it would not take into account the fact that you spent three years collecting a really valuable data set that lots of people have used, like data sets generally aren't credit worthy. Like the only thing we have, we have
this one dimensional kind of credit model, which is papers and citations. And, and so the problem is, if you write really high quality software for a research setting, you might spend a significant fraction of your time doing that. And if you spend so much time that you, your number of papers suffers, then you're going to get dinged on that in terms of your career prospects. And so software papers, so a paper that describes a piece of software is a sort of understood hack on the current academic
system, except that software papers come with a bunch of problems. And Josh tries to address a few of those one is one of which is, you know, if you want to write a paper about a piece of software, you generally have to have sort of supporting new research results, right? That's the hardest part. I think like it's incredibly tough. It's not enough to say I've built the most efficient, most awesome AI
framework for discovering exoplanets, you have to go and find exoplanets. And then you do coincidentally, you get to talk about how you did it. Yeah, it just happens. I have this repository over here, which happens to be on GitHub with a license, and you might want to use it, you know, like, it's like a byline of the paper. So I have a problem with that. And I think it especially is bad for long lived, so arguably like successful software,
right? Like, if there were only ever one release of a piece of software, you could say, okay, well, you know, you probably built it when trying to do some research. So you should write a paper that describes the software and some research results, the end. Okay, but if what happens on version two, like if you and I decide to work on a piece of software that you did version one, that you probably
don't want to write another paper, because now people might cite the other paper. And now you don't get academics worry about citation dilution, it sounds like such a ridiculous thing, but it's real, like, and because it turns into this number called an H index, which is just, well, is a way of trying to parameterize capture the sort of impact of a researcher. So yeah, so I have,
so Joss papers are, you know, the idea is that no results are actually permitted. It's not that we don't need results, you're not allowed to put novel results in the paper, because we're not going to review that, like we, that's not what the reviewers are there to do. So that's really sort of why we call it developer friendly, like the idea being, if you have done the hard work to write this piece of
software, we don't want you to spend more than roughly an hour writing the paper to go with it. And that turns out to be, you know, appealing to quite a lot of people. Yeah, that's really awesome. And so people can, who have worked in any research area, like you said, not just academics, if they want credit for the software that they have created, in terms of academic credit, right? Yeah, the special coins you get at the university, when you get cited, right? That type of currency.
Yeah. So so actually, to that point, you know, we do get I was actually looking through some submissions earlier today, we do have mixtures of people submitting, you know, most most of our authors are in an academic setting. So either in some kind of research institute, but where papers legitimately count towards their sort of career progressions. But we do have people in commercial companies as well, especially in the sort of data science
ecosystem. I was looking today, and there was a paper, it was a scikit-learn contript package. I think it was the HDB scan, some new, you know, implementation of a of a of an algorithm. And it was somebody at a university and somebody from Spotify, I think, or, or no, Shopify,
actually, yeah, very similar. But you know, but it was clearly looked like it was a data scientist and at a company who maybe doesn't care about that credit, but also maybe was a university in a university setting at some point, I think, especially in data science, I feel like there are many people who go and
sort of go a long way in the academic space, and then they go into commercial data science. And I feel there's this interesting tension and trade off in the whole data science space in that the demand for data scientists so strongly in motivates or pulls people out of academics as they're like, we'll pay you half a million dollars. Forget tenure, you can just, you know, you can do this, right? Yeah, yeah.
But there's there's still that that tie back to like, I work with this professor or this group, and I'm still kind of helping them and they give me good ideas. And so I feel like maybe a lot of the papers come from that sort of remaining ties. Yeah, groups have Yeah, some definitely do. I don't think I have a good handle on how many. But the I think, even if you've left academia, I think there's still, you know, the conventional way to share your ideas is in the literature, publishing,
papers. And so I think it's very natural for people to want to, to write a paper. And then, you know, if we're like, well, here's a super short way of getting a paper. Exactly. Well, especially if you've done the work, and we'll get to some of the details in a little bit. But I feel like what you've done is you've come up with this concept of how you submit your stuff to the journal, your software, and it pretty much just checks the box of here's how you run a good open source
project. Yeah, it has a good open source license, it has documentation, it has tests, tests, it's hosted in somewhere like GitHub, etc, etc, right? Yeah, so when I was working at GitHub, I really learned a lot about how, you know, successful projects come sort of into existence. And what are some of the sort of key things that you need. And so
really, you know, there's, there's a lot of there's a lot of material out there now. But certainly, four and a half years ago, this sort of idea of sort of what healthy, open source looked like, or what a successful project looked like wasn't, like wasn't written down that much. And so the team I was in GitHub was sort of trying to create some of that sort of shared understanding in the community. And actually, while I was there, I was thinking about journals, and had already been
talking to some other commercial publishers, just who were asking me about GitHub. So I sort of helping them understand open source, but I was representing the company. And, and, and then towards the sort of in my final year, the company, I just sort of figured, you know what, I like none of the conversations I've had have been very satisfying. They're not getting it, like they're not, like they're, they're doing
kind of the wrong thing. And I realized, I just started hacking on some code. I was like, you know, I think I could do this. And I think it'd be super easy. And if you assume that the review could happen in an issue, and, you know, submission is just creating an issue. And like, I realized, I mean, we have a strong GitHub dependency via the API. But I just realized that I think thought I kind of knew enough to do it better myself. So then so then just decided to go for it.
This portion of Talk Python To Me is brought to you by ActiveState. ActiveState gives you a faster way to build and secure open source runtimes from your first line of code through to production. Every second you spend building your Python distro or trying to secure your Python programs is time away from doing the work you love. Tired of resolving dependencies or making sure you tick off all the
security boxes when you ship to production? With ActiveState, you can focus on your code and leave the open source to them. Your teams can standardize with their Python builds for your specific use. You'll have less friction in the development cycle. And that means you can deliver apps faster. If you need to manage your apps in production, they even give you a unique server side way to verify your Python
applications at runtime. You can bake security right into your Python products without impacting performance. Cut the hours wasted building your distro, finding the right package, or making sure you tick off all the security boxes when you ship to production. Go faster, spend more time doing the work you love, and comply with your enterprise needs for security. Try them and see why their distribution was chosen
by IBM, Microsoft, NASA, Siemens, PepsiCo, and others. Join millions of developers who trust ActiveState to build their open source language distros. Visit talkpython.fm/ActiveState and cut the time configuring and securing your Python builds. That's talkpython.fm/ActiveState. Let's talk a little bit about just the whole process. Actually, let's touch first on the kinds of projects that come up here. So people are listening. They're like, well, I've done some
stuff. It's kind of research. It's a project. Would it fit? So let me just read the quick description of a couple recent things you guys accepted. So one is NIA Pi, N-I-A-Pi, and it's a new micro framework for building and using nature-inspired algorithms in Python. So that's pretty cool. There's one Pi Newcastro, which is Python interfaces for nuclear reaction rate databases, including J-I-N-A stuff. There's a bunch of these. They're not super large scale. They seem a lot of
them are like, I need to get to this data or I need to do this calculation and nothing quite works. So here's the bridge that I had to build for myself a lot of times. Yeah. So we get, I mean, there's a few different categories of software that we get. Actually, there's a bunch. I mean, those two, I'm pretty sure I didn't edit either of those. Because, you know, one of the problems we have is, you know, we get submissions. I'm like, I have no idea.
I don't even, like we asked them to write, we asked the authors to submit a general audience, for a generalist audience, a summary of their software. And I read them, I'm like, I have no idea what this software does. I literally do not understand any of these sentences. Thankfully, we've got like, I think 16 editors now and somebody will be like, oh yeah, I know this stuff. Oh, I know enough that I can help edit this. And then we have a pretty good reviewer pool now.
It's, I think, well over 200 people who volunteered to review for the journal. And so we just have their sort of language expertise and their subject expertise and their GitHub handles. So we just ping them when the submission is made. I think that works really well. And you do have a real rockstar cast of supporting editors. I mean, you look through there and there's, there's a bunch of big names, including Jake Vanderplass. Yep.
Catherine Huff, who does a bunch of the nuclear stuff. Maybe she probably reviewed that one that I just shot at. Yeah. Yeah. And the reason I learned about you guys is I actually was one of the reviewers on a thing called Batman. Ah. Statistical analysis for expensive computer codes made easy. Fantastic. I thought I recognized your face. There you go. Yeah. Yeah. Yeah. See? I didn't make that connection. It's from my GitHub. Yeah. Yeah. That's awesome. Thank you for your time. Yeah. Absolutely.
Absolutely. So one of the things I thought might be fun, and I think one of the reasons I wanted to feature this is sort of twofold. One, if you're working in an area of either research, you're a grad student or even undergrad, and you've got some kind of interesting open source software thing, that would be a good thing to submit. That would be great. But there are many people who ask me like, hey, I'm really just getting started.
I want to contribute to open source. But you can't just drop in on Django and just start adding to Django because it's like an eight-year-old, highly polished, maybe not exactly, but not new greenfield stuff. It's like very sensitive to change, and it's very nuanced. Whereas I think becoming a reviewer, for example, might be a really nice way to start to be part of open source if you're like a student or something. For sure.
And you're trying to get it on your resume for when you get out of school or whatever. Yeah, I mean, one of the things that I think this is true, I only have anecdotal evidence, but I'm going to believe it because it supports what I want to believe, which is that people seem to genuinely enjoy both the review process and being reviewed. But authors and reviewers seem to just, we could do probably a sentiment analysis of all the comments or something because they're all public.
But, you know, we get people who say, I say, you know, would you mind reviewing this? I'd love to. I'm like, really? Okay. I mean, I've had people email me and say, why haven't you given me anything to review yet? I'm like, I don't know. And I'm just kind of, your name hasn't come up yet. And I do worry that sometimes I go to people I know who would be good for this. So I actually, one of the things I'd like to automate is reviewer suggestions. We have this big list. It's in the spreadsheet.
I feel like it's something that our bot could do. But yeah, maybe you could have tags and like, these are their specialties. Yeah, exactly. Exactly. And, and, and it would also keep track of how many reviews you've done because one sort of over taxing people is one of the things you worry
about. This person's good. Yeah. Yeah, yeah, exactly. So, so, but yeah, for sure. People seem to, you know, a number of times where reviewers are like, this was a really good experience because I learned about this package and all that all really we want people to do as a reviewer is try and install it and run it and verify it. Right. So that involves reading the docs, looking at the code. Ideally, you know, if you find that there's methods that are uncommented, quite often reviewers will
actually make pull requests against the thing they're reviewing, which is kind of nice. And just there's this, you know, everyone gets the idea that what we're trying to do is create a, you know, highly usable piece of software, you know, that solves, solves a real problem. So yeah, I think actually that's a great suggestion for people who are looking to, you know, dip their toe, you know, take first steps
in open source. Joss is actually a great place to come and just read, read people's, you know, code. Often, as you say, these are pretty small packages and, you know, and actually maybe even become a contributor. Yeah, that's a great idea. Absolutely. A lot of people who are getting it, open source, some of their first steps into any particular project is to help with documentation or tutorials or examples. And this, this review process is similar to that.
It is. Yeah. And, you know, we, we, we have a fairly prescriptive process, so we don't kind of leave people with just, what do you think about this piece of software? It's like, there's like 20 checkboxes that we ask people to. Yeah. Does it have an open source license? Yes or no? Yes. Does it have tests? Yes or no? It's almost like a little checkbox. I think there are actual checkboxes in there. There are. There are. Yeah, yeah, yeah. Yeah, absolutely. Absolutely. So we
checkbox driven development or something. Nice. Yeah. So I recommend to people out there, if this sounds super interesting, if maybe you're still in college or grad school and you're like, I want to sort of, you know, start to build a resume around this kind of stuff, you know, becoming a reviewer would be real easy. And people who are, especially in school, they already have some specialty so they can help in that area. Yeah, yeah, for sure. Nice. And so Joss is actually one of four journals
under a larger banner called just Open Journals at OJ.org, right? Yeah, that's correct. Tell us briefly about the others. Yeah. So, so the first, I think the first one I set up is this one called the Open Journal of Astrophysics. and that's my least successful. So I guess I was so stepping back, it, it, it would appear based on the evidence I create journals in my spare time, which is a horrible thing to do if you want to have any spare time, in the future. So yeah,
so this is like my problem in life that I seem to make academic journals. and it, and it, it, it's a big time sink. so the Open Journal of Astrophysics was the first. we actually published three papers. It's kind of currently paused right now, mostly because we don't really have a particularly strong or, well, no, we have a strong, but not very engaged editorial board.
And the important thing to realize about a journal is it kind of lives and dies by the ability and willingness of the editors to do, you know, and the reviewers to come together and review content. So, you know, the Open Journal of Astrophysics kind of, and a bit of a hiatus right now. I don't know what will happen with that project. it's a nice, it's a nice project.
in the sense that we, the model is to review papers that are already on the archive, which is a preprint server where people put kind of free and open copies of papers that they're going to submit to other journals. So the idea being that you could just do a sort of review, in a browser. and the, there's this, there's lots of other journals now following this model. They call them archive overlay journals. and so, I'm sorry, we didn't, weren't more successful with that, but you know,
such as life. the second is, the journal of brief ideas. I built that with a guy called David Harris, who's a physicist, in Australia. And he just has this problem. He just really wanted to find a way to capture, short ideas, good or bad. and have a way for people to just write them down and say, you know, here's an idea. I'm not going to take it further or I don't have time right now. And so it's more like a sort of diary of thoughts from the community. and it could be
like the seed of potential research projects, but I'm not going to pursue it. That type of thing. Right. And, and, you know, why that exists is kind of interesting. You know, academics live or die at some level by the quality of their ideas and the novelty of their ideas, which is good and bad. so academics, it turns out care a lot about, you know, who had the idea first. And I really feel like that's one thing reflecting on time and sort of industry, something that I find engineering cultures
care much less about. You're like, we care about building a good system, something reliable. I don't care whose idea this was. This is just a good idea. Whereas academics are very keen, very careful to award, you know, Oh, it was this person, you know, Mike's idea first. And then I took it forward, but he had the original, you know, you hear them a lot. It's very careful. It's the citations. It's the papers. And these are all driven by
the first paper. It's the citations on every subsequent paper and all that. Right. So journal brief ideas as a way for people to say, I've got an idea. It could be good. It could be bad. I want to write it down because I want to, I guess, put it, I mean, you know, like put a stake in the ground. A little bit of a flag on this idea. If I ever come back to it. It's kind of fun. And people, people do use it. And I don't edit that. It's David is the sole editor. It doesn't go
through review. So they're limited to 200 words, these ideas. So really short. So you can have 200 words and a figure like, you know, and that's it. And then, and then Joss is the third journal that I've created. And that's by far the most successful. It's at some level, sort of one of the things that I did when building Joss was I really wanted to absolutely minimize the amount of new software I
wrote. One of the hard things about Open Journal of Astrophysics is there was quite a complex sort of web-based UI with PDF annotations and like lots of bits of technology that I wasn't particularly well versed in. And so Joss is super simple. It's like a web form that leverages the GitHub API to open an issue. And that's it. Like literally that's it. And it's got a very small database behind it so that
it can render out the accepted papers. And then Journal of Open Source Education is, is ready to go. In fact, I think they're very close to accepting submissions. And that, that's not a journal that I'm going to be day to day involved in, in running, but it's part of the sort of family of journals. So really the two that are most similar are Joss and Jose, they are, you know, very, very similar journals and using the same rating model. Yeah, those are really cool. I like it.
This portion of Talk Python To Me has been brought to you by Rollbar. One of the frustrating things about being a developer is dealing with errors, relying on users to report errors, digging through log files, trying to debug issues, or getting millions of alerts, just flooding your inbox and ruining your day. With Rollbar's full stack error monitoring, you get the context, insight and control you need to find and
fix bugs faster. Adding Rollbar to your Python app is as easy as pip install Rollbar. You can start tracking production errors and deployments in eight minutes or less. Are you considering self hosting tools for security or compliance reasons? Then you should really check out Rollbar's compliance SaaS option. Get advanced security features and meet compliance without the hassle of self hosting,
including HIPAA, ISO 27001, Privacy Shield and more. They'd love to give you a demo. Give Rollbar a try today. Go to talkpython.fm/Rollbar and check them out. So let's just talk real briefly about compare and contrast. Most of these articles are written and published in high end, very private, cloistered sort of journals, right? Like JAMA for Journal of American Medical Association or JRME for education. And you can't just like
easily go get them. The papers are often not available on the internet. they're really packaged away just for a few folks to get to, which I think is very odd because so much of the research is paid for by National Science Foundation or National Institute of Health or whatever. So we basically, the public pays for this research and then the results of it are hidden away from public view. Right. Yes. So yeah, like this is very much not like what you guys are doing.
No, I mean, everything you said is true. I think, you know, there's a growing interest in what's generally termed open access publishing, which is not, you know, so stuff once it's accepted and is in the journal is available for all to read. But right now, a lot of the business models of academic publishing
either rely on journal subscriptions. So when your library or you as an individual buy access to these papers, and that's generally, you know, a journal subscription and that can run to, you know, enormous amounts of money, you know, single universities paying millions of dollars a year to publishers, just to gain access to hilariously or disgracefully the papers that their academics have written. So, you know, like, yeah, exactly messed up actually.
and you, you, you as an academic secure public funding often for research, you then do the research, you give your copyright to your research, to the journal that then puts it behind a paywall and sells it back to your university and to the public. So, you know, there's a lot wrong with that. To be fair, the journals would say, well, we add a lot of value. We bring peer review to the process. we, you know, make the papers, we format them nicely. We, we, we, we, you know, we, we run,
we maintain quality at some level and much of that is true. but the cost is still pretty high. And I think there's a lot of interest in low cost publishing these days. And that not doesn't mean low quality. It just means how low can that cost go at some level. And so just our running costs, if you ignore people time, which I'm going to, because we're all volunteers, we're something
around $4 per paper, to in sort of production costs. And that's actually most of that cost is, um, you know, a small web server for running, the app, the web app and the fact that there are actual, we have to pay, subscription fees to get the DOIs. So it costs us about a dollar 50 for each DOI. And we have to pay a membership fee to this organization called cross ref to, to have sort of, to be able to continue to generate those, those DOIs.
Right. That dramatically changes the structure. And, you know, I know that on the academic journals, it's often professors who are not paid by the journal in any way or form asked to volunteer for in the same role as the reviewers are here. So it's not like they're paying huge sums to the reviewers. No, no, no, no, no, no. I mean, that's, yeah, yeah. It's crazy. Yeah. So I,
you know, I'm not, yeah, there's so much to say about publishing. and, and, you know, one thing that's kind of interesting is that peer review, which we see as this, you know, pinnacle of quality and as a process, it's actually pretty new. Peer reviews only existed for 50 years, just full stop. Like most journalists just didn't have it. and like famously people like Einstein would write to the editor and they tend to let her saying, Oh, you know, here's my new theory of
special relativity. And there is nobody qualified in the world to review this. So you must publish it right now. And they'd be like, yeah, okay. You know, you're, I think you're right. Seems legit, but like you just didn't get a review. It just got published. And so peer review is, you know, um, is important. but generally, as you say, you know, people aren't paid for it. I think almost exclusively people aren't paid for it. And so, it's part of your sort of contribution
to the academic ecosystem, yeah, it's part of your job as an academic to review. And that's understood. We have the same model. We have people to review, we don't pay them. and I don't think we have any interest in paying people to review. That would be weird, given that we have no money anyway. So, but, but, but we, what we do have, I would say is I think we, by being open, our reviews being open, a lot of peer review in academic journals is, is closed. You
don't know who's reviewing your work as anonymized. I feel like that openness incentivizes good behavior, and actually quality. we get, you know, somebody, I hope that one day somebody will be able to say, I am a Josh reviewer. I've reviewed 20 submissions. Here are my submissions. And you can go and look at those and be like, this person does really nice reviews. This is actually
really high quality, good insights from this person. And, you know, there is some work already going on in sort of publishing to make, reviews a sort of a credit worthy activity. I mean, people write it on their resumes. They'll say, I review for, you know, app J or something, but, but you can't actually prove that like, unless you're, unless you're the editor and you're like,
no, you don't review for me. Like you would never know. so yeah, no, I think there's some, a lot to be said for sort of being open and there's a lot to be said for sort of innovating with, cost models, and pricing models. And so, yeah, we don't charge anything to submit
to JOS. I don't think we have any interest in charging authors. We do, you know, you know, we, we do have some ideas about how the review that we do could be valuable in other academic settings, like for other journals who want to get software review, but with that's just early phase stages of conversation right now, but it's interesting. Yeah. Yeah. It's, it's really, really neat. I feel like Josh is open source and, you know,
2018 or 2016 business on the internet meets old, old business model. You know, it's just like, wait, these, why, why is it done that way? Cause it doesn't seem like it needs to be done that way. So yeah, pretty fun. Right. Right. Yeah. So I do want to spend a little bit of time talking about other stuff. So maybe we'll leave it there for Josh. Okay. I just want to encourage people who've worked on open source projects to either submit them or sign up for review. Cause I think
that would be cool. So let's talk about the space telescope science Institute where you work. Right. So you've got two major new telescopes coming out that, that you mentioned at the top, right? The James Webb space telescope. And what's the other one called? I forgot. It's like the whole sky. Oh, so yeah. So I mean, Hubble has been running for 25 years. We operate that still. And then there's, um, W first, which is a wide field, infrared space telescope. In fact, that's what the acronym
stands for. is, is, a mission that's currently kind of having a little bit of a rocky stage in, Congress cause you know, budgets are weird. And, these projects span longer than election cycles, which is dangerous. Yeah. it's so interesting to see, like, I've never had a job where I've actually had to pay attention to politics daily. I now have that job. and it's interesting. it's, also not being American. It's kind of learning about learning about that world.
so wait, they could do that. Yeah. And so, you know, so, so currently very active, very, we're very active on JWST, James Webb space telescope, which is, is meant to fly, June ish, 2020. so these are, you know, the lifetime, you know, it takes a long time. It turns out to both convince the government to spend $9 billion, which is what JWST is going to cost. So that's a lot obviously, and then, and then you have to build it and, you know, there's lots of novel
technology that's just never been developed before. And, and it's, yeah, it's, they're complex and, you know, they take decades to build, it turns out. Yeah. So what's, what's the
primary, result expected from the James Webb one and then the wide field one? Yeah. So, I mean, JWST is, I think for me, the most exciting thing about JWST is, it's gonna, so it's an infrared space telescope, and infrared light is different in optical in the sense that it can kind of look further back in time because infrared light isn't obscured by dust in the galaxy and in the universe or isn't obscured as much. And so it allows us to look back further.
and so, look at the first light coming from the universe. So a period of time called reionization when the universe kind of, when the sort of, you know, first atoms and, were forming after the big bang. And so that's, you know, some hundreds of millions of years after the big bang, JWST is going to be able to see the first galaxies and the first stars forming. And that assembly of the very first, the very first galaxies, the stars, become sort of gravitationally bound.
And so that's, that's very exciting for lots of reasons, but, you know, understanding the earliest phases of the universe, another, another, kind of couple of big areas of, some science highlights there, the ability because of the infrared light to be able to not, be obscured as much because of dust. You can look deeper into places where stars and planets are being formed.
so what get called sort of generally protoplanetary environments. So pre before that, but when the stars are just even actually before sort of nuclear fission has started and the star hasn't actually turned on, you can probe those environments. So understanding how solar systems like ours form, is kind of a big theme, right? Cause it takes a while for that stuff to build up, to get enough gravitational force to actually light up a star, right? Yeah. It's formed for a long time.
Yeah. and then the, and then the sort of final kind of big highlight for JST is it's going to be the first telescope that really is going to be able to look at the atmospheres of planets outside our own solar system. So those are generally called exoplanets. so over the past, you know, five, 10 years, uh, the number of planets going around stars other than our sun has grown from like two to, you know,
thousands. And we now think that most stars have planets. and there's pretty good reasons to believe that most stars have rocky planets somewhat like earth, you know, not maybe the same mass, but, but have, you know, places that might have, atmosphere. So JST is going to be able to look at the light passing through the atmosphere of those planets and actually characterize that.
So you can look for things like methane and ozone. And, and so one of the things that is exciting about that is that you could look for exoplanets that have atmospheres that aren't in an equilibrium state, as in maybe have life. So that's kind of exciting. So we're really at this point where we're beginning to think about characterizing, you know, we've discovered all these exoplanets. Now we're going
to say, well, what are they like? And, and I mean, this is, yeah, this is kind of a pretty exciting time for everybody really. Yeah. And it sounds like it's right up your alley actually as well. So, what about the wide field infrared survey? Yeah. What is it up? So it's a little bit later. So James Webb is 2020. The W first is 2025. yes. Theoretically. Yes. Planned. Maybe 26 now. Well, we'll see. so, yeah, so, W first is a different, fundamentally a different
type of telescope. It's actually, about five years ago. the U S government sort of, somebody picked up a phone or emailed somebody at NASA and said, Hey, we've got a couple of spare space telescopes. Would you like one? And so this is the, I forget which agency is that builds all the U S spy telescopes, but they basically donated. They said, we have a, we have this telescope that's never flown. In fact, we've got two, but you probably don't need to. Do you want
this one? And, and it's kind of a bit like Hubble in that, in the sense it's about two and a half meter mirror. And, and the goal is to do an infrared again. So, longer wavelength, uh, optical light, I'd go and, do large scale survey of the sky. So one of the things about, um, building telescopes and space is that you can, you don't have an atmosphere to look through. And, that turns out to be a big deal because it means you get much better.
we astronomers call it seeing, but you get much better resolution. So the shape of the thing that you see is not blurred by the atmosphere that you're looking through. So, infrared, infrared space telescopes particularly are very exciting, especially when you're doing a large survey. So W first is a survey telescope, Hubble and Jada was here. What are generally called sort of, well, aren't survey telescopes. They're sort of a point and shoot. They fix on a point and
they'll stay there for maybe a long time to see farther into the past. Yeah. So W first is exciting because of the volume of data. So instead of, you know, Hubble over the last 30 years has produced something like a hundred terabytes of data. W first will produce about five petabytes, which is a not ridiculous amount of data, but it's enough to be interesting and like requires some thought. Yeah. I see a lot of interesting machine learning and image, AI type stuff being applied there.
Right. And so W first is gonna, has a number of key, science goals. again, like exoplanets features heavily there. especially, what's called, micro lensing. So when a, when a planet passes in front of a star, you get a slight increase in the brightness because of the, effect, the micro lensing of the planet, which is just sounds crazy,
but it's great. Yeah. But the spend in space time curves the light to come over and dark energy, which is this sort of not very well understood, what in fact pretty poorly understood, you know, fraction of component of, of the universe. So understand like in sort of cosmology terms, how, how the universe, kind of works. So it's, and it's, there's a, you need very large samples of the galaxy and looking at like supernova and like distances and how they go off and how they're
affected, over, I was a cosmological distances. And then you need to do lots of shape measurements of galaxies and it's, it's, but you need a big, you need a lot of them and you need very high precision data. And so W first fundamentally is a different type of, of telescope, but it's, yeah, it should be really interesting to see new, new science coming from this new type of telescope. Yeah. Yeah. Awesome. All right. Well, we could talk about space for hours actually, but I w I want to be
cognizant of your time. And, but one more thing that you worked on, I thought it's cool. Just give you a chance to tell the world about is Zooniverse. What's Zooniverse? Yeah. So Zooniverse is a, platform, a web-based platform for, citizen science, which is, so citizen science, is this idea where members of the public citizens of the world, can help, uh, solve real research problems. So, it basically is a platform that brings together
people with research problems, generally academic research problems. so generally sort of professional researchers have a problem where some, you know, they have some part of their analysis or some part of their, their research project requires a lot of, you know, human effort is probably the best way to think of it. So maybe classifying images by their type or, pictures of galaxies by their shape.
And so Zooniverse is a sort of a platform for bringing together the people who have the problems and members of the public who are interested in working on these problems. That's cool. So you can go and say, Hey, I'm interested in a project and maybe browse the existing projects and then you'll learn how to participate. That's right. So there's probably about, I'm guessing there's about 50 projects there listed today.
I haven't been day to day involved as Zooniverse for about, for about five years now. but I was, I guess, second hire on the project after they'd had this original success with a project called galaxy zoo, which was, taking a lot of images from a, from a telescope called the Sloan digital sky survey, and looking at galaxies and making a judgment about their shape, whether they had spiral arms, if they did, which way they were spinning, what, how many there were. and,
and, and, and that kind of thing. And it was very, there was like a one-off project that was very, very successful. They, secured some research funding to build out this, I guess, this approach to doing science with the public, and Zooniverse was born out of that. So, yeah, I mean, we did a whole bunch
of stuff. I mean, as I say, I don't know, I don't track it day to day these days, but we did crazy stuff like, you know, looked at, images from camera traps in the Serengeti, looking at, looking at, uh, pictures of animals, doing things like tracing, you know, particle paths in, particle physics data, looking for new physics, lots more looking at galaxies and gravitational lensing. It was really broad. Actually. It was really fun. Yeah. That sounds really fun. Actually.
I don't know if this was part of it, but I knew there was this protein folding challenge where they almost gamified that it's like that kind of stuff. Yeah, that's right. So that wasn't, that wasn't us, but it was, definitely similar idea. And so, you know, the idea being that there's just people are generally like, there's lots of people who are interested in science, but you know, just aren't doing that day to day and are interested in contributing. And, yeah. So there's a chance
to go help with some problem and you don't need a PhD and a grant to do it. Sure. And, and you know, some of the, some of the best projects are ones that just really, I think we didn't know at the start we're going to be successful, but I think probably still my favorite project is this one called old weather, which is, which is like probably the most boring title ever. It was pointed out to me once, but, so taking a log books from ships, from the Royal Navy, world war one,
where they recorded the weather. And so it turns out that six times a day, the Royal Navy, and actually lots of navies do now still, you know, they record, you know, the air pressure, the water temperature, the atmospheric conditions, cloud coverage, that kind of thing. and just write it down. And the handwriting is generally not very good. The way it's laid out on the page is complex. And so you can do OCR on it, and try and get a machine to read it, but you still need that sort
of context to then extract, extract the data. So we, but these log books are really cool. They've got, they've got basically stories about what's going on the ship. We made a website where people could transcribe them and people just got really into this and following, there was a guy, Lieutenant Dolphin. I remember cause his last name's Dolphin, like the starfish is at the mammal. and Dolphin kept getting thrown off ships for being drunk and disorderly getting reassigned. And they
found him over like 10 years on different Royal Navy ships. And there'd be a note from the captain saying that Dolphin's been, you know, relieved of command and sent to another ship. And just, but the, the, somebody got interested in, in this person and followed them. And then, you know, there was like, you know, there's, it turns out there was only like two major sea battles in the first world war, you know, battle of Jutland and the battle of the Falklands.
Turns out I know about this stuff now. That's the other thing. It was fun just doing lots of other people's research, but you know, in these log books, you're, you're watching the battle happen. It's saying, you know, spotted, you know, enemy battleship engaging, you know, collecting survivors or sinking and like, you know, all real world, like stuff happening. but so, but at the same time, these data that we're extracting get fed into these climate
models. So they do reconstructions of, climate, in, over historical times. Cause one of the challenges in sort of understanding climate change today is actually having a long enough baseline to build models that can actually make good predictions for the future. And so, right. Right. Right. Much of that's over a land, right? Right. Right. So, cause you have that, you could dig down into the ice or whatever, but the water washes that away, right? It's gone.
Exactly. So, this was a project we did with a bunch of meteorologists. and it was, yeah, so it was a lot of fun. And, and for me, it was mostly a technology problem, building that kind of infrastructure, but it was fun to like do lots of, or be involved in lots of people's research as well. All right, Arvon, I think probably we're going to have to leave it there. Maybe just a quick final call to action. People want to get involved with Joss or more generally all the stuff we've been
speaking about. People would like to help review or want to learn more than I think the URL will probably be in your show notes. but Joss, Joss.theoj.org. yeah, we'd love to, we'd love to have your help. It's been really good to chat with you and share what we're up to. Thanks for the opportunity. Absolutely. Thanks for sharing your story. It's, it's cool working and keep it up. Yeah. Thank you. All right. bye. Take care. This has been another episode of Talk Python To Me.
Today's guest was Arvon Smith, and this episode has been brought to you by ActiveState and Rollbar. ActiveState gives you a faster way to build and secure open source runtimes from your first line of code through to production. Check it out at talkpython.fm/active state. Rollbar takes the pain out of errors. They give you the context insight you need to quickly locate and fix errors that might have gone
unnoticed until your users complain, of course. As Talk Python To Me listeners track a ridiculous number of errors for free at rollbar.com slash talkpythontome. Want to level up your Python? If you're just getting started, try my Python jumpstart by building 10 apps or our brand new 100 days of code in Python. And if you're interested in more than one course, be sure to check out the everything bundle. It's like
a subscription that never expires. Be sure to subscribe to the show, open your favorite podcatcher and search for Python. We should be right at the top. You can also find the iTunes feed at /itunes, Google Play feed at /play and direct RSS feed at /rss on talkpython.fm. This is your host, Michael Kennedy. Thanks so much for listening. I really appreciate it. Now get out there and write some Python code. Thank you. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye.
Bye. Thank you. Thank you.