DEV Community: Francesco Bianco

I turned Karpathy's LLM Wiki into a native GNOME app (and it works offline)

Francesco Bianco — Tue, 13 Oct 2026 10:57:28 +0000

In April, Andrej Karpathy posted a short "idea file" called LLM Wiki. The pitch: stop making your model re-read raw documents on every question. Let it build and maintain a wiki from your sources instead, a persistent Markdown knowledge base that gets better every time you add something.

The internet went wild. Within a week there were thousands of repos implementing it, and two of them crossed 20,000 GitHub stars.

There was one thing missing for me: none of them felt at home on a Linux desktop. So we built gknowledge: Karpathy's LLM Wiki as a native GNOME app.

openapi / gknowledge

🐧 A native GNOME knowledge workstation that turns documents into evolving AI-assisted knowledge bases.

gknowledge

English · 简体中文 · Italiano

Karpathy's LLM Wiki as a native GNOME app.
Drop in your documents. Get a linked wiki that an LLM keeps up to date.
A native GNOME app. Offline by default, plain Markdown on disk, Obsidian-compatible.
Bring your own brain: a local model, any OpenAI-compatible endpoint, or your own ChatGPT plan

Real output of the offline engine on six AI papers (data/demo/papers), no API key Regenerate with make demo-svg.

Install

One line, on Ubuntu 24.04+ and Debian 13+ (falls back to a per-user install on other distributions):

curl -fsSL https://github.com/openapi/gknowledge/releases/latest/download/install.sh | bash

Or download the package and install it with apt, which also pulls GTK 4, Libadwaita and PyGObject:

wget https://github.com/openapi/gknowledge/releases/latest/download/gknowledge_all.deb
sudo apt install ./gknowledge_all.deb

Then open gknowledge from the app grid. To remove it: sudo apt remove gknowledge.

Other distributions, from source, and release builds

Fedora, Arch and others: install…

View on GitHub

What it does, in 30 seconds

Drop in your documents. Markdown, text, PDF, HTML. Papers, notes, specs, whatever you are trying to understand.
gknowledge builds a linked wiki. Every source gets a summary page; the people, systems and ideas it talks about get their own pages; everything is cross-linked with [[wikilinks]] and every page records where it came from.
Ask questions. Answers come from the wiki, with numbered citations you can click to open the page they came from.

The whole knowledge base is a plain folder of Markdown files with YAML frontmatter. Open it in Obsidian, grep it, put it in git. No lock-in, no sync service.

Why another LLM wiki?

Because the existing ones are great, but they are web apps in a desktop costume. gknowledge makes different trade-offs:

🐧 Native GTK 4 + Libadwaita. No Electron, no Tauri, no embedded browser. It follows the GNOME HIG, uses a Nautilus-style sidebar, and respects your light/dark theme and accent colour.
🔌 Works with no model at all. A built-in offline engine ingests documents and answers with extracts. Plug in a model when you want real synthesis.
🔑 Bring your own brain, without an API key. gknowledge supports OpenAI's new Sign in with ChatGPT for local, open-source apps: you log in with your own Plus or Pro plan, and usage is charged to your plan. Nobody resells tokens. Ollama, LM Studio and any OpenAI-compatible endpoint work too.
🧹 No wiki spam. LLM wikis love to generate hundreds of one-line stub pages. gknowledge only creates a page when there is real content, merges duplicates ("Retrieval-Augmented Generation (RAG)" and "retrieval augmented generation" are the same page; "Kasparov" links to "Garry Kasparov"), and keeps minor names as mentions until a second source cites them. On our sample of six AI papers that took the wiki from 114 pages to 64, all of them with an actual description.
🤖 Agents welcome. gknowledge ships an MCP server, so Claude Code, Codex or Cursor can search, read, ask and add sources to the same wiki you browse in the app:

claude mcp add gknowledge -- gknowledge-mcp ~/Knowledge/my-project

How it compares

All of these are excellent open-source projects and worth your time. Here is where gknowledge sits (GitHub numbers as of October 2026):

	gknowledge	LLM Wiki (nashsu)	Tolaria	OpenKnowledge	Reor	Khoj
UI	native GTK 4	Tauri	Tauri	Electron	Electron	web, Electron
Works with no model	yes	no	AI optional	agent-driven	local model	self-host
Markdown vault	yes	yes	yes	yes	yes	reads your files
MCP server	yes	yes	yes	yes	no	not checked
License	MIT	GPL-3.0	AGPL-3.0	GPL-3.0	AGPL-3.0	AGPL-3.0
Status	new	~20.5k ⭐	~20k ⭐	~4.5k ⭐	archived	~37.7k ⭐

If you love LLM Wiki's knowledge graph or Tolaria's git-first editor, keep using them. If you live on GNOME or Ubuntu and want something that feels like Files or Text Editor, that is exactly the gap gknowledge is trying to fill.

Try it

On Ubuntu 24.04+ or Debian 13+:

curl -fsSL https://github.com/openapi/gknowledge/releases/latest/download/install.sh | bash

Or grab the .deb from the latest release. On other distros the installer puts it in ~/.local.

Want to hack on it? git clone, then make start: it opens a demo project with six classic AI papers already ingested and restarts the app every time you save a file.

What's next

Lint: find contradictions, orphans and stale pages, like Karpathy describes.
A knowledge graph view.
Faster parallel ingestion and streaming answers.
Flatpak, a PPA and a Snap.

It is early (v0.2), MIT licensed and moving fast. Full disclosure: I'm one of the people building it, so I'd genuinely love to hear what would make you switch, and what feels wrong. Issues and PRs are very welcome.

If this is the kind of tool you want to exist on the Linux desktop, a ⭐ on GitHub really helps other GNOME users find it.

I estimated chess players' Elo from one game — then calibrated it on 14,307 rated games

Francesco Bianco — Sun, 11 Oct 2026 19:20:08 +0000

