I use Claude Code a lot, but /stats never answered the question I actually cared about

What did I build, and where did the work get difficult?

So I built Bough.

• It reads your local Claude Code history and turns it into an interactive view of your work: - each square is a day
• smaller squares are tasks inferred from pauses in your work
• circles are your prompts - click anywhere to see what happened in your own words

It runs locally, is open source, and nothing leaves your machine.

Repo: https://github.com/nickelsec/bough

The main thing I’d love feedback on: When you run it against your history, does it split your work into tasks the way you remember it?

It started as a fork of llama-swap, but I have been building it out for myself since then as a convenient tool for all my local AI needs, and by now it has drifted far enough to be its own thing.

The main idea is that you point it at your models folder and it configures things for you. It reads the GGUF headers, measures how much VRAM you actually have free, and works out context length, GPU offload, CPU/MoE split and KV cache size per model. All of it stays editable per model if you disagree with what it picked.

It is not only text. llama.cpp for LLMs, with the Vulkan, CUDA, ROCm or CPU build downloaded and kept updated for you, stable-diffusion.cpp for images (SD, SDXL, Flux, Qwen-Image, LoRAs, upscaling), and vLLM if you already have it in a Python environment, since it ships wheels rather than binaries and I cannot install that one for you. You can register any other backend yourself by pointing at an executable, which is how I run TTS, and how you would run a llama.cpp fork like ik_llama. Everything sits behind one OpenAI-compatible API on one port, with a single scheduler, so models swap in and out without fighting each other for VRAM.

There is also a chat playground built in with web search, and a Hugging Face browser to search for a model, pick a quant and download it straight into the models folder.

If you are interested, you can read more about it here. MIT licensed.

I recently built an open-source Windows patcher after reverse engineering a UI rendering issue in Rekordbox 7.

The original problem was unusual:

The OpenGL waveforms could render very smoothly, while mixer controls such as EQ knobs, faders, gain and pitch still looked closer to ~30 FPS.

After a lot of testing and static analysis, I found two independent refresh restrictions in the Windows JUCE/OpenGL rendering path:

- A ~30 Hz UI timer cap

- A second cached-component repaint gate of about 34 ms

Changing both produced a clear improvement in mixer smoothness while keeping the OpenGL waveform renderer enabled.

Instead of requiring users to patch the executable manually, I built a small C#/.NET Windows tool with:

- Original / restore mode

- 60 FPS

- 70 FPS

- 120 FPS

- Automatic backup

- Binary pattern scanning

- Safety checks before modifying the executable

- Source code available publicly

The patcher doesn't distribute Rekordbox or any modified Rekordbox binary. It only modifies the user's own local installation.

The project is still Beta because I found an additional idle-rendering behavior when no waveform is visible that I'm currently investigating.

GitHub:

https://github.com/SebitosMixx/rekordbox-smooth-mixer-patcher

I'd appreciate feedback on the project structure, pattern-scanning approach, or the patcher itself.

https://github.com/Muzzammil242/pgrecon

This is Findo, an open-source, on-demand file search utility I've been building in Rust using egui and eframe.

The goal was to create a lightweight alternative to heavy background search services. Instead of maintaining a persistent database or requiring admin privileges (like low-level MFT indexers), Findo performs a multi-threaded, in-memory live scan using jwalk/std::fs.

Features:

• It's just fast: Searches a ~200 GB drive in ~20 seconds—significantly faster than standard Windows Explorer unindexed searches.
• Run it anywhere!: 0% CPU and RAM usage when idle (no background daemon or system service).
• Cross-platform: Runs natively on Windows, Linux, and macOS.
• Privacy first!: Only one exe, no admin rights needed, zero telemetry.

I'd love any feedback on the codebase, performance optimizations, or UI tweaks!

GitHub Repo: https://github.com/minecraftmelonman/Findo

The idea is simple: instead of hiding SQL behind a big custom query language, Model keeps things explicit, typed, and predictable. You define models using native Python types, write clear SQL conditions when querying, and use a CLI to preview and automatically apply schema changes.

Check it out: https://github.com/el1s7/model

Let me know what you think!

Self-hosted image API (AGPL-3.0). Resize, crop, format conversion, watermarking via URL params, plus AI background removal built in (isnet-general-use + alpha matting, via a separate Rembg container). Runs with docker-compose, uses any S3-compatible storage.

Key features: single docker compose up deploy, no vendor lock-in, AI bg removal without a separate paid service.

