The Team Behind osTicket 2.0
Rewriting software isn’t just a technical challenge.
It’s a human one.
Code may live in repositories, but the real knowledge behind long-lived software lives in people; in the decisions they made years ago, the problems they solved, and the lessons quietly embedded inside thousands of lines of code.
That’s especially true for a project like osTicket.
For more than twenty years, osTicket has been shaped by real-world use. Every release carried with it the accumulated experience of administrators, developers, and organizations who relied on the platform to run their support operations. The result is software with a very particular kind of “DNA”: not the kind you can diagram easily, but the kind you recognize immediately when you’ve deployed it, depended on it, and upgraded it through the years.
Which meant that rebuilding the system wasn’t simply about writing new code.
It was about understanding what made the software work well in the first place and making sure we didn’t lose that DNA while preparing the project for what’s next.
Because the next era won’t look like 2003.
It won’t look like 2013 or even 2023.
It will be shaped by mobile-first workflows, real-time expectations, and a world where tools like AI will change how support is delivered, whether we like it or not.
More Than a Rewrite
In the early days of osTicket, development often meant small incremental improvements. Bug fixes. Feature requests. Iterative releases that gradually made the platform better for the people who used it every day.
That steady rhythm served the project well for a long time.
But eventually it became clear that incremental change alone wouldn’t be enough. The architecture that had carried the project faithfully for years had reached its natural limits, and moving forward meant evolving the foundation itself.
That realization led to several attempts over the years to modernize the platform.
Some were promising.
Some made real progress before stalling.
And all of them taught us the same lesson: rewriting mature software is rarely about technology alone. It requires patience, perspective, and a team willing to treat history as an asset and not a nuisance to disregard.
Assembling the Right Team
For a long time, the right path forward simply wasn’t obvious.
The challenge wasn’t finding developers who could write code. There are plenty of talented engineers in the world capable of shipping something new.
The real challenge was assembling the right team — people who believed in the project itself and were willing to study its history, understand its users, and rebuild the system carefully enough that the next twenty years would be easier than the first.
Being a bootstrapped project made that harder than it might sound.
We couldn’t simply throw money at the problem or hire a large team overnight. There were no venture rounds to fund a rewrite, no war chest to accelerate the timeline. Progress depended on patience, discipline, and gradually finding the right people who shared the long-term vision of the project.
So the team came together slowly.
Piece by piece.
And in many ways, that constraint turned out to be a strength.
Because the people who joined weren’t there for a sprint or the excitement of a flashy startup. They were there because they believed in the future of osTicket — and more importantly, in the value of building software grounded in open-source principles.
Over the last several years that team slowly took shape.
Not overnight.
And not in a single place.
Today the team behind osTicket spans two continents.
Part of the group works from Alexandria, Louisiana, USA where the project has long maintained its roots. Another part works from Eldoret, Kenya, where a growing team of engineers and contributors now helps drive the future of the platform.
For me personally, returning to my home country of Kenya was about more than geography.
Yes, it was about creating opportunity and about proving that meaningful engineering work doesn’t only happen in the usual places, and that building in Kenya can be part of building something global.
But it was also about stewardship.
Open source projects don’t survive on code alone. They survive because people care enough to keep building, to keep learning, and to keep showing up long after the novelty fades.
If osTicket was going to live on, it needed more than a rewrite.
It needed a team with the patience to do the hard work the right way.
A New Generation of Builders
One of the more amusing realities of rebuilding osTicket is that some of the people helping shape the project today weren’t even born when the first version was written.
Which tells you something about how long this rewrite has been in the making.
But it also says something encouraging about the future of the project.
Long-lived open source projects need renewal. They need new perspectives, fresh questions, and the energy that comes from people encountering the system for the first time and asking, “Why is it like this?” — the kind of question that forces everyone to separate habit from intention.
At the same time, the project still carries the experience of those who have lived with osTicket for years — people who understand the quirks, the legacy workflows, the upgrade paths, and the reasons certain decisions were made in the first place.
That balance between experience and fresh perspective turned out to be exactly what the project needed to move forward without leaving behind millions of loyal users.
It allowed us to rebuild the platform without losing what made it special.
Stewardship, Not Ownership
Open source projects often talk about community ownership.
And that idea matters.
But the reality of maintaining long-lived software is a little more complicated.
Too many cooks in the kitchen can be just as dangerous as too few — not because contributions are unwelcome, but because a project can lose coherence when features are added without a unifying vision, turning something once elegant into bloatware that tries to be everything for everyone.
Over the years I’ve learned that protecting the vision of a project sometimes requires saying no as often as saying yes. Adding features is easy. Preserving simplicity and coherence over time is much harder, and the cost of “just one more option” compounds until the software becomes harder to maintain and harder to love.
So yes, I’ve often played the role of what some might politely call a benevolent dictator.
Not because the community didn’t matter — quite the opposite.
But because protecting the long-term coherence of the platform mattered, and because someone had to be responsible for drawing the line between “useful” and “bloated.”
Ironically, osTicket naming was partly inspired by osCommerce, another early open-source project that showed what was possible when a community rallied around software.
But it also offered a cautionary lesson. Watching that project evolve — and eventually struggle under the weight of competing visions and fragmentation — shaped how I approached maintaining osTicket.
I honestly believe osTicket is still around, even after being forked to death, because of that discipline, and also because we protected the core of the platform even when it would have been easier to simply say yes to everything.
There’s a longer story there.
We’ll save that for another essay.
The Next Chapter
Rebuilding osTicket required more than rewriting code.
It required assembling a team that believed in the project and its long-term future; a team that could modernize the foundation without breaking the DNA that made osTicket trusted in the first place.
The work that led to osTicket 2.0 was not quick. It took time, patience, and the willingness to revisit assumptions that had been baked into the software for years.
But that foundation is now in place.
The platform has been rebuilt.
The team behind it is stronger than ever.
If osTicket survived long enough to outlive the web it was written for, it now has a team ready to carry it into the next one; from mobile-first experiences to AI-assisted support and whatever comes beyond.