Posts by blog@shkspr.mobi
 (DIR) Post #B4FdIWNQ8JSuob68Su by blog@shkspr.mobi
       0 likes, 1 repeats
       
       How Can Governments Pay Open Source Maintainers?https://shkspr.mobi/blog/2026/03/how-can-governments-pay-open-source-maintainers/When I worked for the UK Government I was once asked if we could find a way to pay for all the Open Source Software we were using. It is a surprisingly hard problem and I want to talk about some of the issues we faced.The UK Government publishes a lot of Open Source code - nearly everything developed in-house by the state is available under an OSI Approved licence. The UK is generally pretty relaxed about people, companies, and states re-using its code. There's no desire and little capability to monetise what has been developed with public money so it becomes public code.What about the Open Source that UK Government uses?The state uses big projects like WordPress, as well as moderately popular NPM packages, and small Python libraries and everything in between. But can it pay the maintainers of that software?A version of this blog post was originally published on Hackernoon.Fixing The PlumbingOpen Source is facing a crisis. The code that the world relies on is often developed by underpaid engineers on the brink of burn-out.  While I don't think anyone wants Open Source to have a paywall, it seems obvious that large organisation should pay their way and not rely solely on volunteer labour.Here are some of the problems I faced when trying to get the UK Government to pay for OSS and how you as a maintainer can help make it easier for large organisations to pay you.Firstly, lots of OSS doesn't have a well defined owner; so who gets the money?I'm not saying that every little library you create needs to be published by a registered company, nor am I suggesting that you should remove your anonymity. But Governments and other organisations need to know who they are funding and where the money is going. The danger of accidentally funnelling money to a sanctioned state or person is just too big a risk for most organisations.If you want to receive funding - make it really clear who you are.What Can You Offer?Even when there is an owner, there often isn't an easy mechanism for paying people. Donation sites like GitHub Sponsors, Ko-Fi, and Patreon are great for individuals who want to throw a small amount of money to creators but they can be problematic for larger organisations.  Many OSS projects get around this by offering support contracts. It makes it much easier for an organisation to justify their spend because they're no longer donating to something which can be obtained for free; they're paying for a service.This doesn't have to be a contract offering a 24/7 response and guaranteed SLA. It can be as simple as offering best-effort email support.The important thing is to offer an easy way for a larger organisation to buy your services. Many organisations have corporate credit cards for lower-cost discretionary spending which doesn't require a full business-case.  How easily could a manager buy a £500 support contact from your site?Maintainers don't only have to offer support contracts. Many choose to offer training packages which are a good way to raise money and get more people using your product. Some project maintainers will speak at your conference for a suitable fee.Again, the aim here is for maintainers to offer a plausible reason for a payment to be made.Playing Well With OthersOpen Source has a brilliant culture of allowing multiple (often anonymous) contributors. That's fine when there's no money involved, but how does a moderately sized project decide who receives what share of the funding? Services like OpenCollective can make it easier to show where the money is going but it is better to discuss in advance with all contributors what they expect as a share.If people think they're being taken advantage of, or that a project maintainer is unjustly enriching themselves, it can cause arguments.  Be very clear to contributors what the funding is for and whether they're entitled to any of it.Finally, we faced the issue that some OSS projects didn't want to take money from the "big bad state". They were worried that if people saw "Sponsored by the Government" they would assume that there were backdoors for spies, or that the developer might give in to pressure to add unwanted features.  This (usually) isn't the case but it is easy to see why having a single large organisation as the main donor could give the impression of impropriety.The best defence against this is to have lot of paying sponsors! Having the state as one of many partners makes it clear that a project isn't beholden to any one customer.It isn't impossible to get Governments to spend on Open Source. But state spending is heavily scrutinised and, bluntly, they aren't set up to pay ad hoc amounts to non-suppliers, who aren't charging money.  While large projects often have the resources to apply for Government grants and contracts, smaller projects rarely have the time or expertise. It is critical that maintainers remove the barriers which make it too hard for organisations to pay them.In SummaryMake it easy for Governments and other large organisations to pay you.Be as obvious as possible that you are able to accept payments from them.Don't be afraid to put a large price on your talents.Offer multiple paid-for options like speaker fees, support, and feature development funding.Talk with your contributors to let them know how any funding will be shared.#government #money #OpenSource
       
 (DIR) Post #B5eVMliz7I8ah1DElU by blog@shkspr.mobi
       0 likes, 0 repeats
       
       You can parse an .env file as an .ini with PHP - but there's a catchhttps://shkspr.mobi/blog/2026/04/you-can-parse-an-env-file-as-an-ini-with-php-but-theres-a-catch/The humble .env file is a useful and low-tech way of storing persistent environment variables. Drop the file on your server and let your PHP scripts consume it with glee.But consume it how? There are lots of excellent parsing libraries for PHP. But isn't there a simpler way? Yes! You can use PHP's parse_ini_file() function and it works.But….env and .ini have subtly different behaviour which might cause you to swear at your computer.Let's take this example: ENV# This is a commentUSERNAME="edent"Run $env = parse_ini_file( ".env" ); and you'll get back an array setting the USERNAME to be "edent". Hurrah! Works perfectly. Ship it!But consider this: ENV# This is a commentUSERNAME="edent" # Don't use an @ symbol here.It will happily tell you that the username is "edent# Don"WTAF?Here's the thing. The comment character for .ini is not # - it's the semicolon ;Let me give you some other examples of things which will fuck up your parsing: ENV# Documentation at https:/example.com/?doc=123DOCUMENTATION=123# Set the passwordPASSWORD=qwerty;789That gets us back this PHP array: PHP[  '# Documentation at https:/example.com/?doc' => '123',  'DOCUMENTATION' => '123',  'PASSWORD' => 'qwerty',];When the .ini is parsed, it ignores every line which doesn't have an = sign. It also treats literal semicolons as the start of a new comment until they're wrapped in quotes.My code highlighter should show you how it is parsed: INI# Documentation at https:/example.com/?doc=123DOCUMENTATION=123# Set the passwordPASSWORD=qwerty;789It gets worse. Consider this: ENV# Set the "official" nameREALNAME="Arthur, King of the Britons"That immediately fails with PHP Warning:  syntax error, unexpected '"' in envtest on line 1You can use single quotes in pseudo-comments just fine, but if the ini parser sees a double quote without an equals then it throws a wobbly.I'm sure there are several other gotchas as well. For example, there are certain reserved words and symbols you can't used as a key.This will fail: ENV# Can we fix it? Yes we can!FIX=trueIt chokes on the exclamation point.How to solve it (the stupid way)The comments on an .env file start with a hash.The comments on an .ini file start with a semicolon.So, it is perfectly valid for a hybrid file to have its comments start with #;Look, if it's stupid but it works…What Have We Learned Here Today?There's a right way and a wrong way to do .env parsing.The wrong way works, up until the point it doesn't.You should probably use a proper parser rather than hoping your .env looks enough like an .ini to pass muster.On next week's show - why you shouldn't store your passwords inside a JPEG!#php
       
 (DIR) Post #B5tXJldw4qYsqowjjM by blog@shkspr.mobi
       0 likes, 0 repeats
       
       NHS Goes To War Against Open Sourcehttps://shkspr.mobi/blog/2026/05/nhs-goes-to-war-against-open-source/The NHS is preparing to close nearly all of its Open Source repositories.Throughout my time working for the UK Government - in GDS, NHSX, i.AI, and others - I championed Open Source. I spoke to dozens of departments about it, wrote guidance still in use today, and briefed Ministers on why it was so important.That's why I'm beyond disappointed at recent moves from NHS England to backtrack on all the previous commitments they've made about the value of open source to the UK's health service.It's rare that multiple people leak the same story to me, but that's what gives me confidence that lots of people within the NHS are aghast at this news.A few days ago, I was sent this quote which was attributed to a senior technical person in NHS England.We are obviously looking at things like Mythos, which is more sophisticated at finding vulnerabilities. In the next week or so, we will be changing our tack on coding the open and making our code public until we're on top of that risk.Most of our repos, unless they're essential, will be removed for security reasons.As I've written before, this is not the correct response to the purported threat by Mythos.  Neither the AI Safety Institute nor the NCSC recommend this action.  While there may be some increase in risk from AI security scanners, to shutter everything would be a gross overreaction.Nevertheless, that's what the NHS is preparing to do.On the 29th of April, guidance note SDLC-8 was sent out. Here's what it says:The majority of code repos published by the NHS are not meaningfully affected by any advance in security scanning. They're mostly data sets, internal tools, guidance, research tools, front-end design and the like. There is nothing in them which could realistically lead to a security incident.When I was working at NHSX during the pandemic, we were so confident of the safety and necessity of open source, we made sure the Covid Contact Tracing app was open sourced the minute it was available to the public. That was a nationally mandated app, installed on millions of phones, subject to intense scrutiny from hostile powers - and yet, despite publishing the code, architecture and documentation, the open source code caused zero security incidents.Furthermore, this new guidance is in direct contradiction to the UK's Tech Code of Practice point 3 "Be open and use open source" which insists on code being open.Similarly, the Service Standard says:There are very few examples of code that must not be published in the open.The main reason for code to be closed source is when it relates to policy that has not yet been announced. In this case, you must make the code open as soon as possible after the policy is published.You may also need to keep some code closed for security reasons, for example code that protects against fraud. Follow the guidance on code you should keep closed and security considerations for open code.There's also the DHSC policy "Data saves lives: reshaping health and social care with data":Commitment 601 – completed May 2022We will publish a digital playbook on how to open source your code for health and care organisationsAnd, here's NHS Digital's stance on open source in their Software Engineering Quality Framework:The position of all three of these documents is that we should code in the open by default.All of which is reflected in the NHS service standard:Public services are built with public money. So unless there's a good reason not to, the code they're based should be made available for other people to reuse and build on.All of which is to say - open source should be baked into the DNA of the NHS by now. There are thousands of NHS repositories on GitHub. The work undertaken to assess all of them and then close them will be massive. And for what?Even if we ignore the impracticality of closing all the code - it is too late! All that code has already been slurped up. If Mythos really is the ultimate hacker, hiding the code now does nothing. It has likely already retained copies of the repositories.And if it were both practical and effective to hide source code - that doesn't matter. These AI tools are just as effective against closed-source. They can analyse binaries and probe websites with ease.There are tens of thousands of NHS website pages which refer to their GitHub repos - will they all need to be updated? What's the cost of that?I've no idea what led to NHS England making this retrograde decision - so I've send a Freedom of Information request to find out.I am convinced that closing all their excellent open source work is the wrong move for the NHS. I hope they see sense and reverse course.Until then, I've helped make sure that every single NHS repository has been backed up and, because the software licence permits it, can be re-published if the original is closed.In the meantime, you should email your MP and tell them that the NHS is wrong to shutter its world-leading open source repositories.Don't let them take away your right to see the code which underpins our nation's healthcare.Further ReadingI'm quoted in this article from The New Scientist.Matt Hancock on the issuePetition - Keep Things Open#government #nhs #OpenSource #politics
       
 (DIR) Post #B6OKJBwpW1w2dkw98y by blog@shkspr.mobi
       0 likes, 0 repeats
       
       GDS weighs in on the NHS's decision to retreat from Open Sourcehttps://shkspr.mobi/blog/2026/05/gds-weighs-in-on-the-nhss-decision-to-retreat-from-open-source/Within the UK's Civil Service you occasionally hear the expression "being invited to a meeting without biscuits". It implies a rather frosty discussion without any of the polite niceties of a normal meeting0. In general though, even when people have severe disagreements, it is rare for tempers to fray. It is even rarer for those internal disagreements to spill over into public.Which is what makes GDS's latest guidance so surprising. At the start of the month, NHS England made the bizarre and irresponsible decision to close all their Open Source repositories due to unfounded fears of AI hacking1. Lots of people within the NHS were outraged. As were many outside - with this petition against the move gathering over 2,000 signatures.Within other parts of government there was also alarm. Although I no longer work for Government Digital Service, I was contacted by several concerned people there who remembered all my work on Open Source. The brilliant team in Whitechapel have now published their guidance "AI, open code and vulnerability risk in the public sector".It is brutal.They utterly repudiate the NHS's stance and forensically eviscerate it. I'll let you read the whole thing, but here are a few choice excerpts:Recent public reporting about organisations restricting access to public repositories due to AI-enabled code analysis illustrates how quickly leaders may reach for blanket closure in response to uncertainty.Basically, non-technical managers need to stop over-reacting.Private repositories can create a false sense of security.I think that's the crux of the argument. Closing code doesn't solve the underlying problems.Making code private is not an appropriate mitigation for lack of ownership, patching capability, or operational assurance, so systems that cannot be safely maintained should be remediated or retired.If you are so concerned about the poor security of your systems, you should shut them down completely to mitigate the threat.Closure can become a one-way door.As I said to the BMJ, "nothing lasts longer than a temporary fix".Where code has been developed in the open, making a repository private later may not remove access for a capable adversary as popular repositories are often mirrored or forkedIndeed. A friend of mine has already archived all of the NHS's repositories. You can see the ones they've tried to hide.But the killer blow, I think, is this:Moving code from public to private as a substitute for investment in secure-by-design delivery, ownership and remediation is a warning sign because it reduces sharing and scrutiny, can slow coordinated improvement across government and suppliers, and does not remove the underlying weaknesses in a running service.Exactly! Coding in the open has been shown time and again to produce high quality and secure work. The looming threat of AI vulnerability scanners doesn't change that - security is a shared responsibility. Technical teams need to be well enough resourced to create secure systems; hiding code is as reliable as papering over structural cracks.GDS was created was to be a strong centre with vast technology expertise. This was to counter the frankly shoddy approach to tech in other departments. Back then, a Service Assessment was a way for a department to prove that they were actually capable of designing, launching, and managing a complex IT project.Most departments have become significantly better at the development and running of these sorts of projects, so the raison d'etre of GDS has somewhat waned. Departments feel more confident in running off on their own. Usually I'd celebrate that - it's important that GDS doesn't become a bottleneck and that the talent is distributed throughout the whole Civil Service.But NHS England has always been a bit of a weird one. One of the reasons NHSX was created2 was to ensure that the health service had strong expertise in technology and its deployment. As the Head of Open Technology there, I helped craft the policies which embedded Open Source and Open Standards within it3.I don't know what discussions have taken place within NHS England - although I looking forward to receiving a response to my FOI request. It looks to me like a small group within NHS England have received a report showing some potential vulnerabilities discovered by Mythos. Rather than following their own internal guidance, they've over-reacted and slapped a blanket ban on coding in the open.I fervently hope that this new guidance will encourage DHSC to bring NHS England into line with best practice. If not, perhaps GDS ought to reassert itself as the technical authority with power to veto a department's incomprehensible decisions?Of course, all the budget cuts mean that biscuits cannot be purchased for any meetings. Which may explain some of the morale issues within the Civil Service. Thanks Austerity. Thausterity. ↩︎As of today, they've shut down nearly 200 repositories. More may be coming. ↩︎I was there right before the start of NHSX and helped set it up. ↩︎Which, I suppose, is why I'm bitter and angry that all our hard work is being undone. ↩︎#AI #gds #government #nhs #nhsx #OpenSource