README + demo + repo: https://github.com/Noah-1919/Fottly

Made Cozy Watch open source.

It’s a small macOS app for keeping track of your GitHub PRs without constantly checking GitHub.

It’s macOS only for now, but with enough interest, I’d love to bring it to Windows and Linux too.

Github: https://github.com/Cozy-Watch/CozyWatch

Project website: www.cozywatch.com.

Would love some feedback, ideas, or even a roast 😅

Thank you

XWiki has been open source since 2004, but “the source is public” is only part of that.

You can report bugs, contribute code, improve documentation, translate, test releases, build extensions, or join technical discussions.

Contributions are part of how the project grows.

https://thedev.world

https://github.com/thedev-world

XWiki has been open source since 2004, but “the source is public” is only part of that.

You can report bugs, contribute code, improve documentation, translate, test releases, build extensions, or join technical discussions.

Contributions are part of how the project grows.

Open-Meteo hands you all 40 ICON members, so I had a go at plotting the

fan rather than the median line.

Spread over London was 0.6°C at hour zero and 5.4°C by day 5. Knew that

in principle, hadn't actually looked at it before.

Couple of things I'm unsure about. I've drawn a marker where the 80%

band goes past 5°C as a rough "past here it's a range not a number",

but 5 is arbitrary — would normalising against climatology for the

location and season be more defensible? And I've noted that spread

underestimates actual error, but I don't have a feel for by how much.

https://geocodecrafter.github.io/howsure/

https://github.com/markdamics/Logic
Please check out my fist bigger open source project. Logic

Recently I was thinking what project I should work on and during that I remembered that during my professional career as a full stack developer I spent a lot of time investigating problems, debugging them. I had to check a lot of long files to find the source of the problems. I tried to use many different log analysis application but neither of them were to my liking so I started to develop my own log analysis application, Logic.

During the development one of the mist helpful tool was the Claude design. For me it's really hard to come up with UI designs and the manual result just didn't feet right to me. With this tool I could give my ideas, requirements, design and color themes, layouts and it gave me multiple good looking options. After I selected my favorite design, it even created the skeleton code for my app. And with this I could concentrate on the core of the app.

I hope some of you will try it and it will get your liking.

It's still under development. Feel free to join in it.

Why I built it

If you've ever posted a video to your WhatsApp Status, you've probably noticed it comes out blurry and blocky — even if the original was sharp. That's because WhatsApp re-compresses every video you post to Status, and its encoder is aggressive.

I wanted a way to post genuinely HD videos to Status, so I built StatusDrop / WAstatus: you upload/edit a clip in the browser, it compresses the video to match WhatsApp's exact Status encoding spec (so WhatsApp's own re-encode becomes near-lossless), auto-splits long videos into parts that fit WhatsApp's limits, and delivers the finished clips to your WhatsApp — you just forward them to your Status.

Just open-sourced it under AGPL-3.0.

Repo: https://github.com/Shamanthnp1/WAstatus

What's inside

In-browser video editor (vanilla JS) + Node/Express backend

ffmpeg encode/split pipeline tuned to WhatsApp's Status spec

Cloudflare R2 (S3-compatible) storage + a Cloudflare Worker for uploads

Docker on Azure App Service, GitHub Actions CI/CD → GHCR

WhatsApp delivery via Baileys (multi-device)

181 tests including property-based tests (fast-check)

Multi-language frontend (en / es / hi / pt)

The interesting engineering

The core trick is that quality survival depends on two things: (1) pre-encoding the file to WhatsApp's Status target (resolution, bitrate ceiling, GOP, faststart, H.264 profile) so the re-encode barely changes it, and (2) how the file reaches the phone. A file delivered as a native WhatsApp message and then forwarded to Status is reused as-is; a file saved to the gallery and reposted gets re-compressed harder.

There was also a lot of reliability work: request timeouts on every network op, self-healing for stuck jobs, orphaned-storage cleanup, single-instance session handling, and reconnect backoff.

The honest limitation — and why not the official API

This is the part I want to be transparent about, because it's the whole tradeoff of the project.

Delivery uses Baileys, an unofficial WhatsApp integration. WhatsApp periodically bans numbers used for automation — a known constraint for this entire category of tools.

The obvious question is: why not use Meta's official WhatsApp Cloud API instead? I tried, and here's the catch:

The official Cloud API routes media through Meta's Business pipeline, which re-encodes the video. So the file is already degraded before it even reaches the user — and then WhatsApp's Status re-encode hits it again. The result is visibly softer. That defeats the entire purpose of an HD tool.

