Tag Archives: open source

Month notes

March 2025 month notes

Community

I came across this really interesting project that aims to ensure that the JavaScript libraries are keeping dependencies up to date and that features available in the LTS versions of Node area being used. JavaScript is infamous for fragmented and poorly maintained libraries so this is a great initiative.

But even better I think is Jazzband, a Python initiative that allows for collaborative maintenance but also can provide a longer term home for participating projects.

Digital sovereignty

With the US deciding to switch off defence systems there has been an upswing in interest in how and where digital services are provided. One key problem is that all the cloud services are American every other Western country has let US companies dominate the space and many of the services they offer are now unique to them.

This is probably impossible to solve now but the article linked to above is a useful starting point on how more commodity services could be provided by local providers.

There was also an announcement of an open source alternative to Notion funded by the French (and other) governments. The strategic investment in open source that can be run in the service capacity that European states do have seems a key part of a potential solution and helps share costs and benefits across countries.

Editors

I have been trying out the Fleet editor again, this is Jetbrain’s take on a VSCode style editor that has the power of their IntelliJ IDE but without a lot of the complexity. It’s obviously not as powerful or fully featured as VSCode with all its plugins.

I liked the live Markdown preview but couldn’t get the soft-wrapping that was meant to be enabled by default to work. It was also frustrating that some actions do not seem to be available via the Command Palette and that the Actions aren’t the default tab when hitting Ctrl-Shift-P.

LLMs

I experimented with AWS’s Bedrock this month (via Python scripts), the service has a decent selection of services available with a clear statement of how interactions with them are used. If you’re already an AWS user then access to them casually is effectively free (although how viable that is in the long run is an interesting question) making it a great way to experiment.

I thought have the AWS Nova models might help me write code to interact with Bedrock but they turned out to not really be able to add more than the documentation and a crafty print statement told me.

The Mistral model seemed quite capable though and I’ve used it a couple of times since then for creating Python and Javascript code and haven’t had any real problems with it although it predictably does much better on problems that have been solved a lot.

An alternative to Step Functions

Yan Cui wrote a really interesting post about Restate and writing your own checkpointing system for repeatable AWS Lambda invocations. Step Functions are very cool but the lack of portability and platform-specific elements have been off-putting in the past. These approaches seem very interesting.

When it comes to Lambdas Yan’s newsletter is worth subscribing to.

Reading links

  • Some helpful pieces of good practice in Postgres although some things (soft deleting in particular, view use) will be context specific
  • Defra’s Playbook on AI coding offers a pragmatic view on how to get the best out of AI-led coding
  • Revenge of the Junior Developer, man with a vested interested in AI software developer is still angry at people struggling with it or not wanting to use it
  • AI Ambivalence a more sober assessment of the impact and utility of the current state of AI-assisted coding and a piece that resonated with me for asking the question about whether this iteration of coding retains the same appeal

There was an interesting exchange of views on LLM coding this month; Simon Willison wrote about his frustration with developers giving up on LLM-based coding when he has been having a lot of success with it. Chris Krycho wrote a response pointing out that developer’s responses weren’t unreasonable and that Simon was treating all his defensive techniques fro getting the best out of the approach as implicit knowledge that he was assuming that everyone possessed. It is actually a problem that LLM’s suggest invalid code and libraries that don’t exist.

Soon after that post Simon wrote another post summarising all his development practices and techniques related to using LLMs for coding that makes useful reading for anyone who is curious but struggling to get the same results that people like Simon have had. This post is absolutely packed with interesting observations and it is very much worth a read as a counterbalance to the drive-by opinions of people using Cursor and not being able to tell whether it is doing a good job or not.

Standard
Software

Volunteering at State of Open 2025

I volunteered at the State of Open conference this month, the conference is put on by the Open Source technology advocacy groups OpenUK.

Volunteering allowed me to sit in on a few sessions. AI was obviously a hot topic. There is naturally a lot of unhappiness at what constitutes the idea of an “open” foundation model; it isn’t just the code and the model weights, there’s also an interest in the training corpus and any human refinement process that might be used.

It is reasonable to assume that a lack of transparency in training data is because a lot of it has been illegally obtained. The conference did have a discussion group on the UK government’s consultation on copyright and training material, one that critics have said represents a transfer of wealth from creators to technologists.

