As we all know, real programmers in real client projects use one of seven architectural patterns, with the “Big Ball of Mud” being the most popular. Open-source software doesn’t have that luxury.
Whether it’s another JavaScript library all developers must learn this year, the newest Laravel technology, or an old elephant supporting the syntax from the previous decade, you can’t defend your poor architectural decisions with the usual excuses. The hosting stack is limited, there’s a low business value in doing it the future-proof way, the client wanted a shiny new button, blah, blah..
Maybe because, as an open-source project, you have to be ready to defend your decisions at any given moment—especially the ones that feel like your most stupid idea so far.
In a client project, no one outside your team really looks at the code. And when they spot the “compromise” or the “hard decision”, they don’t call you out. They know. They know the reasons, and they know the cost. They would do exactly the same. By the end of the week, they probably will. By the time marketing starts asking questions (most likely months from now), we can say “that wasn’t the best engineering decision, but it was the best decision for the project at the moment”. And our chairs will sink into the mud for another centimetre. Just another Tuesday.
But in open source, you could be doing the right thing for years. As soon as you try something different, you’re called out. As soon as there’s a new energy-efficient model and you don’t adapt to it, you’re called out. As soon as your code breaks someone’s carefully crafted custom environment, you’re called out. And calling out isn’t even remotely considered an inconvenience. It’s not pleasant, but it’s not really “client feedback” either. No time to explain? There are “saved replies”.
So, if direct feedback is not the top priority, what is the actual concern of an open-sourcerer?
What kind of server is it going to be hosted on? Every and any. You can’t specifically support or ignore. You don’t know where it’s gonna live, and you need to do everything you can to keep it alive wherever it is.
What coding standard are we going to use? Dewi likes PSR-12, but Mark insists on PER. He uses it at work, and it’s much cooler. Everyone wants PSR-4, but no one wants to touch that old, inherited, non-PSR-4 codebase. Obviously, you can’t let everyone use the standard they want. There has to be a common ground on a project-wide standard. It may not be your first choice, or the best choice overall, but the code in the project must be standardised. There was a time and place when this decision was made. You weren’t there to vote? Too bad. This is the standard now.
Is the new deployment going to break production? How about the web? Or almost half of it. “Testing it on staging” has a completely new meaning when your production is 43% of the web.
So, the next time you take a look at an open source project, still alive and more than five years old, and complain about its outdated architecture, coding standards, bad solutions… take a look at one of your client’s projects, older than one year, and tell me it’s not a ball of mud. Tell me it can survive the next 25 years as is, without an overhaul. And tell me you can stand behind every line of that code.