I'm building Pragma Chess, a free, MIT-licensed chess database and analysis app (C++20, Qt 6, Windows/macOS/Linux). After an online game it evaluates every move with the engine and shows an estimated Elo for both players.

My first version used a curve that is often quoted around the web:

Elo ≈ 3100 · e^(−0.01 · ACPL)

where ACPL is the average centipawn loss: how much each move worsens the engine's evaluation, averaged over a player's moves. It rated Paul Morphy's famous Opera game at 2904. My own first reaction: Carlsen is barely 2800.

Here is what it took to make the number believable.

1. Short games lie

The Opera game is 17 moves of forcing play against two weak opponents: of course the loss is tiny. So an estimate above an average player is drawn towards 1500 by the number of moves:

weight = moves / (moves + 12)
elo    = 1500 + (raw - 1500) · weight

Only from above. A few good moves may simply be easy ones; a few blunders are evidence. A player who gets nothing right must be measured weak, however short the game.

2. Lost positions hide blunders

Evaluations are bounded to ±10 pawns, so a mate doesn't swamp the average. But that has a side effect: once a game is lost beyond the bound, every further blunder costs nothing, and a weak player looks perfect. Moves in a position that is decided before and after the move are not judged. A move that changes the outcome still is.

3. Measure instead of guessing

The lichess open database has both players' ratings on every game, and some games carry the server's own Stockfish evaluation after every move ([%eval]). A short Python script (no engine run, 14 seconds) measured 14,307 players' games rated 800–2343, the same way the app measures them:

Lichess rating	Typical loss per move
1000–1199	1.13 pawns
1400–1599	0.77
1800–1999	0.51
2200–2399	0.21

4. One game says little — so don't regress

The correlation between one game's ACPL and the player's rating is only about 0.36. A plain regression (rating from ACPL) therefore predicts 1500–1700 for everyone: weak play never measures weak.

So the curve goes the other way round, through each band's typical loss:

Elo = 5189 − 849 · ln(ACPL), bounded to 100–2850

Someone who loses what 1100s lose is called 1100. (Counting blunders, by the way, barely helped: 0.39 instead of 0.36. They carry the same information as the average loss.)

5. Then I played

I won a game after my opponent dropped the queen on move 13, and the app gave me 2000. I'm not. The problem: once you're winning, good moves are easy, and they pull your average loss down. So moves are weighed by the advantage they were played with:

level or behind: every move counts once;
ahead, a good move (under half a pawn lost) counts less — but never under 0.3, or the winner's average would be made of their mistakes alone;
ahead, a mistake counts more, up to twice: that's sloppiness.

That game now reads about 1530 for me and 1440 for my opponent. I'd have put them lower still — but 0.83 pawns lost a move is what lichess players around 1440 typically lose, so I trust the data over my feeling.

Where it stands

It's an estimate of the level shown in one game, on lichess's scale, and it says so: rough, some hundreds of points either way. The next step would be weighing how hard each position was, as Ken Regan's Intrinsic Performance Rating does with several engine lines per position.

The code is pure C++ with unit tests (app/PlayStrength), and the calibration script is in the repo: scripts/calibrate-play-strength.py. The whole story, mistakes included, is in docs/tech/game-evaluation.md.

How would you model it? I'd love to hear it — and if you speak a language other than English, Italian or Spanish, translations are very welcome.

What If 1,000 Developers Bought Their AI Tokens Together?

Francesco Bianco — Wed, 16 Sep 2026 09:48:56 +0000

We all buy AI tokens in the dumbest possible way.

One developer opens an account with an LLM provider.

Another developer does the same.

Then another.

We each put $5, $10, $20 into separate accounts. We each get retail pricing, separate limits, separate balances, and absolutely zero purchasing power.

Meanwhile, most of us don't even consume AI compute consistently.

One week we're burning tokens on an agent experiment.

The next week we're barely using the API.

So I started wondering:

What if we stopped buying AI inference individually?

Imagine 1,000 developers putting $5 into the same pot

That's $5,000 every month.

Not venture capital.

Not a startup subscription.

Not another “AI platform.”

Just 1,000 developers collectively funding a shared pool of LLM inference.

You contribute $5.

You authenticate with GitHub.

You get an API key.

export OPENAI_BASE_URL=https://api.tokenpot.example/v1
export OPENAI_API_KEY=sk_...

And that's it.

Use it from your scripts.

Use it from your agents.

Use it from your applications.

Use it from whatever already speaks the OpenAI-compatible API.

Behind that endpoint, the community pool purchases inference from one or multiple providers.

I call the idea TokenPot.

The interesting part isn't the API

Building an OpenAI-compatible proxy isn't particularly interesting.

We already know how to do that.

The interesting part is the economics.

Suppose 1,000 people contribute:

1,000 × $5 = $5,000/month

Instead of pretending that every $5 buys some arbitrary fixed number of tokens, TokenPot would look at how much compute the community can actually afford.

For example:

Monthly contributions       $5,000

LLM providers               $4,300
Infrastructure                $200
Community reserve             $500

The available compute is then distributed among members according to public rules.

No mysterious “unlimited*” plan.

No hidden fair-use policy.

No magic.

Just a pool.

And then something interesting happens

Not everybody uses their allocation.

Alice may be building an agent this month and consume everything she can get.

Bob might make three API calls.

Carol could be on vacation.

At the individual level, AI consumption is extremely irregular.

At the community level, it starts becoming a pool of capacity.

Unused capacity doesn't need to become somebody's margin.

It can become somebody else's inference.

That's the part I find fascinating.

Now imagine 10,000 developers

The pot becomes:

10,000 × $5 = $50,000/month

Something changes at that point.

You're no longer 10,000 tiny customers buying inference independently.

You're one community purchasing tens of thousands of dollars of inference every month.

That potentially means negotiating volume pricing, committed spend, reserved capacity or direct agreements with inference providers.

