Why would you feel bad? The whole point of open source is they could have done it themselves, if they wanted some integration they needed and you didn't.
And then they could either contribute it back, fork your project or just keep it to themselves, if the license allows it. At any rate, you already helped them...
People often act very entitled about open source I've found.
You'll often get angry irate emails/issues raised demanding you help them or add a new feature or whatever. Some people are just clueless and need help, others are just dicks.
It is often not worth the hassle in my opinion, but then everyone's circumstances and motivations are different and I am glad that a lot of people do think it is worth it.
Some of the commenters in that issue have a very regressive and myopic stance. Raising such a public ruckus will heavily disincentivise scientists from publishing their code in the future. Decisions will still be made, but in the dark. There's a certain amount of self-stroking going on there with people feeling better by putting down code produced by non-professional programmers.
A much better response would be:
1. Scrutinise end users of the code: demand that governments only use this data if proper due dil has been carried out.
2. Submit code improvements.
3. (maybe) Demand that peer reviewers are more rigorous when checking the way results are generated. The issue with this is that this would also be a strong disincentive for scientist to publish their work.
While the tone of the covid model scrutiny leaves a lot to be desired it is understandable seeing as how the results are affecting the entire world. The situation is unprecedented.
I don't think anyone is saying the code can't be better or even that the results might be wrong (I don't know as I haven't spent much time going through the codebase).
My meta point is that people are:
1. pressuring and blaming the wrong party.
2. doings something which will have an unintended strongly negative consequence (make scientists averse to publishing their code).
I don’t doubt it, but covid-sim is not the best example of this effect. In this case, people are worried that poorly written simulation code is informing policy decisions that affect billions of people. They are not demanding that it should be fixed, they are demanding that it should not be relied on in its current state.
They're worried that there isn't testing code to prove that it's correct. If it's proven correct in other ways, it doesn't need unit tests.
Yeah, the code's bad – so what? It wasn't written by programmers. Most simulation code is bad, but if it's been proven correct it doesn't need to be good.
From what I can tell, this is a matter of conflicting conventions in different fields meeting head-on.
To be clear, I am not arguing for or against the validity of the claims regarding covid-sim. I am only saying that this is not a good example of the effect where people feel entitled to get open source code that fits their needs.
Dunning-Kruger powered software developers with beliefs that they are in any way qualified to say that mathematical simulations checked by dozens of actual scientists with PhDs are not valid ask that results are ignored because there's no unit tests.
I don't even know where to begin with this, it's so insane. It's extra funny because John Carmack was the one who did a lot of the refactoring of this code. It's also not remotely true that billions of lives have been disrupted on the basis of this code being correct.
This is exactly why scientists don't release their code.
Another reason scientists often don't release code is that code is not considered the valuable artifact produced by research--in more methods-focused fields in particular, it's instead the mathematical model, as embodied in some latex in the published paper. "Reproducing" the results then doesn't consist of trivially rerunning the same code, but in reimplementing it, possibly in a different language. This could maybe be seen as valuable in that the reproduction will surface both implementation errors and logic/modeling errors (though, really, having the source facilitates both).
In fact, more applications-focused researchers (those who combine real data with established models, for instance) tend to write higher-level scripts stringing more-engineered tools. In this case, open sourcing the scripts would be both easier and more pointless, since they will be almost the same as what is stated in English, tables, and plots in the paper. Epidemiology is usually this way, in my experience, though the linked repository seems to have some of both flavors.
The underlying misunderstand in that issue thread seems to me to be a disagreement on what the main valuable byproducts of scientific programming are. Professionally programmers will naturally think it's the code, but, traditionally, the code has been seen in academia as only a temporary vehicle for the model and it's parameters, which is the real product. (Also, the "program" might really need to include the lab, its papers, and its institutional knowledge, which is harder to package and open-source.)
Right or wrong, the assumption is that any competent grad student could reproduce the result in a week or so of (admittedly unnecessary) greenfield coding. But this is clearly not ideal, and newer work does strive for more professionalism in coding, open-source-by-default, and therefore faster replication. The project in question clearly predates this trend.
(Of course, a third reason academics don't open source is that some secrecy is required before publication in competitive fields. On a months-long project, you might not want to be committing publicly before publication. But this isn't much of an excuse.)
Yup. This whole experience was immensely frustrating. First people complain that the code isn't open source and as soon as it is available suddenly there are piles of people swooping in to shit on everything. That's not going to make scientists write better code. It is going to make scientists refuse to open their code.
The only thing more frustrating is when I see people swoop into open source code with "security vulns" that are based on nonsense threat models.
> People often act very entitled about open source I've found.
It's interesting. For me there are at least two classes of open source.
1) Project with a single maintainer, or perhaps a small number of key people, nothing in the way of corporate backing, often worked on in spare time, but which can still be very popular and widely used. I always think back to the example of NDoc, which was a great tool for taking raw XML doc comments from .NET code and turning them into beautiful Javadoc-style HTML documentation. It worked incredibly well for .NET 1.x but the .NET 2 support was never finished because the author, Kevin Downs, received abuse and threats via mail-bomb due to it not being ready "fast enough" for some people. Understandable he decided to quit and, as far as I'm aware, not a peep has been heard from him since in terms of OSS contributions. The way Kevin was treated, and the way other OSS maintainers have been treated by both individuals and corporations, is absolutely despicable and completely unacceptable.
2) Corporate backed OSS projects that are actively evangelised: projects like .NET Core, Node, npm, TypeScript, React, Angular. You might even think of something like Firefox in this category since, although Mozilla is a foundation, it's substantially funded by corporate sponsors (mainly Google?), has full time employees paid to work on the products, etc. Some of these might at times have been considered open source in name only: i.e., source code is absolutely available, but there is little or no way for most people outside of the sponsoring organisation to meaningfully contribute. With these I take a slightly different attitude, and I certainly expect sponsoring organisations to take more responsibility for the projects. If you're actively evangelising people to use a project (and especially if you've succeeded in recruiting large numbers of people to use your project), and you're not giving them much opportunity to contribute, then absolutely you need to take responsibility for making sure the project is supported appropriately. That might even include paid support options.
And I suppose perhaps these represent the extremes of a spectrum (perhaps - I don't claim to have this absolutely right, by any means).
Clearly there are a lot of people who would disagree with me on both sides. E.g., people who think every open source project should be like (2) and that all authors bear an equal responsibility for supporting their code. On the flipside, since I've been flamed on this before, I know there are people who think I'm a walking manifestation of all human evil because I've suggested that any open source project might perhaps fall into category (2).
Fundamentally though I think your point stands: a lot of people behave in a way that's very entitled towards individual maintainers of OSS projects. As you say, depending on your circumstances, often not worth the hassle.
I have a very simple Firefox extension that inverts the colors of sites, I wrote it as I needed something that would just give me dark themed web pages when my baby was asleep next to me. You would not believe some of the reviews and requests (ultimatums) I got.
The funniest ones are those who need your thing for their professional work, yet treat you as if you were a fully paid contractor at their beck and call.
Absolutely, but that is often not the expectation. When I have pointed this out in the past people have gotten hysterically angry demonstrating a degree of entitlement. The mere mention they could do it themselves or submit a pull request has been regarded as a hostile personal insult like declaring war or perhaps worse than making sexually profane and racial commentary about their spouse.
And then they could either contribute it back, fork your project or just keep it to themselves, if the license allows it. At any rate, you already helped them...