Overall though it felt that there was more unhappiness than solutions. The expectation seems to be that companies will be able to train their models on whatever material they want and can obtain.

This unhappiness rang again for the other topic I heard a lot about which was maintainer well-being and open source community health. Maintainers feel stretched and undervalued, companies have been withdrawing financial support and informal, volunteer-run organisations handle conflict poorly within its own pool of collaborators leading to people leaving projects where they feel criticised and undervalued.

The good news is that people’s belief in the importance and value of openness, transparency and collaboration is still strong. The speakers at the conference were here to share because they want to help others and believe in the power of shared efforts and knowledge.

Becoming a volunteer

Someone asked me about how you volunteer for the conference and to be honest it was pretty straight-forward, I saw an invitation on LinkedIn, filled out a Google Form and then just turned up to the briefings and did the jobs I was asked to do. If I have the time then I think it is always worth volunteering to help out at these kinds of events as while you might not be able to get to see everything you want it also means you have something meaningful to be doing if the schedule is kind of ropey.

You also get to interact with your fellow volunteers which is much more fun that going to a conference alone.

Links

  • Astronomer Apace Airflow as a service
  • dbt a tool for transforming data
  • Tessl a start up looking to switch from coding as we know it today to specification-driven development

Talk recommendations

This is purely based on what I was able to see.

Standard
Software

OpenUK: What the fork do we do now?

I attended an excellent talk organised by OpenUK about open-source forks recently.

Dawn Foster gave the context about why forks happen and a few historical examples of when forks overtake their originating projects and why that sometimes doesn’t happen and a few occasions when both the original project and the fork end up in different niches.

This was all given life by James Humphries’ talk about OpenTofu and the problems the consortium of former competitors have had getting their project off the ground. One immediate lesson learned was not to just take the head of the forked project but look for a stable milestone to branch from so you don’t immediately inherit someone else’s work in progress.

Another interesting observation was that commits direct to main without the context of a PR were often harder to understand. Change control processes attract a lot of passion but it was interesting that fast moving projects with direct to main changes are harder for newcomers to understand and maintain.

One problem I found particularly interesting was the change in licensing on Terraform’s registry project which meant the fork had to construct an alternative registry very quickly. They had advice from several other projects including Homebrew and were able to quickly bring up a registry that could be community-maintained and with a contribution of network costs from Cloudflare very low-cost.

Hashicorp clearly changed the terms to not allow competitors to use their registry and maybe that’s valid but it demonstrated that it is the ecosystem that makes forks difficult rather the actual code of the tool.

The project removed the tool’s telemetry early on to help respect user privacy but then then that makes it harder to explain whether their fork is finding traction or not. Looking at the traffic into the registry is a proxy for the volume of usage. This balance between privacy and metrics is an interesting one in open projects.

Standard
Software

Passive-aggressive collaboration

One interesting (and depressing) aspect of post-Github open source development is the use of the pull request as a passive aggressive way of putting off potential contributors, users and testers.

I have had the experience of discovering an issue with a piece of open source and raising an issue for it only to be “invited” to contribute a reliable failing test case, with a fix and all to the project’s contribution standards.

Now the joy of open source is being able to scratch your itch and prioritising your own problems by contributing solutions.

However there are often very good reasons why the maintainers should be the ones fixing the issues.

Firstly the maintainers should be the ones who gain most from fixing issues. One cool thing about Git-based development is that forking allows you to use existing codebases but not share the views and priorities of the original project. If I disagree with the direction or design of a project I can fork it and completely change the code to match my own aesthetics and priorities.

However in most cases I agree with the direction of the maintainers and I am simply pointing out an issue or problem that maybe they haven’t encountered in their context. I could scratch my itch but it is often more effective if the maintainer took my use case into consideration and reworked the codebase to include it.

Maintainers:

  • have more context on the code base
  • know more about the problems the code tackles
  • know their conventions and coding standards better than I do
  • have more invested in having an effective solution than I do

Looking at things like Guava which while open are effectively not open to contribution. This is a more honest approach than inviting non-trivial contributions.

Trying to take the perspective of the maintainer I know it is tedious when people do things outside of your area of interest (i.e. IE fixes when you’re not targeting that version of the browser or Windows fixes in a project targeted at UNIXes). However telling people to “fix it themselves” is not as honest as saying “that’s not our focus”. People can then decide whether they want to fork or not.

Standard