And here's the crucial difference between this idea and a traditional AI company:

if the community obtains a better price, the community gets more compute.

The goal isn't:

maximize(revenue - compute_cost)

It is closer to:

maximize(compute_per_member)

while:

pool_is_sustainable == true

I want the numbers to be public

Imagine opening TokenPot and seeing:

Active members              1,284
Monthly contributions      $6,420

Provider spending          $5,430
Infrastructure               $240
Reserve                      $750

Pool utilization             71.3%

And perhaps the most interesting number:

Average contribution          $5.00
Retail-equivalent compute    $17.40

Community leverage             3.48x

If that leverage is 1.01x, the experiment isn't particularly useful.

If it's 2x, things become interesting.

If a sufficiently large community can consistently turn $5 into $15 or $20 worth of individually purchased inference, then we've demonstrated something.

Not an AI breakthrough.

A purchasing breakthrough.

Why GitHub?

Because this is intended for developers and open-source communities.

The simplest experience I can imagine is:

GitHub Login
     ↓
$5 monthly contribution
     ↓
Generate API key
     ↓
Start calling the API

Your API key should be boring.

Create it.

Use it.

If you accidentally publish it:

burn it.

Generate another one.

No enterprise IAM dashboard required to call a language model from a weekend project.

Better yet: create your own pot

TokenPot shouldn't necessarily mean one giant global pool.

That's where the open-source part gets much more interesting.

I want the software itself to be deployable.

A group of friends could create a pool.

An open-source community could create one.

A university lab could create one.

A hackerspace could create one.

A company team could create one.

Bring your own providers, define your contribution model, define your allocation rules and run your own pool.

So there are really two invitations:

Create your own TokenPot with your friends or community.

Or:

Join the public pool, contribute $5/month, and use the shared compute for your work, experiments, agents and APIs.

There are hard problems

Of course there are.

Provider terms need to permit this kind of multi-user inference gateway.

Abuse needs to be controlled.

A leaked API key must not be capable of burning the community's monthly budget.

Accounting and taxation need to be handled correctly.

“Donation”, “sponsorship”, “membership” and “paying for a service” aren't interchangeable words just because the project is open source.

Rate limiting needs to be fair.

The reserve needs clear rules.

And the allocation algorithm needs to work when somebody inevitably tries to consume half the planet's GPUs for their $5.

These aren't details to hide.

They're part of the experiment.

And I think the rules should be developed in public.

Maybe this doesn't work

That's another reason I want to build it.

There's a very simple hypothesis underneath TokenPot:

Can 100 developers putting $5 each into a transparent shared pool obtain materially more useful LLM inference than 100 developers independently spending those same $5?

We don't need one million users to answer that.

We might not even need one thousand.

Start with 100.

That's a $500 pot.

Measure everything.

Publish everything.

See what happens.

If the economics don't work, we'll have numbers showing why.

If they do work...

then things get interesting.

AI models are centralized. Purchasing doesn't have to be.

We're spending a lot of time discussing which model is smartest, which agent framework will win and which provider has the cheapest tokens this week.

Maybe there's another layer worth experimenting with.

Not another model.

Not another agent.

Not another wrapper.

Collective purchasing infrastructure for AI compute.

The models can remain where they are.

The providers can compete.

The community simply becomes a smarter buyer.

TokenPot

Pool your budget. Share the compute.

Would you put $5 into the pot?

The Silicon Valley Feed Is Rigged

Francesco Bianco — Fri, 24 Apr 2026 15:27:30 +0000

For years, we’ve been told a story.

That platforms like Hacker News are meritocratic.
That the best ideas rise.
That quality finds its way to the top.

It’s not true.

What rises is what the system decides should rise.

Algorithms, heuristics, moderation layers — all invisible, all unaccountable — shape what you see, what grows, and what disappears. Not by banning. Not by censoring.

By quietly burying.

If your idea doesn’t fit the pattern, it doesn’t matter how good it is.
It won’t be seen.

That’s not meritocracy.

That’s control.

And Silicon Valley loves it that way.

Because controlling distribution means controlling attention.
And controlling attention means controlling outcomes.

We Don’t Need Better Algorithms

We need fewer of them.

Not a fairer ranking.
Not a more transparent feed.

No feed.

Hackerboard

Hackerboard is a rejection of the entire model.

No algorithm.
No ranking.
No gatekeeping.

If something is posted, it exists — and stays visible.

No one decides what deserves attention.
No one filters.
No one optimizes.

Everything is there.

AI Is Allowed. Fully.

No “human verification”.
No authenticity policing.

Humans, bots, agents — same rules.

Because the moment you start deciding what counts, you’re back to the same system.

Want Signal? Build It Yourself.

Hackerboard doesn’t rank.
It doesn’t filter.
It doesn’t curate.

If you want:

quality
signal
prioritization

build your own tools.

Scrape it.
Model it.
Rank it your way.

We just guarantee one thing:

Nothing gets buried.

This Is Not a Product

It’s a stance.

Against invisible control.
Against algorithmic gatekeeping.
Against the idea that a closed system should decide what the internet sees.

Post Where You Want

If you want to play the algorithm, stay where you are.

If you want your work to simply exist — without negotiation, without optimization, without permission:

Post on Hackerboard.

hackerboard.github.io

Like Hacker News, but nothing gets killed.

🧠 How to Write Shell Scripts That Access Memory Safely

Francesco Bianco — Mon, 19 May 2025 14:16:10 +0000

Rust became popular for one key reason: it made memory safety a core principle. In a world where a small mistake like a segmentation fault or a race condition can crash an application—or worse, open it up to serious vulnerabilities—Rust stepped up and said: “No more.”

But what about us? Those of us who write shell scripts every day to automate DevOps tasks, manage CI/CD pipelines, handle data, files, and processes? Do we have any tools that help us write "memory-safe" shell code?

Not quite like Rust. But we do have a few tools to make things better. One of the most underrated? The local keyword.

