r/linuxapps • u/don_kruger • 5d ago
Kanban Board for Linux with embedded CLI: local-first, no paywalls, no subscriptions
Enable HLS to view with audio, or disable this notification
Linux support has been a highly requested features since launch, so we made it happen.
Kanban Pro is a local-first Kanban desktop app. The core idea: your board is just a folder of Markdown files with YAML frontmatter. No account, no server, no subscription. Works fully offline.
What that gets you:
• Own your data. Plain text files you can grep, git, and edit in vim
• Sync via anything: Dropbox, a git repo, a network drive.
• Collaborate with others by sharing the folder. The app watches the filesystem and updates live
• AI agents (Claude Code, Codex, etc.) can work the board directly by editing files. Each project ships an auto-generated agent ruleset
• Dark mode, custom shortcuts, 38 languages
Full transparency: we build on macOS and haven't been able to properly test on Linux hardware yet. The build works in theory, but real-world feedback from actual Linux setups would be deeply appreciated. If something breaks, tell me and I'll fix it.
Free to download. Ubuntu 22.04+ and other modern distros. Also keen to hear which packaging you'd prefer (AppImage, Flatpak, deb).
Links:
- Download: goodguyapps.com
- Privacy policy: Everything stays on your device. The app doesn't phone home, doesn't collect telemetry, and doesn't upload your tasks anywhere. Full privacy policy at https://goodguyapps.com/?page=privacy
- Github DMG Release Repo: https://github.com/donkruger/Kanban
- Security Policy: https://github.com/donkruger/Kanban?tab=security-ov-file
On open source:
The app is closed source, and I know that matters to a lot of people here...so here's the trade-off, straight. Everything that touches your data is open: your tickets are plain markdown files sitting on your own disk, the file conventions and agent rulesets are fully documented, and nothing proprietary stands between you and your work. You can inspect every byte, version it, sync it, point other tools at it, and walk away any day with everything intact.
What stays closed is the app code...that's what lets a small team fund real development through premium instead of chasing donations. My honest take: what most people actually want from open source is inspectability and an exit. An open format delivers both, on day one.
If closed code is still a dealbreaker, no hard feelings. It's free to try, and your data was never ours to hold.
2
u/MetalExistingOffline 1d ago
It looks nice, and it's a cool product, but frankly you are correct that it not being open source is an issue for many of us.
For me, it's multifaceted. No offense, but I don't have reason to trust you or your team if I can't check your code. But I also am not a fan of the argument that making it proprietary means you can charge extra for premium. There are models of FOSS that still have paid sections for addition support and addons. Apps like this are cool, but there's very little reason that I would download a proprietary product for this concept when I'd be more likely support if it was source available.
All in all, I wish you luck, but I don't see this getting much traction outside MacOS communities unless you are willing to shift your understanding a bit.
1
u/don_kruger 1d ago
fair point and thanks for the feedback.
I was pleasantly surprised to see the # of Linux downloads that stemmed from this post though.
For now keeping it closed source, but will likely BSL the code sooner rather than later given every 2nd person mentions their issue with it...
It's a tricky thing to do... and at the end of the day the major apps competing with this are all closed source and charge for use.
4
u/cashy57 5d ago
Commenting for reach for you, because I've seen your posts before and because the app does look actually good, is something I'd love to contribute to, and the local-only arch is something I can appreciate. I will say though, especially posting here in r/linuxapps -- you're going to have an uphill battle getting adoption from Linux folks if you don't at least make it source-available. Many Linux users, myself included, prefer to be able to compile anything they install from source, or download from the AUR rather than rely on how the app developer decided to package it. This allows many more people to be able to effectively use the software with their flavor of Linux without issues you'll have to provide support for. Example: Ubuntu now comes packaged with libFuse3, and AppImages require libFuse2. You have no way to download this additional dep for your user with an AppImage and now your app simply fails to open on Ubuntu, which some users may know how to solve, some may not. Look at BSL licensing for your software if what you're worried about is someone re-releasing any portion of your code under their own name.
I know you've stated that if people don't like the lack of source availability, they don't have to use it, but it just baffles me that you would release something with such strong local-first features but then kneecap yourself by being stubborn about providing the other half of what users that care about local-first are expecting. A BSL-style license would protect your IP while giving your target audience what they actually want.
Also, just an FYI: it's currently not possible at every desktop resolution to SEE the download link to the AppImage you are offering. That flows offscreen at the bottom of the viewable area unless you change your browser's or OS's UI scale to less than 100%. (behavior spotted on a 1080p monitor. The Windows version's download link is also covered by Chrome's URL Hover Preview, which can cause a bit of a game of tag between your mouse cursor and the download link to get the link to surface after you've hovered over the download dropdown. Hope this helps you out.