Sindome has had 20 developers who have actively worked on it over the past 28 years. We haven't written every line of code. Sindome's core database was based on a LambdaCore from 1996. There were other developers who worked on the MOO code prior to that, and that probably makes up 50-100k lines of MOO code in our codebase currently. Just want to give credit where credit is due, we built on the backs of other developers as well.
I asked ChatGPT to give me a breakdown of typical enterprise business systems in terms of lines of code, team size, etc. It broke it down into small, medium, and large codebases. Here's what it said:
Small Enterprise Application
Codebase Size: ~50K - 100K Lines of Code
Example: Internal business tools, microservices, small web apps
Team Size: 5-15 developers
Tech Stack: Often a monolithic or small microservice-based backend
Medium-Sized Enterprise Application
Codebase Size: ~200K - 500K Lines of Code
Example: A corporate CRM, HR system, mid-sized SaaS platform
Team Size: 20-50 developers
Tech Stack: Typically a mix of frontend, backend, APIs, and third-party integrations
Large Enterprise Application
Codebase Size: ~1M - 10M+ Lines of Code
Example: ERP systems (SAP, Oracle), banking software, large e-commerce platforms
Team Size: 100+ developers
Tech Stack: Often a combination of multiple programming languages, microservices, and legacy systems
We fall on the upper end of a Medium-Sized enterprise application. You'll note the average team size for a medium enterprise application is 20-50 full time developers, acting in conjunction, working 40 hours a week.
These are for enterprise applications, which are often supporting large business applications and thousands if not tens of thousands of customers, which of course, we don't have. That reduces the overhead but I think the numbers are illustrative.
Okay, with the context setting and numbers out of the way, let's talk about the challenges. Why is it so hard to find coders for Sindome?
Niche expertise
MOO is not a common language. There is a very limited subset of developers who have ever played a MUD, let alone a MOO, let alone written any MOO code. I asked ChatGPT to calculate how many MOO developers it thought there were.
The broader MOO programming community (people writing LambdaMOO-style code, managing servers, or running game worlds) may number in the low hundreds, with fewer than 1,000 globally
Let's compare that to how many Javascript developers there are in the world:
As of 2024, JavaScript remains the most widely used programming language among developers worldwide. Recent estimates indicate that approximately 27.4 million developers utilize JavaScript in their work.
Even a language like COBOL, which was created in 1959 and has been kept alive by mainframe programming and banking systems, has an estimated 2 million developers worldwide.
So, we can agree we are looking for some very niche skills.
No Financial Gain
Usually, when you're looking for niche skills, you have to pay top dollar for them.
I asked ChatGPT what the average salary for a senior software engineer with niche skills was in 2025:
Senior software engineers possessing niche skills—such as expertise in artificial intelligence (AI), machine learning, cloud computing, or cybersecurity—can command significantly higher salaries due to the specialized nature of their expertise. For instance, senior-level cloud engineers earn an average of $160,000 annually, while senior machine learning engineers can see salaries ranging from $247,000 to $942,000, depending on their specialization and experience.
We can't afford to pay any dollars, let alone top dollar. So that further narrows our pool of potential candidates down to people who are passionate about MOO code or passionate about Sindome specifically, who are willing to work for free. It's difficult to attract interested parties.
If you're interested in more information about Software Engineering Salaries, you can check out https://levels.fyi.
Legacy Programming Language
The game itself is programmed in MOO. Specifically, the ToastStunt variant of MOO (server source is C++), which itself is a fork of Stunt (C++), which is a fork and partial rewrite of GammaMOO (C language), which was a fork of the original LambdaMOO (C language). The original release of LambdaMOO was made in 1991. Improvements were made, and for many years we were running on a version released in 1996, with some custom patches we wrote ourselves. We moved to ToastStunt several years back, which continues to be under development, and adds additional modern functionality.
There are open source projects out there that developers will contribute to for free, as labors of love or passion projects, but many of these are developed in modern languages, and the act of contributing to these open source projects looks good on a resume and builds technical & development skills.
While coders contributing to Sindome will definitely develop their skills, it won't be in a language they can go out and easily monetize their experience with. Thus, it isn't much of an incentive.
Learning Curve for the Codebase
As you may know, the bits of code that are executed by the MOO to make the game are called verbs. In some programming languages, these would be called functions, or methods. We have 16,736 verbs, and 350,000 lines of code which make up the MOO codebase. This is only the MOO code and does not include the server source code for ToastStunt (40,000 lines of code). Then there is the web client, the website, the grid, etc which together would add another 50-100k lines of code. That would put us somewhere around 500,000 lines of code.
Let's think about it like a book. If on average a typical verb has 10 words per line, that would give us about 5,000,000 words. An average reader can read about 250 words per minute. That's 20,000 minutes or 333 hours to read through all of the code we have. Assuming someone is able to devote 20 hours a week to learning the codebase, it would take over 4 months to read every line of code in our codebase which still doesn't mean actually understanding or internalizing what was read.
A developer doesn't need to read or understand every line of code in a codebase to be effective, but they do need to know and understand a good chunk of it if they are going to be effective.
I asked ChatGPT how long it took on average for a developer to onboard into a new job working in a medium sized enterprise system (300-500k lines of code). It gave me this general timeline, which seems to match my own experience:
General Onboarding Timeline for a Medium-Sized Enterprise Codebase (200K-500K LOC)
Phase
Duration
Activities
Week 1-2
Initial onboarding
Setting up the dev environment, accessing documentation, shadowing senior devs, understanding the architecture.
Weeks 3-6
Familiarization & Small Tasks
Reading core code, debugging, fixing minor bugs, and getting familiar with the development workflow.
Months 2-3
First Independent Contributions
Implementing small features, refactoring code, participating in code reviews, and engaging in deeper discussions about architecture.
Months 4-6
Autonomous Work & Deeper Knowledge
Handling major features, participating in design discussions, and contributing meaningfully to system improvements.
Months 6-12
Full Productivity
Owning components, mentoring newcomers, optimizing systems, and making informed technical decisions.
Keep in mind, that timeline is based on a 40 hour work week. A motivated developer might be able to onboard more quickly, but we're talking about volunteers, with limited time. We can't expect miracles.
It's a pretty daunting task to onboard into a codebase such as ours, and we need to hold our coders to a high standard, because if things break, the IC world can grind to a halt.
Trust & Restrictions
Trust further narrows down our field. We have strict requirements for bringing on an admin. Admin have access to a lot of systems! They can see your stats. They can see your door codes. They can see your private RP. We need to trust anyone we bring on has the best interest of the game at heart and is not going to cheat.
By their nature, coders need to have a level of access to the system that most staff do not need. Which further raises the bar in terms of trust.
We have had people play the game for a few days and xhelp asking to be coders. I truly appreciate their desire, but I don't know them. This is an internet stranger. They could be anyone, and they could have any intentions. They might be the best developer in the world, but if we don't know them from a hole in the wall, how can we bring them onto staff, give them access to restricted systems, and let them make changes to those systems? I would not feel comfortable with that. I don't know that the player base would feel very comfortable with that.
It's very hard to restrict what a coder can and can't access without also restricting how productive they can be. The more restrictions we might put on what a coder can do, the more hamstrung and frustrated they will be with the entire experience. And the more likely they are to give up on coding for Sindome and look for greener pastures.
If we require developers to run everything by a Senior Developer (Me, Johnny) then that Senior Developer becomes a blocker. If I'm not around, the developer is stuck. If I'm busy, and I rubber stamp changes without actually reviewing them, there is no point in having me as a checkpoint at all, since it's not actually accomplishing anything.
So we come back to trust. We need to trust our developers know what they are doing. We need to believe they have the best interest of the game at heart. We need to know that they aren't going to go off and make changes that will be harmful to the game. We need to know they understand the game, the staff, and the players well enough to recognize when a potential change or feature needs to be discussed before it is implemented.
Trust takes time to build. Especially online.
We've made exceptions to this several times in the past because we thought we could make it work, and every time it has turned out poorly.
Knowing the Game
It's not enough for someone to be a great developer, they need to understand Sindome. We've been online more than a quarter of a century and there is a rich history of IC lore, OOC policies, decisions around code, decisions around… everything.
Knowing the game isn't just about knowing the names of NPCs or Gangs, it's about understanding what fits and what doesn't fit the theme. It's about recognizing the specific vision for the game and coding things that support it.
That's one reason why we require that anyone who wants to join the staff do a tour as a Support GM. Could be joining to code, or build, or be a publisher, but you need to spend 3 months as a Support GM. There is no better way to build your knowledge of the game.
We've skipped this step in the past, let people jump right into coding or building, and we regretted it. We ended up with features, systems, and areas that did not match the vision for the game. It was confusing. It was frustrating. For the coder, and for everyone else.
It's a Marathon, not a Sprint
Sindome, in general, is a marathon, not a sprint. This is especially true for coders. They take the longest to onboard. And they need to be the most patient and thoughtful with the changes and features they introduce. We need full, complete, well documented systems that are going to stand the test of time. That is the only acceptable code to write for Sindome.
Throughout our history and the 20 different developers that have worked on the codebase, there have been many times that systems have been released poorly documented, partially implemented, and full of bugs. These systems, while cool, were a pain in the ass for everyone involved. They were confusing to players and admin who didn't understand how to use them, they were disruptive to gameplay when they broke or didn't respond as expected, and they were frustrating for the developers who came after that needed to puzzle through what was intended without good documentation so they could fix the problems.
Most developers I know would prefer to be working on new features and cool shit, rather than fixing bugs or writing documentation. This is especially true with people donating their time freely.
At work, I can ask a developer to write documentation and expect it will happen even if they don't want to do it. It's much harder to get a volunteer to follow through on something they don't want to do. It takes a level of dedication, patience, and self sacrifice to spend hours writing up documentation you don't want to write. Or to fully QA a feature you want to release. Or to request and then wait for a code review for someone who isn't around very much.
We need coders who understand that what they put into the game now, is going to need to be supported by future developers for the next 10-20 years or more. And used, in real time, by players starting the moment they commit their code to production.
Interconnected Systems
Sindome has a number of highly coupled, interconnected systems. The entire underlying codebase is very highly coupled. That means that changing something in one place, may have an unintended, unexpected, side effect on something else. This is how probably 40% of bugs happen. New coders are especially susceptible to this, as they haven't learned the ins and outs of the system.
It takes literal years to learn it all. This can be frustrating, as most coders want to make awesome stuff and do it right now, not in 2-3 years.
Training in our Codebase
Developers getting trained up at a job are usually supported by a team of 5-8 other engineers who work closely with them in their parts of the code. They can expect immediate feedback and answers to questions.
We can't provide that due to the volunteer nature, and Johnny and I having busy IRL schedules and families and such. We do our best, but training takes a long time, and getting answers isn't as immediate as it would be in a work environment.
Training to be a Developer
There are not nearly as many resources for learning MOO code as there are popular languages. I'm the one who wrote the ToastStunt documentation & rewrote the LambdaMOO programming guide. I maintain the LambdaMOO Programming resources Github. I think I'm the only one who's ever recorded any YouTube videos on how to code in MOO.
I can teach someone how to code in MOO. But my time is limited. I've mentored a number of GMs and Builders in how to code in MOO over the years. I can train someone who has no development experience, but it takes much longer. If someone does have development experience, it still takes a year of dedicated effort on their part, and a bunch of my time giving them feedback, support, and training. It was a lot easier for me to find the time 10 years ago than it is now. I still do my best to teach whoever on staff is willing to learn, but most of the effort needs to be self directed on their part, and there just isn't that much interest. Not everyone wants to be a developer.
Trolls & Bullshit
It goes without saying that volunteers on Sindome have to eat a lot of shit from trolls. Some people can let the bullshit slide off them. Some people decide it's not worth the effort.
Retention
There are a number of reasons that there are only a couple people from the total of 20 developers that have worked on the game over the years still coding.
There have been several developers who have left the staff over the years to create their own games. Nothing wrong with that. There is freedom in working on something from scratch without 20-30 years of history to consider.
People stop having a ton of time to devote to the game due to family or work.
People lose interest in the genre.
Trolls and bullshit happens.
Interpersonal drama between staff and players happens.
Coders have left because they felt they gave all they had and didn't have anything left to create.
People have left because they've been overwhelmed and they needed to pull back.
There are a lot of legitimate reasons people leave the staff, and there isn't much we can do to prevent it. Real life comes first.
Our Current Process
As I mentioned, our current process is to bring people on as SGMs. If they express an interest in coding, I will give them the resources to learn, and train them personally as time allows.
In Summary
It takes a lot of trust to join the staff, a long time to learn the code base and vision for the game, niche expertise, and a considerable commitment of time to be a coder for Sindome. It's not something that is easy to find, or easy to maintain once we do find someone.
There is no easy solution for earning trust, or learning to be a developer. There is no incentive other than love for the game to walk down the long path to being a developer. Many of the people that start down the path realize it isn't for them, or that they prefer being a GM, or a builder. Or they only want to do it a bit of the time. Or they really want to do it but can't find the time in their day between family and work.
We do our best to support those that want to become coders. And we will continue to be willing to train and develop talent, which given the niche nature of the MOO, is probably our best bet to have long term developers working on the game.
I hope this very long post helps clarify things for anyone who was interested!
– S