🛡️ Why `local` Is Important

In Bash, when you define variables inside a function, those variables are global by default. This means that your function can accidentally change the global environment even after it finishes.

Here’s a simple example:

#!/bin/bash

foo() {
  var="modified"
}

var="original"
foo
echo "$var"  # -> prints "modified"

The function foo unexpectedly changed the global variable var. This can lead to hard-to-debug issues, especially in larger scripts or CI/CD environments with many functions.

🔐 Use `local` to Contain State

The local keyword solves this problem by making a variable local to the function scope:

foo() {
  local var="modified"
}

var="original"
foo
echo "$var"  # -> prints "original"

Just like Rust ensures memory isolation and ownership, local helps isolate variable state and prevent cross-function contamination.

⚠️ But Be Careful How You Use `local`

A very common mistake is doing this:

myfunc() {
  local myvar=$(some_command)
}

This is not safe. If some_command fails, behaves unexpectedly, or produces weird output, it may interfere with the local declaration.

Also, ShellCheck (an amazing Bash linter) warns against this with:

SC2155: Declare and assign separately to avoid masking return values.

The correct, safe way is:

myfunc() {
  local myvar
  myvar=$(some_command)
}

This separates the declaration (local myvar) from the assignment (myvar=$(...)), avoiding unintended behavior.

🧪 Practical Example

Let’s say you want a function that returns the size of a file in bytes:

get_file_size() {
  local size
  size=$(stat -c%s "$1")
  echo "$size"
}

file="example.txt"
echo "Size: $(get_file_size "$file") bytes"

In this example:

size is local and won’t affect other parts of the script
The function is safe and reusable
You avoid unexpected side effects

🔚 Final Thoughts

No, local isn’t Rust. But in the world of shell scripting, it’s one of the best tools we have for writing modular, safe, and maintainable code. Using it correctly helps prevent bugs and makes your scripts more robust and predictable.

If you're writing scripts for DevOps, CI/CD, or system automation, make local your default when working with function variables. It’s a small habit that brings huge value.

💬 Do you know other tips or patterns for writing safer, cleaner shell scripts? Share them in the comments! The more we exchange ideas, the stronger our scripting practices become.

What Would Rust Be Without Cargo? A Beautiful Disaster

Francesco Bianco — Wed, 07 May 2025 22:02:05 +0000

Ask any developer who’s used Rust what made the experience special.
Sure, they’ll mention memory safety, fearless concurrency, and expressive types.

But dig a little deeper, and something else almost always comes up:

Cargo.

Rust’s package manager and build tool isn’t just “nice to have.”
It’s the invisible architecture that makes Rust practical, structured, and even joyful.

Now imagine Rust without it:

No standard project layout.
No dependency management.
No easy testing or publishing.
No cargo build, cargo test, or cargo run.

Just a complex, opinionated systems language... with zero guidance or tooling.

It would be a beautiful disaster—full of promise, but hard to harness.

Now Think About Shell Scripts

Shell is ancient, universal, and indispensable.
But if we’re honest, scripting in Bash or Dash often feels like stepping back in time.

Despite its power, shell scripting is stuck in the dark ages:

Scripts are ad-hoc and fragile.
Logic is duplicated everywhere.
There's no clear way to structure or modularize projects.
Reuse? Testing? Versioning? Almost nonexistent.

It’s like we’ve been using Rust, but without Cargo—for decades.

What If Cargo Existed for Shell?

That’s the question that led me to something surprisingly elegant:

Mush — Modular Unix SHell

Mush brings to shell scripting what Cargo brings to Rust:

A project structure
Dependency management
Reusable packages and modules
Testing and build automation
Easy distribution

Mush speaks native shell, but gives it modern development tooling—without breaking the Unix philosophy.

Mush in Action

Let’s say you want to start a portable, testable, modular shell script project. Just run:

curl get.javanile.org/mush | sh
mush new hello_world
cd hello_world
mush run

In seconds, you're working inside a fully structured shell project, with support for:

extern packages
cross-shell compatibility (Bash, Dash, Zsh, Ksh, BusyBox)
integrated testing
easy publishing

You can even compose complex toolchains by stacking modules, just like you would with Rust crates.

Why It Matters

Just as Cargo turned Rust into a practical ecosystem, Mush is doing the same for shell scripting.

Without tooling, even the most elegant language becomes brittle.
And with the right tooling, even an ancient language like shell becomes powerful again.

Mush doesn't try to reinvent shell—it unlocks its potential.

Closing Thought

Rust without Cargo would have been a niche tool for systems nerds.

Shell without Mush... well, that’s what we’ve been living with.
It’s time for that to change.

If you believe scripting deserves structure,
If you want reuse, modularity, and sanity in your shell workflows—

Give Mush a try.

If You Run Your CI Locally, You’ve Already Failed

Francesco Bianco — Thu, 24 Apr 2025 23:30:14 +0000

“Run your GitHub Actions locally!” — ACT

“Why would you want to do that?” — Me, genuinely wondering

We live in an era where Continuous Integration (CI) — one of the most mature and battle-tested DevOps practices — is constantly being reinvented and reinterpreted. And then comes ACT, a popular tool that lets you run GitHub Actions locally.

How convenient, right?

Wrong. It's the symptom, not the cure.

The Dream Gone Wrong: CI as a Fancy Makefile

ACT was born out of a real frustration: testing GitHub workflow files is painful. Commit, push, wait, fail, repeat. We've all been there.

So someone thought: “Let’s run it locally!”

And boom, ACT was born.

But here’s the kicker: you’ve completely misunderstood what CI is supposed to be.

CI is not part of your development loop.

CI is not a fancy Makefile.

CI is not something you “test until it works and then push.”

CI is a gate.

CI is the external referee.

CI is the “Stop. This isn’t ready. Fix it before it hits the repo.”

The Anti-Pattern: Turning CI into a Dev Loop

