Thanks to @meena for prompting this - it's not like I'm some sort of Superior Programming Being whose every line of code is elegant snd brilliant and not worthy of the sweaty masses. I'm a tediously average programmer. I detest status-driven gatekeeping. I would like to share my work so the effort can be leveraged by others to do new and useful work. I support some ideal of open source circa 1995 where useful decent quality tooling is freely shared and available.

That is not the environment we live in today. Beyond the individual entitled ankle-biters that harass devs for not doing work they want for free, we now have this extreme corporate bullshit of "open source supply chain", that freely-provided _caveat utilitor_ code should be treated like code acquired under a commercial procurement agreement with formal specs, requirements, and standards for security, quality, and lifecycle management.

I work in this space in my day job, I'm the one who sets and verifies those specs for our acquired codes, and I'm going to say flat out, that is that absent an explicit agreement with a supplier, all that supply chain and capital-P procurement activity is *solely* on the code user, not on the code author, full stop. Screw off with that CTO/infosec/bureaucrat thinking. Into the sea with you.

For those of you in the back:
_IF THAT PROCUREMENT AND ASSURANCE WORK IS IMPORTANT TO YOUR ORGANIZATION, YOUR ORGANIZATION NEEDS TO PAY FOR IT_.

Further:
_WITHOUT AN EXPLICIT AGREEMENT, NOBODY IS REQUIRED TO PROVIDE THAT SERVICE TO YOU AT ANY PRICE_.

And finally:
_WHAT PART OF 'USE AT YOUR OWN RISK' IS UNCLEAR TO YOU?_

I will curse all day long about research-grade software being built and distributed by organizations who explicitly know they are working on nuclear safety applications and do not perform adequate diligence in design, implementation, and testing. This goes beyond #ResearchSoftwareEngineering - it's production software engineering practice. These are organizations who absolutely know how their code is used (we have monthly meetings with them). I hold these organizations and individuals to a higher standard because this is quite literally our jobs.

By contrast, this is not the job of @bagder and expecting or demanding he do some corporation's or industry's V&V and SQA work is laughable, expecting him to do it _for free_ is arrogant, insulting, and delusional.

But this is where we are now with sharing our code. Ethically, I believe anyone who puts their code in public bears some personal responsibility to ensure it's of a reasonable level of quality, functionality, and security. It's as if you were bringing homemade food to a potluck - the expectation is that it's edible and not spoiled or adulterated. You aren't expected to disclose every significant allergen, provide a list of ingredients, or a nutritional statement but you're expected to wash your hands, use clean utensils and ingredients of good quality, and ensure the food is cooked all the way through.

That's gatekeeping, absolutely, and I won't apologize for setting that demand or an analogous one for "potluck" software.

I am old enough to remember Matt's Script Archive and I have seen what happens when we don't do this sort of positive gatekeeping. For those unfamiliar, Matt was the Typhoid Mary of insecure internet software and his formmail.pl script was the poster child for bad and dangerous code you found for free on the internet. https://en.wikipedia.org/wiki/Matt%27s_Script_Archive

And while I appreciate he was a teenager when he posted most of that code, as an adult he was repeatedly told how damaging his code was and yet he kept distributing broken versions for YEARS.

Matt's Script Archive - Wikipedia

Our paper "Future challenges for Research Software Engineering" is out. We looked into what research software engineering might look like in future and what challenges will await us. The paper is based on a community discussion during the deRSE 2025 conference.

#RSE #ResearchSoftwareEngineering

https://doi.org/10.14279/eceasst.v85.2721

Future challenges for Research Software Engineering | Electronic Communications of the EASST

The #NAIRR pilot has evolved from concept to a real shared #AI research platform that connects researchers, educators, industry partners, and national labs. Sandra Gesing, executive director of US-RSE, highlights how this 2-year-old collaborative infrastructure is lowering barriers for teams to fuel creativity, discovery, and possibility.

👉 Read more: https://www.govtech.com/education/higher-ed/2-years-into-nairr-pilot-shared-infrastructure-boosts-ai-innovation/