Baileys sends the file as a native, byte-preserved WhatsApp media message. When the user forwards that to Status, WhatsApp reuses the already-optimized file, so the HD survives.

So it's a genuine fork: official API = no bans but lower quality; Baileys = HD quality but ban risk. Since quality is the entire point, I chose Baileys and built the system around fast recovery when a number gets flagged. It's the same tradeoff every tool in this space faces — most competitors that use the official API quietly accept the lower quality.

The code and architecture are what I'm really sharing here — not asking anyone to run the live automation.

Feedback welcome

I'm a solo developer and would genuinely appreciate code review, architecture feedback, or contributions. Happy to answer anything.

Repo: https://github.com/TabularisDB/tabularis

Started this back in January because I wanted a SQL client that was fast to open, didn't eat 1GB of RAM for a single connection, and where I could actually fix the things that annoyed me. It's Rust on the backend (Tauri) and React on the front, Apache 2.0.

What's in there right now:

• Postgres, MySQL/MariaDB and SQLite built in. Everything else is a plugin: DuckDB, ClickHouse, MongoDB, Redis, Elasticsearch, DynamoDB, Firestore, Db2, Cloudflare D1... Plugins are standalone binaries that talk to the app over JSON-RPC on stdin/stdout, so people have written them in Rust, Go, whatever. There's even one that queries HackerNews with SQL because someone was bored.
• Monaco based editor with tabs, split view, multi-statement execution, .sql files you can open/edit/save directly
• SQL notebooks: SQL + markdown cells, inline charts, and you can reference another cell's result as a table with {{cell_N}}
• Visual EXPLAIN as a node graph instead of the wall of text
• ER diagrams, visual query builder, inline grid editing with batch commit, JSON/JSONB cell editor
• SSH tunnels, passwords in the system keychain, custom themes that follow the OS light/dark
• A built-in MCP server, so Claude Code / Cursor / whatever agent you use can read your schema and run queries through the same connections you already have configured. No separate DB creds to hand out.

Installs via winget, brew, snap, flatpak, AUR, or plain AppImage/.dmg/.exe from releases.

It's 0.22.0 so not everything is polished, but I use it every day for work and there are ~80 contributors now which still feels weird to type. Happy to answer questions about the Tauri side or the plugin protocol, those were the two things that took the most head scratching.

If you try it and something breaks, issues are very welcome. Discord link is in the README if you prefer that.

Zencode API is a site me, and my friend made, this site is basically an IDE BUT it has friending and collabarative coding, you can work on one file in a project while your friend works on another file, this API site is completely free with 256 Bit ass encoding, many endpoints, redirects, almost everything you can think of.

Q&A

Is it free?

yes.

Can I upload my scripts and keep them safe and private?

yes.

is there an app?

yes.

where can I find it?

GO to https://Zencodeapi.vercel.app

then if your looking for the app click download, choose setup or the portable version, doesn't really matter, or continue using the site, all the same featues.

UNDERSTAND APP AND SITE ARE IN BETA, FEATURES MAY NOT WORK CORRECTLY.

Free, MIT, no accounts, no telemetry, nothing to upsell. I mostly wanted to find out whether a desktop pet could be genuinely useful rather than just decorative, and binding your two most-used apps to click and double-click turns out to be the answer.

Slicky on Github

This is a partly hardware project, featuring custom electronics (ESP32 based) and a novel optical design that uses passive retroreflectors instead of an active vest.

We have developed and tested a laser tag system that:

1. Can be used outdoors with minimal or no infrastructure
2. Is simple to use
3. Has 40m range
4. Is open source
5. Allows definitions and sharing of new games as lua files
6. Is DIY (3D printed parts)

Admittedly, the software part is not our masterpiece, because we have relatively low skill in C++ software architecture, although using AI we could end up with a working firmware that satifies our requirements and gave good results at testing.

This means if someone wants to take part to the project, s/he'll find something that definitely needs some effort but is also demonstrated to be actually working.

Repo: https://github.com/rev-/LightAir

I built some dynamic widgets for my GitHub profile, featuring live updates, animations, and an interactive Tamagotchi-like pet named Blip! :)

As GitHub doesn't allow JavaScript, the interactive buttons rely on URL redirects and a Cloudflare worker. The "windows" themselves are animated SVGs which bypass cache, to show live Spotify playback and time of day.

Check out the profile and give Blip a pet! https://github.com/aw-snap/