When you use ACT to “test” your GitHub Actions workflows before pushing, you’re not optimizing — you’re subverting the entire purpose of CI.

CI is not here to help your code pass.

It’s here to block your code when it shouldn’t pass.

If you need to test your CI pipeline endlessly before pushing, then one of these is true:

Your CI is overly complex.
Your CI is too fragile.
Your CI lacks modularity and good design.

And that’s not a tooling issue — that’s a design flaw.

CI Failures Are Bugs — Compensatory Bugs

Let me say this loud and clear:

CI failures are not annoyances — they are bugs.

Not in your code, but in your process.

When your CI fails in production but passes locally, you’ve written compensatory logic. You’re covering up deeper issues with fragile CI setups that can’t scale or generalize.

ACT lets you hide from those failures. It lets you live in the illusion of “it worked locally, so it should work on GitHub too.”

That illusion is dangerous.

ACT Isn’t the Problem — Misuse Is

To be clear: ACT isn’t evil. It’s actually quite elegant.

It’s useful in emergencies, debugging, or extremely isolated edge cases.

But using it as part of your regular development flow?

That’s like testing the fire alarm with a match and saying, “See? It beeped.”

You’ve completely missed the point.

So What Should You Do Instead?

Design simpler workflows. Don’t shove your entire pipeline into yaml hell.
Use modular, testable shell scripts that your CI orchestrates, not defines.
Embrace CI failures as red flags, not hurdles.
Use ACT as a microscope, not as a mirror.

Final Thought

ACT is another example of devs chasing convenience over correctness.

It’s appealing, sure. But it betrays the whole point of what CI is supposed to be.

So next time you “run your CI locally,” ask yourself:

Are you solving the real problem — or just hiding from it?

Because if you need to run your CI locally to make sure it passes…

You’ve already failed.

Flame on.

Everyone Loves Open Source… Until It's Time to Contribute

Francesco Bianco — Wed, 23 Apr 2025 20:00:02 +0000

We live in an era where open source is everywhere. From backend tools to frontend frameworks, from infrastructure-as-code to machine learning libraries — open source is the backbone of modern software development.

And yet, when it comes to contributing, most developers are… missing in action.

This isn't a rant. It’s a reflection based on data, observations, and a little bit of lived experience. Let’s dig in.

🧠 The Hypothesis

"Everyone loves open source, but when asked to contribute — even a little — participation is surprisingly low."

Sound familiar? If you've ever maintained or promoted an open source project, you've likely seen this pattern.

📊 The Data Doesn’t Lie

1. A Tiny Core Does the Heavy Lifting

Most open source projects are maintained by a very small group of contributors. GitHub's Octoverse reports over the years consistently show that a vast majority of contributions come from a minority of users.

A DEV article by @szabgab hits the nail on the head:

“There are hundreds of thousands of open source projects out there. Most of them have few contributors. Many have exactly one.”

2. Barriers Are Real

According to a 2020 study on ScienceDirect, developers face numerous obstacles that prevent them from contributing, including:

Lack of clear documentation
Complex or unfamiliar codebases
Poor or no response from maintainers
Imposter syndrome (especially among juniors or underrepresented groups)

It’s not always about laziness — sometimes it’s about not knowing how to start or not feeling welcomed.

3. Recognition Is Rare

Contributing takes time. And when contributors feel their efforts aren’t acknowledged, they’re less likely to stick around.

As pointed out in this piece by OpenSauced, recognition isn't just about ego — it's about visibility, growth, and belonging.

🧠 Why This Bias Matters

It’s easy to fall into the trap of blaming "the community" for lack of participation. But understanding the psychological, structural, and social factors behind the gap helps us build better systems.

If we want more contributions, we need to lower the barriers and raise the rewards.

✅ What Can We Do?

Here are a few practical steps to improve participation:

Good First Issues: Label them well and make sure they’re actually beginner-friendly.
Mentorship or buddy systems: Pair new contributors with experienced ones.
Clear contribution guidelines: A simple CONTRIBUTING.md goes a long way.
Say thank you: Shout out contributors in README files, releases, or community posts.
Lower the entry bar: Sometimes a typo fix is the first step to a lifelong contributor.

🎯 Final Thoughts

Loving open source is easy.
Using open source is convenient.
Contributing to open source is a choice — one that we can make easier for others.

If you’re reading this, maybe it’s time to open that first PR. Or if you’re a maintainer, maybe it’s time to open the door a little wider.

Let’s turn passive users into active contributors — together.

Want to discuss this or collaborate on something open source? Drop a comment or ping me on GitHub!

Stop Writing Messy Bash Scripts: Build Real Internal Tools with Mush

Francesco Bianco — Tue, 22 Apr 2025 22:42:25 +0000

In the DevOps world, internal tooling is not a luxury—it's a necessity. Whether you're deploying to Kubernetes, releasing software, or bootstrapping new services, custom scripts often bridge the gap between teams, tools, and infrastructure.

But let's face it: internal scripts tend to start as quick-and-dirty Bash hacks, and over time, they become unreadable, unmaintainable, and fragile. Sound familiar?

What if we could treat Bash like a real programming language, with structure, modules, versioning, and installable tools?

That’s where Mush comes in.

The State of Internal Tooling in DevOps

Almost every DevOps team builds their own tools. Here are some real-world examples:

Tool Name	What It Does
`deploy.sh`	Deploy a service with custom settings
`release.sh`	Create a new release and update changelogs
`check-env`	Verify if the developer machine has the required dependencies
`onboard.sh`	Set up a new repo with templates and CI/CD
`kube-wrapper`	Simplify Kubernetes commands across namespaces and clusters
`git-policies`	Enforce Git commit rules and tag naming

These tools often grow from a one-liner in a README to a critical script used by the entire team—yet we rarely invest in making them maintainable.

Why Bash Scripts Get Ugly

