I recently sent a brief answer to @krille on Mastodon about what managing an average FOSS project looks like in 2026. Christian is the main author of a Flutter app (FluffyChat, a Matrix client). Indeed, this deserves a more extensive discussion.
I recently sent a brief answer to @krille on Mastodon about what managing an average FOSS project looks like in 2026. Christian is the main author of a Flutter app (FluffyChat, a Matrix client). Indeed, this deserves a more extensive discussion.
The use of AI tools for development (AI-aided development, AIAD) and intellectual work is a disputed, hot topic. I’m generally on the pragmatic side in that regard. While the environmental impact of AI systems is evident and a reasonable concern, these tools, when used with a grain of salt and a responsible approach, can solve problems that would otherwise be hard to manage. Keep man in the loop, to say it in one sentence, and do not pretend that such tools can fully replace human judgment and capabilities.
Ok, such dramas and the whole topic are starting to be annoying. The last episode was the rsync project with the well-respected Andrew Tridgell as maintainer, who initiated a Claude-based development effort for the 3.4 series a few months ago. The rsync tool is a well-known, widely used tool for copying files between hosts in a smart way, includes a daemon to optimize file transfers, and serves as an entry point for synchronization.
I already dealt with the status of the WWW in the recent past. See, specifically, the authoritative opinion of Sir Tim Berners-Lee on that. Multiple dynamics have upset the initial idea of a distributed, democratic, and influential worldwide system, as conceived in the 90s, including the roles of BigCorps, socials, and geopolitics. What appears to be the last brick in the grave of the WWW is the current AI wave, which introduces two distinct elements of breaking an already compromised equilibrium.
Some months ago, I participated in this Mastodon poll. My thesis was that, in general, there is no presumptive quality flag that can be added to a product, whether it was created with AI-aided tools or not. My opinion sparked a small, heated controversy among some readers.
I recently finished reading Simone Aliprandi’s second edition of a book I would recommend to many people interested in either authoring software and databases or making creative works. ‘The Artificial Author’, as its title suggests, deals with the role of generative AI in creative jobs seen from a legal point of view. This massive book seeks to shed light on a central yet complex issue that, in recent years, has affected many people, not only in the IT sector but also across many sectors of the creative industry.
Here at work, we develop a series of tools for geospatial processing with multiple goals, expected maintenance durations, different scopes, generalization needs, and motivations. Note that about 10 years ago, here in Europe, a completely new approach to upstream and downstream services for Earth Observation began: ESA changed its data licenses, and distribution and access modalities entered the Big Data era.
Someone on Mastodon (I’m sorry, but I don’t remember who exactly) published a short post that pointed to a rather technical economic study of the impact of AI on FOSS software development [1]. It is no secret that the AI debate is highly polarized, and the enthusiasts for the current trend in AI applications in the IT domain are at least as numerous as those who are concerned/skeptical. What is certain is that no one can, in the long term, prospectively evaluate the impact of AI on society, particularly in the IT world.
I have already addressed the implications of modern LLMs, specifically their training, in the context of copyright and licenses for both code and original content. A 'IANAL' disclaimer applies to this post, but my honest opinion is that such training is a legitimate type of reading and learning after study, unless explicitly excluded in licenses among the licensee's rights.
I recently re-read the seminal book by Fred Brooks about software engineering, entitled "The Mythical Man-Month" or MM-M for brevity. Specifically, I read the paper version of the 20th anniversary, which was revised and reprinted in 1995, after the first edition of 1975. I did that on purpose, firstly because it is always a fantastic read, and secondly to understand how much of its contents is still valid today, exactly thirty years later since its last revision.
My last post dealt with some ideas about copyright that need more in-depth analysis. First, as it was common in the old good days, IANAL applies to this post and the whole topic. The final results of current litigations in courts that touch on some of the primary companies involved in the whole AI thing could ultimately differ from what is now the common sense point of view (mine). This post could become rapidly obsolete, so another disclaimer is due for this aspect, too.
My last post captured the attention of my old fellow Sandro 'strk' Santilli on Mastodon, who sent a provocation about the whole AIAD thing. So, the challenge is accepted.
Like many other developers, I recently started using some LLM-based AI systems as helpers for coding in a few languages. I'm not a fan of VSCode, and I prefer a more traditional approach to coding: I hate to cope with code completion servers and use one of my preferred editors, Vim or Emacs. Navigating by tags is more than enough for me. That said, this is the summary of my current experience in the new world of AI-aided approach to coding (i.e., AI-aided development or AIAD for brevity).
One of the coding projects I currently maintain is Autodir, a not-so-known little daemon based on autofs that can be used to create automagically users or group directories at their first use. It is specifically helpful when some kind of shared accounts system is adopted for multiple hosts and the related home directories need to be created optionally and on demand. Well, I recently moved the old repository from SourceForge to GitHub, and that has also been the occasion for me to update the old Docbook howto document for Autodir initially written by the original Autodir developer, Venkata Ramana Enaganti. I mostly maintained the project as a Debian package in the last 20 years or so, with only little interest in feature improvements: it basically just works, and that's more than enough for my use cases.