Problems with Open Source

Photo by Pixabay on

Over the last month or so, I’ve had a fun opportunity to travel around and present at a small conference that my company hosts. And through those presentations and conversations, I’ve been thinking about (or talking about) a lot of the problems in security (or is it cybersecurity? IT security?). One of the themes that I’ve oft repeated is that open source software isn’t a solution to your budget problems. Those projects are “free” but… are they really?

Most places that I’ve worked over the years, they don’t invest in open source. There isn’t a license fee or a support fee to pay, so why bother? Yet, we’ll throw truckloads of money at companies on the promise that they’ll provide some level of support for the product they are selling. (And then eventually those companies get larger and have made enough money that providing good support is no longer a priority. Or they need to cut costs and the first thing that gets cut is the support team. Sigh, a different problem for a different post maybe.)

This lack of investment in open source is a major problem. Essentially, we are expecting developers to work for free. Many of whom are working on these projects outside of their normal day jobs because they are passionate about something (or once were passionate about something). Some projects get additional contributors, some projects die off… Some of these projects lead to major vulnerabilities because the code wasn’t maintained for years on end. It’s a problem.

So most of us sit back, don’t contribute to the projects we use in any meaningful way, open issues for those developers to fix the problems we are having (or add new features we want), and threaten to write our own versions when the maintainer doesn’t respond fast enough. It’s too bad we can’t through some corporate money behind those requests. Ultimately, if there were a chance of monetary gain, I suspect more people would be involved because… well, developers need to eat.

On the other hand, maybe we just have too much ego.

I’ve written a lot of scripts over the years, nothing too complex and not all open source, but I’ve run into some of these problems with my open projects. In one instance, I shopped around with people that wrote similar code and had their projects online. I specifically remember contacting one developer and stating, “Hey, I was wondering if we should merge our code bases. They do basically the same thing but I’ve added these features to mine and you have that feature to yours.” The response? Not interested. It was something along the lines of, “My use case is this one specific thing so I don’t want to add those features.”

In other cases, it’s been people hunting me down in email or user groups and asking for things. The expectation seems to be that I don’t have anything else going on and I need to add their features or fix their problems immediately. Often, when given specific code snippets from a person, I’ll invite them to be a contributor to the project. Their response?


There isn’t a response. It’s always the same.

There’s some level of ego here, I think. We’d rather strike out on our own and build our own project so we can have 100% control… because we know better than everyone else exactly what is needed. The thought: “why would I contribute to an established project when I could write it faster, better?” In reality, a project created and implemented by a team is going to be better over the long term. They’ll have better ideas make it into the project and, honestly, the project will stand a better chance of being maintained over the years.

Anyway, circling back around to the money problem…

Working on a team can be frustrating because there’s a level of compromise you don’t deal with as an individual. Sometimes ideas will come up that you don’t like or think aren’t worth doing – as an individual project owner, you have 100% control over this. As part of a team, you have to compromise with others. Compromise can be difficult. And compromising when you aren’t being paid to compromise? Yeah, it’s easier to just go your own way.

This whole opinion is less of a plea to pay fees for those projects and more of a warning that when you rely on open source projects, you have to be aware that there’s a hidden cost to you and your company. If that project were shut down tomorrow, would you be willing to hire a developer to keep the project alive? Would you be willing to fully replace whatever it is in your organization with an enterprise (read: expensive) solution to meet your requirements? Could your security program exist without that product?

In the end, you have to be willing to pay for something because nothing is ever really free. If you can live without that project, why are you using it? If it’s critical to your security program, why are you comfortable with it being a free product and no guaranteed support?

Did I have advice to give here?

Sort of.

If you’re a manager over a security team, hire a developer. Let them contribute to open source projects as part of their responsibilities to the team and keep these projects alive. If you’re a developer with a day job, advocate for a portion of your time to be allocated towards these personal projects so you aren’t spending nights and weekends working on this alone. Look for other developers that are also passionate about your project and invite them to be part of the team.

Let’s just stop trying to go it alone and thinking that we can always do better than the last person.

There are options to help fix this situation but none of it is free and that’s the thing everyone needs to come to terms with. Just because it’s open source doesn’t mean it should be 100% free.

%d bloggers like this: