What is the threshold for a software paper to be publishable? I've been asked to referee a paper about a software tool. I'm struggling with whether this particular work is sufficient to warrant publication. The journal I'm reviewing for doesn't have a "notability/novelty" criterion, but they do require that the work be a "unit of publication."

Let's call the thing I'm reviewing "Feature." Feature is part of a larger package, let's call it "Package." Feature is a GUI tool that takes the data that has already been calculated by Package and plots it using a widely-used plotting backend. It has some nice stuff exposing options in the plotting backend as GUI elements, and a few options related to the nature of the plot being made (scatter plot vs. heatmap, basically, plus some toggles based on domain-specific labels in the data).

Here are some facts that are shaping my view:


There is essentially no scientific logic in Feature. It needs to be able to read the files, optionally multiply by a weight, and then it has a few stored toggles in the data to change which data is presented. But it's mainly a very simple GUI to analyze visualize data from Package.
The entirety of Feature is less than 1400 lines of code, with almost half being the GUI-specific.
Looking at the code, (especially non-GUI) I suspect that I could cut about 300-400 lines of code -- the developers aren't using scientific software tools available, including reimplementing a function that's in a library they include.
Currently, a paper about Package version X.0 is under peer review (X>1); cited in the manuscript I'm reviewing. All authors of the paper on Feature are also authors of the paper on Package.
The entire author list for Package is essentially one research group -- this isn't a giant community-wide effort. And the paper on Package version X-1 was published only 2 years ago, so I'm surprised they're trying to get two more software papers out already.


The last two especially annoy me, because I feel like the purpose of scientific software papers are to make scientific software development citable, not to pad your paper count. The authors will already be getting the citations based on the other paper.

On the other side, I came to this with some bias that one of the authors has a tendancy to care more about quantity than quality with publications. So I'm not sure if my leaning toward reject is partially based on that, or on the facts on the ground. (Hence the desire for other opinions.)

EDIT: I forgot to say that Feature is not yet merged into the main branch of Package, but it currently in a separate branch in the same git repository.
There is no bright line threshold for such things and the answer should be the same as for any scientific paper, hinging on questions of novelty and extension of knowledge. If it doesn't have that, then it probably isn't a good candidate, though the standards of different journals vary widely. 

But you seem to describe a small-if-any advance with little novelty and you also seem to have made up your mind. We can't help you with the judgement and you just need to take a risk and call it. Others may disagree with you, but that is always the case in reviewing. 

I don't really understand your point 5 and might disagree with your emphasis on it. Why is work done within a group less valuable that work that crosses institutional lines? Lots of papers are done by one or a few people within a research group. However, I might agree more if you mean all of their cited papers come from those same people. That isn't necessarily a red flag, but might be.