Carsten Schmitz joined a software project to translate it. That was the job in 2004: help make PHPSurveyor usable in another language. It was a modest entrance into a project somebody else had started. Within two years, its original creator, Jason Cleeland, had handed him the project. In 2015, Schmitz would help form the company around it. The translator had acquired quite a few additional duties.
The sequence is worth lingering over. A translation is an act of attention to somebody else’s work. You take what exists, look closely at how it communicates, and make it accessible to another reader. In software, that reader is also a user trying to get something done. A button needs to make sense. A question needs to say what it means. An awkward phrase can become a practical obstacle.
Schmitz’s subsequent career stayed close to those obstacles. His public trail includes bug fixes, replies to contributors, questions about distributing the software, and lessons in building surveys. He is now LimeSurvey’s co-founder and CTO, based in Hamburg. The company title sits above a working history full of smaller jobs, each with someone waiting on the other side.
A translation, then a handover
PHPSurveyor began in 2003 with Cleeland, an Australian developer. Schmitz arrived the following year. Translation gradually gave way to bug fixing and support; in February 2005, he began assuming a leadership role. The full handover followed in 2006. The project became LimeSurvey in 2007.
Those dates describe a transfer of responsibility rather than a sudden invention. Cleeland’s place at the beginning matters. So does the interval between Schmitz joining and taking charge. Open-source work can give a contributor room to become useful before anyone agrees what to call them. In this case, the title eventually caught up with the work.
LimeSurvey’s purpose remained concrete: let people create questionnaires, distribute them and collect answers. A survey looks simple from the respondent’s side. Questions appear, boxes get ticked, someone presses a button. Behind that apparently tidy encounter are choices about language, access, branching and what to do with the results. Somebody has to make those choices possible.
The package that fell asleep
In June 2009, Schmitz introduced himself on a Debian bug-report thread as LimeSurvey’s project lead. He had asked Nicolas Barcet to package the application the previous year and had seen a working package. Then progress had stopped. His message asked for an update and for help finding a sponsor who could see the process through.
The exchange gives the career a useful change of scale. Leading a project did not mean knowing every procedure involved in getting it to users. Here was the project leader asking other people how their system worked. Software distribution has its own requirements and its own people. A working application still needs a route onto somebody’s machine.
Schmitz described the issue as having fallen asleep. It is a nicely domestic description of an uncompleted technical process. There was code. There had been progress. Now somebody needed to nudge the conversation awake. No grand declaration was required, just an inquiry from the person responsible for keeping the project moving.
Please send it again
A different kind of stalled conversation appeared in June 2013. A programmer named Larry Woods wrote to the developer mailing list with a complaint. He had offered to volunteer and believed nobody had answered. His message was irritated, and the opportunity to turn an administrative failure into an argument was readily available.
Schmitz replied that nobody had seen the email on the list and that it was absent from the archive. Perhaps it had gone to the wrong address, or bounced. He asked Woods to send it again, explaining that the project normally responded to applications of that kind. The answer stayed with the immediate problem: the missing message.
“Do you mind sending it (again), please?”
Carsten Schmitz, developer correspondence, June 2013
It is a small moment, but a revealing piece of the work. A project that accepts contributions has to maintain the entrance as well as the software. An offer of help can disappear into a mailing-list problem. Somebody who feels ignored may leave. Asking for the message again leaves room for the exchange to continue.
In October 2015, Schmitz answered another returning contributor, Mark Yeung, who had translated into Traditional Chinese. Yeung wanted to install LimeSurvey again and asked about a ComfortUpdate key. Schmitz asked him to create an account and share the username, and welcomed him back. The reply combined a practical next step with a brief acknowledgment of the person taking it.
These exchanges put names beside the abstract word “community.” They show separate people arriving with different histories and needs: a programmer who thinks his application has vanished, a translator returning to the software. Keeping a project open requires dealing with those arrivals individually. The welcome has to survive contact with the inbox.
A company with an open door
LimeSurvey GmbH was founded in Hamburg in 2015. Schmitz had also created LimeService, a hosting offer that later became LimeSurvey Professional and then LimeSurvey Cloud. The commercial organization grew around a project with a history of its own. Its work included providing services and coordinating the software’s further development.
The distinction between software and service remains visible. LimeSurvey’s Community Edition can be installed on a user’s own infrastructure. LimeSurvey Cloud supplies managed hosting. Those options address different appetites for administration. Some users want to run the system themselves. Others have a questionnaire to finish and would prefer that somebody else handle the server.
Run the survey software on your own infrastructure.
Use the hosted service and leave server operation to the provider.
The code is distributed under the GNU General Public License, version 2 or later. That makes the ability to examine, modify and redistribute it part of the project’s operating terms. The company also holds the LimeSurvey name and logo as trademarks. Shared code and an identifiable organization coexist, with separate rules for each.
For Schmitz, the company added an organizational setting to responsibilities already accumulated through the project. A 2018 conference programme called him CEO. His current GitHub profile calls him Founder & CTO, and his LimeSurvey biography identifies him as CTO. The technical role fits a public record still populated by releases, development questions and the workings of the application.
One issue at a time
Schmitz’s instructions on LimeSurvey’s bug tracker are brisk. Update before reporting a problem. Submit one issue in each report. Explain how to reproduce it. Where appropriate, attach a survey export that demonstrates the fault, reduced to a small test case. A report should give the developer something they can actually investigate.
He also tells users to mark reports containing sensitive material, or security issues, as private. The instructions explain that access will be limited to developers and describe how the submitted material will be handled. The practical demand for detail comes with attention to what that detail might contain. A useful example should not become an accidental public disclosure.
There is a familiar human negotiation inside these rules. The user sees something go wrong. The developer needs enough information to see the same thing. Both can be perfectly sincere and still talk past each other. A small, reproducible example gives the conversation a shared object. It is less dramatic than a complaint and considerably easier to repair.
Teaching appears in his record too. At GOR 2018, Schmitz and LimeSurvey software engineer Markus Flür were listed as instructors for a three-hour hands-on course in survey creation. The programme ran from simple survey construction to basic branching. In a branching questionnaire, one answer determines which question comes next. The software has to keep up with the respondent.
The workshop places Schmitz beside people learning to use the tool, with a colleague whose responsibilities included front-end engineering and customer support. It is a useful setting for this story. Building an application and explaining it meet at the moment someone tries to make their first survey work.
A lime you can spot in a corridor
By August 2026, the invitation to talk had acquired a light source. LimeSurvey announced that Schmitz was attending FrOSCon and told people how to recognize him: he was wearing a backpack with an LED logo. The accompanying photograph shows a glowing green lime and the company’s name on the bag.
The post also directed attendees to a sticker exchange where the company would leave its new stickers. The objects are small; the invitation is direct. Find the bag, have a chat. A software project that exists in repositories and browser windows also gets discussed between people standing in the same place.
Schmitz’s interests outside work include hiking, biking and geocaching. His biography gives most of his limited spare time to family. Those details keep the profile at a human scale: a person in Hamburg, with a long-running project, other people to look after, and reasons to leave the desk.
His GitHub status offers a compact joke about cooperation: “Apes together strong!” It sits above a profile tied to the company and its shared code. The September 2026 community release archive continues to carry his name. The small jobs did become a company. They also kept arriving: another release, another question, another person finding a way in.