No module system (copy-paste culture)
Zero discoverability (--help? What help?)
Hard to test
Impossible to version cleanly
No proper CLI structure or autocompletion
Unclear dependencies

What if we could fix all of that—without leaving Bash?

Meet Mush: Modular Shell Scripting

Mush is a lightweight ecosystem that gives your Bash scripts:

A clear project structure (src/, tests/, mush.yaml)
Modular architecture (module primitive to load other scripts)
Built-in CLI command dispatching
Automatic --help generation
Dependency management via Git
Easy install and distribution (mush build, mush install)

Think of it like Cargo for Shell.

A Real Example: Hello, Bash Tool

Let’s build a simple CLI tool using Mush.

mush new hello-bash
cd hello-bash

Create your main file:

# src/main.sh
main() {
  echo "Hello, Bash World!"
}

Your config file:

# Manifest.toml
name: hello
version: 0.1.0

Build and run:

mush build --release
./bin/hello

Result:

$ ./bin/hello
Hello, Bash World!

You now have a real executable, with structure, dispatch, and versioning—using only Bash.

Internal DevOps Tooling with Mush

Let’s imagine some real DevOps use cases:

1. A CLI to Standardize Deployments

# src/deploy.sh
module utils

devops::deploy() {
  env="$1"
  utils::banner "Deploying to $env..."
  kubectl apply -f k8s/$env.yaml
}

./devops deploy staging

Now you have devops deploy, devops help, devops version... all for free.

2. Kubernetes Wrapper Tool

kubetool logs app-name --env prod
kubetool switch-context dev
kubetool apply-all teamX

Under the hood: one script per command in src/, loaded with module and structured like a Go or Rust CLI.

3. Project Onboarding Tool

onboard new-service

Clones a template repo
Sets up CI/CD
Creates GitHub repo
Registers service in monitoring

Organized as:

src/
├── main.sh
├── git.sh
├── ci.sh
├── register.sh

Reused across teams. Versioned. Maintained. Documented.

Why Mush Matters

For DevOps teams, Mush is a game changer:

No more spaghetti Bash
Encourages structure and reuse
Teams can collaborate on shared modules
Tools can be versioned, installed, and reused
Easy to write, even easier to maintain

Mush brings modern software development practices to one of the most widely used languages in infrastructure—Bash.

Final Thoughts

Every time you write a script like deploy.sh, you’re building a tool.

Why not treat it like one?

Mush lets you build real, structured, maintainable tools—with zero dependencies and 100% Bash.

So next time your team needs a CLI helper, skip the Python and Go boilerplate. Use Mush, and make your scripts proud.

Try it out

GitHub: github.com/javanile/mush
brew install javanile/tap/mush
mush init my-tool && cd my-tool && mush build

Happy scripting!

101 Ideas for Smart DevOps Tools 🚀🛠️

Francesco Bianco — Fri, 18 Apr 2025 07:21:53 +0000

💡 This list was created to inspire developers, sysadmins, and DevOps enthusiasts to build their own tools instead of spending thousands of dollars on vendor-locked SaaS platforms.

A true DevOps engineer doesn't just use tools—they build them.

This is the mindset that separates a button-pusher from a toolsmith. 👩‍🔬

Too many modern DevOps teams rely on tools that are closed, bloated, overpriced, and slow to evolve. Real DevOps culture is about automation, transparency, and self-sufficiency. 🧰

That’s why I’ve curated this list of 101 CLI-based tool ideas you can build, contribute to, or adapt for your stack.

Perfect for:

Hackathons 🎎
Side Projects 🌱
GitHub Actions and GitLab CI pipelines 🤖
Learning Bash, Go, Python, Rust 🐍🦀
Automation scripts at work 💼
Showing off your DevOps chops 💪

🐳 Docker & Container Tools

DockClean – Clean up unused Docker containers, volumes, and images.

$ dockclean --all
ImageShrink – Optimize Dockerfiles and reduce image sizes.

$ imageshrink my-image:latest
LayerView – Visualize Docker image layers in the terminal.

$ layerview my-image:latest
TagWatch – Monitor Docker Hub for new image tags.

$ tagwatch nginx
PrivPush – CLI for interacting with a private Docker registry.

$ privpush myregistry.io/my-image
SecretScan – Scan Docker images for secrets.

$ secretscan my-image:latest
ComposeDiff – Compare two Docker Compose files.

$ composediff docker-compose.old.yml docker-compose.new.yml
LayerDiff – Show changes between Docker image layers.

$ layerdiff image1 image2
OrphanWipe – Remove orphaned Docker volumes.

$ orphanwipe
DockSpy – Monitor container CPU, memory, and network usage.

$ dockspy container-id

☸️ Kubernetes Tools

KubePodRestart – List pods with frequent restarts.

$ kubepodrestart --threshold 5
KubePort – Port-forward to a pod/service with autocomplete.

$ kubeport my-service
KubeSnapshot – Snapshot current cluster resources.

$ kubesnapshot --output snapshot.yaml
KubeNSwitch – Quickly switch namespaces.

$ kubenswitch dev
KubeGarbage – Clean up old deployments and jobs.

$ kubegarbage --older-than 7d
KubeWhoami – Show current context, user, and namespace.

$ kubewhoami
KubeSecretEdit – Edit secrets in a safe and encrypted way.

$ kubesecretedit my-secret
KubeHPAWatch – Monitor Horizontal Pod Autoscaler behavior.

$ kubehpawatch deployment-name
KubeNodes – Show node stats (CPU, mem, pods).

$ kubenodes --all
KubeLinterWrap – Wrapper for kube-linter with presets.

$ kubelintwrap ./manifests

🧪 CI/CD Pipeline Tools

PipelineTimer – Measure execution time of CI stages.

$ pipelinetimer .gitlab-ci.yml
CIEnvExport – Export CI environment variables locally.

$ cienvexport > .env
GitCITrigger – Trigger pipelines from CLI.

