The Lunduke Journal

The Chief Architect of OpenLDAP says that “AI-generated contributions MUST always be rejected.”

Part of the growing rift between “Pro-AI” and “Anti-AI” Open Source projects.

Gregory raises a critical point about the whole “Asahi re-licenses from MIT to GPL” story…

This sort of licensing change requires the consent of every copyright holder (aka developer) on every component which Asahi wishes to re-license. Asahi specifically states that “you retain all copyright ownership of any code you write”.

Which means potentially hundreds of different developers.

Did Asahi leadership get approval from all copyright holders before announcing the sweeping licensing change?

From what I’ve seen:

- Asahi is unhappy that Omarchy is basing work on some of Asahi’s Open Souce code.

- Based purely on statements from Asahi developers, and those close to them, this reaction is based on Asahi’s dislike of both AI and any politics other than extreme Leftist politics.

- This prompted a bizarre response from Asahi. They appear to be trying to get some type of revenge on Omarchy — or to stop Omarchy in some way? — but it just made Asahi look like they don’t understand Open Source licenses in general.

- The official response from DHH and Omarchy was, paraphrasing, “Ok, weird. But it doesn’t really change anything for us.”

Strong, emotional reaction from Asahi. Bemusement from Omarchy.

Tempting to make my office look like this.

How I utilize my little army of clankers is evolving as I gain experience working with them (and as they improve).

I have a small team of bots focused on QA work. Adhoc testing, running structured test passes (BVT, BFT, & Comp), and performance testing.

Those bots operate almost entirely “hands off” right now. They crank through thousands of tests (adding to them as they go), on a wide variety of machines, and then pass their results to a QA Lead bot — which takes those results, cleans them up, does a first pass at *very* high level triage and ranking… then sends them to me to let me choose how to handle them (aka “what to fix”).

For the programming bots, how hands-off I am really depends on what work is being done.

For the majority of bug fixing: they’re all operating on fairly extensive documentation (written by me). And I always have at least 2 additional bots code review every change they make before sending those changes to QA for a regression pass.

That allows 90%+ of bug fixes to operate in a *mostly* hands-off way (other than me making the final call on what to fix or not… and, occasionally, with a little direction on how to implement the fix).

I’ve done some tests with a more “set it and forget it” approach with mixed results.

QA Pass -> Bug Fixing -> Code Review -> [Repeat X Times]

That process works well… until it goes way off the rails.

But if I keep myself in the loop, to guide the process, I’m finding the results to be incredibly productive.