YAKG: Yet Another Kerio GUI — Built Because I Wanted a Button

Today I built and open-sourced YAKG — Yet Another Kerio GUI.

It started for a very simple reason:

I wanted a button.

The Problem

For my software engineering job, I sometimes need to connect to a client's network through Kerio VPN so I can deploy and work with our systems inside their environment.

Recently, that meant deploying an embedding-based product category classification model on a client's servers.

Most of my colleagues use MacBooks, and connecting to Kerio is pretty straightforward for them. There is a GUI. You enter the connection details, click a button, and get on with the actual work.

I use a Lenovo IdeaPad running Ubuntu 24.04.

On Linux, the Kerio Control VPN Client is essentially a command-line experience. Configure it, control the service, inspect logs, figure out whether the tunnel is actually alive.

And yes, I know:

“You're a software engineer. Just use the terminal.”

I can use the terminal. I actually love the terminal.

But I also like GUIs.

There is no shame in wanting a button for something you do repeatedly. Being comfortable with the command line does not mean every interaction with a computer needs to become a small DevOps ceremony.

So I searched.

And searched.

I wanted a simple Linux GUI for Kerio.

Maybe there is one hidden somewhere in the depths of the internet, but I couldn't find anything that did what I wanted.

Normally, that would have been the end of the story.

Use the CLI. Get the work done. Complain about it again next time.

But then something else happened.

“Fine, Let's Build One”

A few days earlier, Cursor had released Grok 4.6.

I had been reading about the new model and its focus on longer-running coding tasks, and at some point a very obvious thought entered my head:

Why am I searching for this GUI? Let's just build one.

Not a startup.

Not a SaaS.

No landing page with “revolutionizing enterprise VPN connectivity.”

Just a small open-source desktop application that solves this annoying problem.

I opened Cursor, described what I wanted, and started planning the project with the model.

It proposed six milestones:

1. Detection and status
2. Service control — start, stop, restart, enable, disable
3. Connection control and real connection state
4. Configuration viewing, validation, and safe saving
5. Profiles
6. Tray, notifications, and autostart

That sounded surprisingly close to an actual desktop application rather than the tiny wrapper I originally had in mind.

So I started building.

A Few Hours Later

This is the part that still feels strange.

A few hours later, all six milestones were done.

YAKG could detect the installed Kerio client, control its service, determine whether the VPN tunnel was actually connected, safely manage configuration, maintain multiple profiles, and stay in the background with tray support and desktop notifications.

It had become a proper little GNOME application.

And importantly, the GUI itself does not run as root. Privileged operations are handled through the normal Linux mechanisms, passwords live in the desktop secret store, configuration writes are validated and backed up, and the application tries very hard not to turn “I wanted a Connect button” into “I accidentally created a security problem.”

Then came the moment that mattered more than all the generated code and completed milestones.

I installed it on my own Ubuntu machine.

I entered my Kerio profile.

I clicked Connect.

And it worked.

Perfectly.

I was connected to the client's network through an application that had not existed that morning.

That felt good.

What Exactly Did I Build?

I called it YAKG — Yet Another Kerio GUI, because the software world clearly does not have enough projects named “Yet Another Something.”

YAKG is a native GNOME frontend for the Kerio Control VPN Client on Linux.

It does not implement the Kerio VPN protocol itself and does not replace the official client. It simply puts a sane desktop interface in front of the Linux client that already exists.

Connect.

Disconnect.

Manage profiles.

See the actual connection state.

Forget which systemctl command you needed this time.

That's it.

And honestly, that's enough.

Not every open-source project needs to change the world.

Sometimes software can simply remove one irritating thing from somebody's day.

Building With AI Feels Different

The code is only half of why I wanted to write this post.

The other half is how the project came into existence.

There was a time when starting an open-source project like this meant accepting a fairly large cost.

You had the problem, then researched all the APIs and system behavior yourself, designed the architecture, wrote the boilerplate, built the UI, handled edge cases, wrote tests, debugged packaging, documented everything, and eventually—maybe—published it.

That cost naturally filtered which ideas became projects.

You had to care enough.

With coding agents, that equation has changed.

I still had to understand the problem.

I still had to decide what I wanted.

I still had to test the application on the real machine, inspect what it was doing, make decisions about behavior and security, and ultimately decide whether I was comfortable putting my name on the repository.

But the distance between:

“I wish this existed.”

and:

“It exists. I am using it.”

has become ridiculously small.

That changes what is worth building.

Open Source, Laziness, and Token Money

I keep thinking about what open source means in this new environment.

Traditionally, I imagined open source as people sharing their knowledge with each other.

Someone spends days, months, or years learning something, builds a tool, publishes the source code, writes documentation, answers issues, and makes the collective software ecosystem a little better.

That spirit is still there.

But I think AI adds a funny new version of it.

Sometimes open source is now just:

loving the field, being a little lazy, and throwing some token money at a problem for the love of the game.

And I don't mean “lazy” negatively.

Laziness has always been one of the great forces in software engineering.

We automate things because we don't want to do them twice.

We write libraries because we don't want to solve the same problem again.

We create abstractions because typing the same twenty lines for the hundredth time feels offensive.

My laziness was simply:

I don't want to manage Kerio from the terminal every time.

AI made the cost of acting on that laziness low enough that, instead of accepting the inconvenience, I could turn it into software and give the result to everyone else.

Maybe somebody running Ubuntu will search for “Kerio VPN GUI Linux” six months from now.

Maybe they'll find YAKG.

Maybe they'll install it, click Connect, and never think about any of this.

That would be enough for me.

Yet Another...

There is an old joke in software naming: Yet Another compiler, package manager, framework, tool, whatever.

The implication is that surely the world does not need another one.

Maybe it doesn't.

But today I needed another Kerio GUI.

So I built one.

And now there is one more open-source project on GitHub.

YAKG — Yet Another Kerio GUI.

Built on Ubuntu, on a Lenovo IdeaPad, with AI, some token money, a little laziness, and love for the game.

Sometimes that's all the reason you need to build something.