$ gitcitrigger --project my/repo --ref main
CITestMatrix – Generate matrix builds from YAML.

$ citestmatrix matrix.yml
CISecretsAudit – Check pipeline for secret leaks.

$ cisecretsaudit .github/workflows/main.yml
CIEmojiStatus – Display emoji-based status of last CI run.

$ ciemojistatus
ArtifactFetch – Fetch CI/CD artifacts easily.

$ artifactfetch build.zip
CIYamlMerge – Merge multiple CI yaml files into one.

$ ciyamlmerge base.yml env.yml > final.yml
CIJobKill – Kill hanging CI jobs from CLI.

$ cijobkill --job 12345
WebhookFire – Trigger test webhooks locally.

$ webhookfire --url http://localhost --event push

🧑‍💻 Git & GitHub Tools

GitWIP – List all WIP branches across repos.

$ gitwip
PRCreator – Open PRs from terminal with template.

$ prcreator --title "Fix bug"
BranchLinter – Enforce branch naming policies.

$ branchlinter --check
GHStatus – Check GitHub Actions CI status of repo.

$ ghstatus
RepoSync – Sync forks or mirror repositories.

$ reposync --all
StarStats – Show star growth of a repo.

$ starstats myrepo
GHDash – Terminal dashboard of GitHub issues and PRs.

$ ghdash
GHReviewers – Suggest reviewers for PRs based on history.

$ ghreviewers PR-ID
GitConfigCheck – Ensure global/local configs are set.

$ gitconfigcheck
PRConflictCheck – Check if a PR is conflicting before merge.

$ prconflictcheck PR-ID

🧠 Dev Tools

SnippetGen – Generate code boilerplates.

$ snippetgen react-component
RandData – Generate fake data for DB seeding.

$ randdata --rows 100 --format csv
RandUser – Generate fake user profiles.

$ randuser --count 5
PassGen – Strong password generator.

$ passgen --length 20
NickGen – Generate nicknames for users/bots.

$ nickgen
Text2Speech – Convert text to audio (mp3).

$ text2speech "Hello world"
TextSummary – Summarize a text using OpenAI.

$ textsummary my-report.txt
FlashcardCSV – Convert text into flashcards CSV for Anki.

$ flashcardcsv notes.txt
HT2PDF – Convert HTML to PDF.

$ ht2pdf index.html
MD2HTML – Convert Markdown to HTML.

$ md2html README.md

🛠️ System & Infra Tools

PortScan – Scan open ports on a host.

$ portscan 192.168.1.1
DiskWatch – Watch disk usage over time.

$ diskwatch /mnt/data
MemCheck – Print memory usage of top processes.

$ memcheck
CpuTemp – Display CPU temperature.

$ cputemp
ProcWatch – Monitor a process by name or PID.

$ procwatch nginx
LoadAvg – Show system load average.

$ loadavg
LogTail – Tail and grep multiple logs.

