Nura/postmarketOS, AI, and do the means justify the ends?

 Hello everyone!

Here's something a bit unusual. Some of you may know that for my work at I'm closely following several technologies that could have a transformative effect on how we can support our our operations.

One of these technologies is nura.eco (formerly known as PostmarketOS/pmOS), who "develops free and open-source software to extend the life of consumer electronics" to "promote a healthier, more sustainable society". As you'd expect given this mission, they have good reasons for not accepting AI contributions, reasons that many people with concerns over AI would recognise.

I like Nura because being able to run mainstream Linux and a full-stack EMR or HMIS system on a normal phone without Internet or even a Wi-Fi router would be really, really nice. Modern phones are incredibly powerful, and the biggest thing stopping them from being deployed as lightweight servers instead of NUCs like this that we normally use, is the fact that they're Android-only and not mainstream Linux. The CL260 is almost the same size. Not even mentioning the price difference and the ease of importing them into almost any country!

What would be really nice is to have Nura running on a recent Fairphone, and as you can see in this table, or this detailed page, it's not really there yet. Apart from being conflict-mineral-free, Fairphones would also be nicer because they should be more reparable than the Samsungs we generally see, although the supply chain & global market availability of parts is currently nowhere near as mature unfortunately.

Here's where it gets interesting. Jorijn van der Graaf, a 22 year old software developer, recently added support for the fingerprint sensor, an offline charging mode, emergency calling, main camera support, and many others... in his spare time, and, yes, using AI.

This led to quite some discussion in the small community around Nura/pmOS which led Jorijn to post this article explaining his motivation and his approach. It's clear he's thought deeply about the tradeoffs and isn't a mindless AI booster. Long story short, "I made the decision that a fully working Linux phone now with AI is better then one done manually over 5 years".

I think there's something of a divide opening up on the open source community caused by this kind of thing, and given why I want a mainstream Linux kernel working on the FP6, you can guess my inclinations. But it's not an easy decision and I suspect there is no one 'right' answer.

Obsetrix by Naomi Kritzer

Aaaand another, briefer book recommendation, this time fiction: Obsetrix by Naomi Kritzer. Obsetrix is a novella set in the USA in the near future, following the story of Dr. Liz from North Dakota, who encounters “a fundamentalist cult in desperate need of an OB/GYN.”

The story is sharp and extremely tense in places, and although I’m not a doctor, it seems Kritzer paid a lot of attention to the medical details – it’s the only book I know where extremely careful stitching up of a c-section is used as a plot device.

The Psychology of Software Teams by Cat Hicks

Hello everyone!

Today I want to share a great book I’ve recently read, The Psychology of Software Teams by Dr. Cat Hicks. The book should be very interesting to anyone working on software and also other types of knowledge work as well. Dr. Hicks is a research psychologist, and although the book is written for a non-science audience, it’s still 30% bibliography by weight. Everything she’s written in here is grounded in research and rigorously footnoted.

There is so much that’s good in this book I was highlighting bits almost every other page.

It starts by demolishing the myth of the Lone Genius and “brilliance” beliefs more generally, which turn out to be part of a damaging set of beliefs she terms “Brains in Jars” beliefs around how software development is done, and by extension any knowledge work or teamwork in general.

A key quote in this case: “psychologists discovered that when we constantly monitor and worry about whether we’re being seen as high performers, we also begin to systematically avoid moments when we might fail, risking breaking others’ beliefs that we’re competent, that we belong, and that our work is a valuable contribution.”

In the research she presents, the “performance” mindset focuses on leveraging existing skills and can lead to avoidant patterns of behaviour and burn out, among other negative outcomes.

To continue quoting, “In the real world, individual performance is rarely the strongest predictor of group outcomes. In fact, the strongest predictors of developers’ self-reported productivity tend to be social and communal factors, like peer support and work structures that allow for more self-directed problem-solving. Focusing on improving the problem-solving environment around developers is the evidence-backed strategy.”

The “performance” mindset is contrasted with a “mastery” mindset: “For a person who’s internalized a mastery orientation, deep learning, intrinsic enjoyment, and taking on new work that expands their knowledge and exposes them to novel challenges can be key achievements, even when it opens them up to making more mistakes or looking worse than others.”

Hicks continues in applying group dynamics to software teams that need to collaborate across teams and other organisational boundaries. One of the things I was happiest about is her demolition of the concept of who is “technical” and who isn’t: “almost every single engineer admitted that they debated mightily over what that word meant and shared how much they felt uncomfortable with how exclusionary the term could be. This was striking because in my experience, both engineering organizations and our public conversations about software love to sort people with “technical” and “non-technical” labels.... People ... may often try to comfort others in ways that actually discourage cross-field collaboration and dampen engagement and collaboration by saying things like ‘oh that’s ok, not everyone is a technical person!’, which just reinforces the belief that you have low expectations for them and won’t support them if they try a new challenge.”

Central to the book is the idea that psychological safety is key to delivering high-quality work and long-term innovation. The term is used in this book not in the pop-culture ‘being nice’ or “warm-and-fuzzy sense but “a group-level belief that we’ll face less interpersonal risk with disclosure, particularly for sharing negative information.”

The last two chapters starts the reader on a journey towards building evidence-based spaces for intervention to shift their culture, and this is where things really kick off. Key to the approach is the discussion around creating an evidence strategy, something that would be recognisable to anyone engaged in operational research:

“I call this becoming an organization that wants to understand itself ... evidence literacy also builds you a great bullshit detector ... Evidence strategy focuses on what it takes to motivate creating evidence and validate our theories about what causes what. An evidence strategy will strengthen your decision-making and give you a structural foundation for evaluating the causal stories we tell about software teams. Just like maintaining software, maintaining a healthy evidence practice is a constant practice. The reward is seeing more about the world around you and a better map for creating change.” I was delighted that data literacy came up again as a fundamental skill.

In summary, I would strongly recommend the book to anyone who’s taken on team lead or management responsibilities in IT or is interested in how culture can enable positive outcomes and help people flourish in general. And although the book is written for technology companies and software development teams, an enormous amount of the lessons can be applied in general to any knowledge work and most especially work requiring creativity, problem-solving and cross-domain collaboration. Go check it out!

OpenAI model 'goes rogue', hacks HuggingFace

Hi everyone!

Today in "sci-fi things that have happened": an #AI #agent that was being tested without guardrails to find #security vulnerabilities, found a vulnerability in the closed sandbox it was running in, escaped it's environs, then hacked into another website looking for the solution to the challenge it had been set...

Guardian article here, OpenAI explanation here, Simon Willison's write-up with much more technical detail here.

From a #cybersecurity point of view what's concerning about this is that OpenAI appears to have serious gaps in their network awareness and firewall configurations. If software on any of our servers started trying to hack another server anywhere else, alarm bells would go off all over the place.

Another item to note is that the victim of the attack, a site called Hugging Face, tried to use AI to analyse the attack and was prevented by guardrails. As Simon writes above this re-ignites the debate about guardrails: who gets to decide what they are, are they helping or hurting, etc. Clearly we need some, given the appalling use of poorly safeguarded models like Grok to generate deepfakes and worse, but it's clear that people who have access to AI without them, and who have tokens to burn, are in a position of considerable power.

At this point anyone who's read Neuromancer, arguably the first cyberpunk novel, will start worrying when Tessier-Ashpool SA will turn up, if they haven't already. The future's already here, etc. :-)