#RSE #RSEng #ResearchSoftwareEngineering #Innovation #Collaboration #HPC

2 Years Into NAIRR Pilot, Shared Infrastructure Boosts AI Innovation

Providing shared computing power, AI tools and educational support, the National Artificial Intelligence Research Resource pilot connects researchers, educators and industry partners pushing boundaries with AI.

GovTech

Can anyone help me find a new server?

I've recently changed my surname and since I want to create a new mastodon account to match, it's a good time to also find a server that might be a better home for me than Fosstodon.org

TBH, I don't use many of the within-instance features, mainly I just look at feeds of people I follow, but I can't be bothered to self-host.

I'm mainly interested in toots about #RSE (#researchsoftwareengineering), #environment, #maker stuff - so maybe there's no best fit!

Our next Hacky Hour will take place Wednesday, 1st October 14:00-15:00. We will meet in the Learning & Teaching Building on in the Union Bar fake lawn. Our Hacky Hours are informal meetings to help with programming problems and related issues (testing, documentation, maintainability, reproducibility). We have experts in programming languages, command line shells, collaborative tools, LaTeX, a number of scientific fields. https://www.strath.ac.uk/science/computerinformationsciences/hackyhour/ #HackyHour #RSE #ResearchSoftwareEngineering
HackyHour | University of Strathclyde

A more complete example would involve a mechanical desk calculator, a slide rule, and mathematical tables like Abramowitz and Stegun ("Handbook of Mathematical Functions") https://www.nist.gov/mathematics-statistics/handbook-mathematical-functions-abramowitz-and-stegun Prior to the use of digital electronic computers, complex numerical problems were translated to manual computing plans and solved by teams of human "computers", often women with degrees in math who were locked out of university and technical jobs.

This is sort of the origin of #researchsoftwareengineering - the relationship between subject matter experts who understand a problem domain and the pure and applied math underpinning a solution and the experts in numerical analysis and computation who could convert that mathematical solution into a plan or program suitable for automatic computation whether the computer was electronic or human.

I'm mainly interested in the evolution of digital computing techniques here but it would take very little to make this a complete example that covered all of 20th century computing and broaches some very uncomfortable facts about gender and race in computing long before ENIAC. Not my primary focus but I'd feel remiss in not calling it out.

Handbook of Mathematical Functions: Abramowitz and Stegun

Date: 1964

NIST
I swear I'm going to get thrown out of the #researchsoftwareengineering community before I actually get into it. I'm not setting impossibly high standards - "show your work" is standard in every branch of math, science, and engineering. Just apparently not when scientists and engineers touch computers.

📢 "#ResearchSoftwareEngineering: Discovering and Bridging Knowledge Gaps" is out now in IEEE Computing in Science & Engineering: https://s.dlr.de/cise-special-issue-rseng.

This special issue collects work that has been started during the #Dagstuhl Seminar 24161 "Research Software Engineering: Bridging Knowledge Gaps" (April 2025): https://dagstuhl.de/24161.

Over 5 papers, it lays out how #RSEng and #SoftwareEngineeringResearch should collaborate in the future for mutual benefit.
#RSE s can leverage state-of-the-art methods and tools from software engineering research to create better software that enables better research. SERs can gain insights into an understudied area of SE practice, and develop new research questions and agendas that produce the methods and tools required for state-of-the-art software engineering in research contexts.

The issue has been guest-edited by @danielskatz, Caroline Jay, Lars Grunske and myself.

🧵 The following thread posts present each of the collected papers.

Our next Hacky Hour will take place Wednesday, 3rd September 14:00-15:00. We will meet in the Learning & Teaching Building on in the Union Bar fake lawn. Our Hacky Hours are informal meetings to help with programming problems and related issues (testing, documentation, maintainability, reproducibility). We have experts in programming languages, command line shells, collaborative tools, LaTeX, a number of scientific fields. https://www.strath.ac.uk/science/computerinformationsciences/hackyhour/ #HackyHour #RSE #ResearchSoftwareEngineering
HackyHour | University of Strathclyde