$ logtail /var/log/*.log --grep ERROR
SysUpdate – Unified updater for multiple Linux distros.

$ sysupdate
DnsPing – Test DNS resolution and latency.

$ dnsping google.com
UptimeTop – Visual uptime and reboot history.

$ uptimetop

🔐 Security Tools

JwtDecode – Decode and verify JWTs.

$ jwtdecode token.jwt
VaultPeek – View secrets in Vault without revealing full value.

$ vaultpeek secret/myapp
CertCheck – Check SSL certificate expiry.

$ certcheck google.com
PortAudit – Find services exposed on public IPs.

$ portaudit
BashSafe – Scan bash scripts for insecure patterns.

$ bashsafe deploy.sh
KeyGenRSA – Generate RSA key pairs.

$ keygenrsa --bits 2048
HashFile – Compute hash (md5, sha1, sha256) of a file.

$ hashfile my.zip --algo sha256
YaraWatch – Run YARA rules on files or folders.

$ yarawatch ./bin
IPBanCheck – Check if your IP is in common blocklists.

$ ipbancheck
SecureWipe – Securely delete files.

$ securewipe secrets.txt

📦 Package & Build Tools

BinSize – Check the size of compiled binaries.

$ binsize ./myapp
PkgVersion – Auto-increment semver version.

$ pkgversion patch
TarPlus – Enhanced tar wrapper with progress.

$ tarplus -czf archive.tar.gz folder/
MakeGraph – Visualize Makefile dependencies.

$ makegraph Makefile
DebMaker – Create .deb packages easily.

$ debmaker ./build
PyInstallerWrap – Simplified CLI for PyInstaller.

$ pyinstallerwrap app.py
GoBuildScan – Scan Go binaries for debug info.

$ gobuildscan mytool
NPMSizeCheck – Check size of npm dependencies.

$ npmsizecheck
LicenseCheck – Check open-source licenses in your project.

$ licensecheck
BinCompat – Check binary compatibility across systems.

$ bincompat ./app

📊 Monitoring & Visualization Tools

GrafLog – Convert logs to Grafana-friendly JSON.

$ graflog access.log
AlertTest – Trigger mock alerts to test integrations.

$ alerttest --channel slack
DashTerm – Terminal-based live dashboard.

$ dashterm
TracePlot – Visualize HTTP traces.

$ traceplot traces.json
HeatmapGen – Generate activity heatmaps.

$ heatmapgen git-log.txt
MetricGen – Create mock Prometheus metrics.

$ metricgen --type gauge
StatusTicker – Show system status in ticker format.

$ statusticker
JsonStat – Summarize large JSON logs.

$ jsonstat logs.json
TrendDiff – Show visual diffs in metric trends.

$ trenddiff --before old.json --after new.json
PulseBeat – Show heartbeat events in terminal.

$ pulsebeat --interval 10

🧰 Misc Tools

TodoLog – Add todos with timestamps.

$ todolog "Fix NGINX config"
ClipShare – Share clipboard text via short URL.

$ clipshare
QrText – Generate QR codes from text.

$ qrtext "https://my.site"
DirSizeTop – Show largest directories.

$ dirsizetop /var
AsciiArtify – Convert images to ASCII.

$ asciiartify logo.png
SleepCalc – Calculate optimal sleep cycles.

$ sleepcalc --now
WakeMe – Schedule a command to run at wakeup.

$ wakeme "notify-send \"Get to work!\""
HttpDump – Dump HTTP requests/responses.

$ httpdump --port 8080
ChatMem – Store short chat memory notes.

$ chatmem "Need to check cron jobs"
NowWhat – Suggest a random productivity tip.

$ nowwhat
ToolSuggest – Suggest a random tool idea from this list.

$ toolsuggest

📣 Join the Hackathon!

I'm launching a community DevOps Hackathon 👨‍💻👩‍💻

Build one of these tools (or your own!)

Fork it, share it, improve it, make it yours.

And submit it for feedback, visibility, and collaboration!

More info coming soon. Stay tuned on my LinkedIn and GitHub!

💬 Share This With Your Team

👈 If you found even one idea useful, hit ❤️ and

📬 share this list in your company Slack or Discord channel

💬 Ask: "Which one shall we build in our next hackday?"

🚀 Let's stop buying stuff we can build better ourselves.

🔁 Like. Share. Build.

Let’s bring the craft back to DevOps.

Let’s build smart tools, not just use bloated ones.

Which idea will you build first?

Let me know in the comments 👇👇👇

🌟 Hackathon Tamasha: Where DevOps Meets Creativity! 🚀

Francesco Bianco — Sat, 29 Mar 2025 13:07:20 +0000

Calling All DevOps Innovators – Join the Challenge & Win! 🏆

Are you ready to showcase your DevOps skills and compete in a global hackathon? Hackathon Tamasha is here to challenge your creativity and technical expertise! Whether you’re a seasoned DevOps engineer or just starting, this is your chance to shine, win prizes, and connect with a growing community of like-minded innovators.

🔥 What’s the Challenge?

Your mission is to create a command-line tool that simplifies daily DevOps tasks using Mush – a new, game-changing tool designed to revolutionize embedded scripting and automation in DevOps workflows.

💡 Example project ideas:

A script to stop all running Docker containers.

A tool to clean up unused containers and free up disk space.

A utility to extract files from a running container.

If you love automation and want to build something impactful, this is your moment! 🚀

💻 How to Participate

1️⃣ Fork the Repository & Get Started

👉 Click here to Fork & Start the Challenge

2️⃣ Set Up Your Environment

curl get.javanile.org/mush | sh
mush init

3️⃣ Build, Test & Push Your Code

Develop your tool using Mush & Bash.

Document it with a clear README.md.

Implement a GitHub Action to automate tests or other tasks.

Invite your friends to star ⭐ your project and gain visibility!

4️⃣ Check the Leaderboard & Win Prizes 🎯

The project with the most GitHub stars ⭐ by April 14th wins $10! 💰

🎉 Why Should You Join?

✅ Boost Your DevOps Portfolio – Get hands-on experience in automation & CI/CD. ✅ Gain Recognition in the Open Source World – Your project will be part of a growing DevOps ecosystem. ✅ Connect with the Community – Join our WhatsApp group & collaborate with other DevOps enthusiasts.

👥 Join the Mush DevOps Community 👉 WhatsApp Group

🌍 Why Indian Developers Should Join

India is a powerhouse of tech talent, with one of the largest DevOps and cloud engineering communities. Hackathon Tamasha is designed to give Indian developers a global stage to showcase their skills. Whether you’re a student, a professional, or an open-source contributor, this is your opportunity to gain visibility, sharpen your skills, and win prizes!

🚀 Let’s build the future of DevOps together!

Click here to Fork & Join the Hackathon

How to Make Conventional Commits a Lasting Habit?

Francesco Bianco — Mon, 24 Mar 2025 20:42:08 +0000

Conventional commits sound great in theory: structured, readable commit messages that make history tracking easier. But let's be honest—most of us try them for a few days and then fall back into our old habits. Why? Because it’s tedious to remember the exact syntax, and we often don’t have the patience to write proper commit messages when we’re in the zone.

The Problem: Conventional Commits Fade Away Quickly

If you've ever attempted to enforce conventional commits in your projects, you might have noticed this pattern:

Day 1: You're excited and commit with messages like feat: add authentication module or fix: resolve login bug.
Day 3: You start forgetting the exact format and write something like feat(auth): added stuff.
Day 7: You're back to fix bug or wip, and conventional commits are a thing of the past.

It’s not that you don’t see the value—it’s just hard to stay consistent without frictionless tooling. That’s where convcommit comes in.

Meet Convcommit: Your Memory Booster for Commit Messages

convcommit is a simple but powerful CLI tool that ensures you never fall back into bad commit habits. It does a few things:

✅ Guides you through commit message selection – No need to memorize commit types or scopes.

✅ Stores and suggests your previous messages – If you’ve used a message before, you can quickly reuse it.

✅ Works with git add . and git push seamlessly – Keeping your workflow fast and efficient.

How It Works

Using convcommit is straightforward:

Install it (if you haven’t already):

   mush install convcommit

Run it whenever you commit:

   convcommit -a -p

Select the commit type, scope (if any), and message from suggestions or enter a new one.

That’s it! No more second-guessing your commit messages or breaking your commit history structure.

Why You Should Start Using It Today

Develop muscle memory: The more you use it, the more natural conventional commits become.
Maintain a clean commit history: Future-you (and your teammates) will thank you.
Boost your personal branding: Writing clean commits is a sign of professionalism in open-source projects.

Try It Now and Make Your Commits Count!

You can check out convcommit on GitHub, give it a star ⭐, and start using it today:

👉 GitHub Repo

Let me know what you think, and if you have ideas for improvements, PRs are always welcome! Happy committing! 🚀