Common Misconceptions Around Open Source

Open source is “free” (as in Freedom), not “free” (as in Beer)

Government agencies and labs regularly show interest in commissioning and supporting open source software (software with source code that anyone can inspect, modify, and enhance) as a method to address various pain points they face. This interest warms my heart; I have been a big open source proponent for thirty years across dozens of organizations. Throughout my career, I have used open source software to build companies and solve business problems. I have managed, or have been responsible for, significant contributions to dozens of major open source projects and have created or sponsored at least five that are still out there, alive and roaring (I’m looking at you Airflow, Flyte, Presto/Trino, Superset, and Amundesen). I love open source; I really do – both from a philosophical perspective and a practical one.

Like all powerful tools, though, it’s easy to think that open source is the right tool for every job, a salve for all things software. Now that I am in the business of building proprietary software, I can also see the value in the proprietary software approach as well, and find the two approaches can be more complementary than I once imagined.

The bottom line is that open source software is appropriate for some use cases and proprietary software is appropriate for others, but neither is a silver bullet. Before you make this decision, it’s important to deeply understand the problems you are trying to solve and realistically evaluate your options and your organization's technical capabilities.

This blog covers three key considerations about open source vs. proprietary software:

• “What does “free” mean?”. While open source software does not come with a sticker price, adopting an open source solution can and will still cost significant money over its lifespan. Think free (as in freedom) vs. free (as in Beer).
• Open source software needs to be maintained. Just like owning a car, you are either your own mechanic, or you need to hire someone else to be your mechanic. Though someone might give you a car for free, it won’t work if you don’t maintain it, fuel it, change the oil regularly, and fix it when it breaks. It’s the same with open source software. It’s great if you have the technical skills to do it yourself, but few do, which means hiring someone to do it for you.
• Proprietary software is like a train, not a car. In proprietary software models, maintenance and evolution are supported by all users who buy a seat (aka license) or a subscription at a predictable cost. The cost of maintenance is translated into the cost of the software.    

What does “free” mean?

Free (as in freedom) vs. free (as in Beer)

This is a paraphrase of a longer quote by Richard Stallman in 2001. It attempts to point out an ambiguity in the English language, that the word “free” has multiple meanings. It’s also sometimes encountered as Gratis versus Liber, invoking Latin, which has separate words for these two concepts.

Open source is “Free” as in “Liber, or as in “Freedom.” It guarantees that “users have the freedom to run, copy, distribute, study, change and improve the software.” It’s free the same way we enjoy free speech and the right to assembly.

Open source licenses also often come with strict requirements aimed at preserving that freedom. They can include clauses on how users MUST give back to the community. Often, any time users “change and improve” the software they are required to commit it back to the project, sometimes the licenses can include restrictions on commercial applications. Some licenses (called copyleft licenses) require that any derivative work of the copyleft-licensed software be released under the same license as the original software. In other words, the modified code has to be exactly as “open” as the original. One of the practical ramifications of this requirement is that the users may be forced to publish their own software as open source, regardless of whether they want to.

Users must understand the particular license associated with the software, or they can easily damage themselves. The government normally doesn’t use such licenses; it often releases the software into the Public Domain, meaning anyone can use it, including integrating it into proprietary software. So these requirements can come as a surprise to government departments.

Open source is most certainly NOT free, as in “gratis.” Using open source software always costs labor, cash, or both. Although it can appear to be “gratis,” as there is no charge to download and install a piece of open source software, thinking this way denotes a misunderstanding about the actual cost of software, bringing us to the next key concept.

Total Cost of Ownership

Car ownership is a good analogy to understand total cost of ownership. If you own a car, how much does it  REALLY cost over the time you own it? Anyone who has owned a car knows that this number far exceeds the sticker price, including expenses like:

• Insurance
• Gas (or electricity, we would prefer electricity)
• Maintenance (replacing brakes, tires, wipers, etc.)
• Repairs (over and over if it’s a Jeep)
• Parking (lots, and tickets)
• Etc. etc.

How this total cost compares to the sticker price can vary significantly based on the age and quality of the car, if you are buying a Jeep Wrangler versus a Toyota Corolla for example your numbers may differ by an order of magnitude, even if the sticker price is the same. Don’t buy a Jeep. I know they look cool. Don’t do it.

As the New York Times reported, a Floridian spent $6,083, or 33 percent of the entire cost of a reliable used Corolla ($18,240) in one year of ownership. And this was without any serious car repair.

Open source software needs to be maintained

Open source software requires you to either be your own mechanic or hire someone to maintain it for you.

Maintaining software is no easier then maintaining a car, in fact, it can be harder. Software breaks, often at the most inconvenient time (just like a car does). Software must be upgraded and kept current, or it will become a security risk or violation (just like your car needs its yearly maintenance or you're out of warranty). Most of the software we use in land management is fed by data (it’s our gasoline) that must be collected, formatted, and reformatted over time. Data changes format unexpectedly, and breaks software with disturbing regularity. Different open source components must be integrated and customized; those customizations and integrations also break (why does my Apple CarPlay stop working randomly? Why, Apple, why?). Users of software need to be trained or train themselves on the new version of the software and then possibly rewrite their own dependent code and analysis if the changes are not backward compatible.

The maintenance requirements of open source software are extensive. Big tech companies employ entire teams of top-notch software engineers to maintain and enhance the open source software they rely on. Maintaining open source software is significant work.

Even open source software proponents do not claim that open source software is “free” as in “gratis;”, rather they go to great lengths to set expectations with their potential users (“there ain’t no thing as a free lunch”). So why is open source so popular? This question brings us to the third important concept.

The numbers look much better when you are your own mechanic

Being your own mechanic is a pretty obvious extension to the car analogy. We all have those friends who never have to take their cars to the shop; rather they have the skills and background to fix their cars at home. I am not one of those people. I envy those people and want to be like them, especially when I look at the bill from the mechanic. My own personal “person I envy because he can fix his own car” is called Phil, so I’ll use him as an example.

It is not true that Phil doesn’t pay anything when his car breaks down. He still often needs parts and complains bitterly about the price of parts. He sometimes goes to the junkyard or conducts shady deals in back alleys for parts. Occasionally, his shady parts explode. But he doesn’t pay for labor. At least not in money; he pays for it in his own time. And the added risk of dying in an explosion.

Phil has some other advantages over me. When his car breaks down on the side of the road, sometimes, he doesn’t have to get it towed. I’ve seen him fix it on the side of the highway. He doesn’t have to wait days in line for the mechanic to get to him. He can start working on it right away. His car is always the top priority in his own personal queue of “cars that need to be fixed.” He can modify his car. In my opinion, he shouldn't, and things occasionally explode when he does, but he can. He also can buy beat-up cars, work on them, and make them awesome. He can get deals.

This doesn’t mean that Phil can always fix his own car. Sometimes, he needs tools he doesn’t have. Sometimes, he rents garage space for those tools; sometimes, he even (gasp, horror) has to take the car to the mechanic. But even when he does this, he has an advantage. He knows exactly what they are proposing to do with his car, can negotiate the price, and avoids getting upsold on unnecessary or premature repairs.

Phil is awesome. I wish I were like Phil. But I’m not and never will be, since to become so requires decades of study and practice. This analogy leads us to why open source software is so popular among tech companies. They can be their own mechanics. They are already running their own garages. They often make deals with other tech companies to ONLY work on specific projects (like how a rental car agency only offers certain models of cars).  

When you are running many open source projects across your company and can easily hire top-tier engineers to work on them, when you are piggybacking on a project that half of Silicon Valley uses to run their companies (like Linux, Apache, Postgres), the total cost of ownership numbers shift pretty dramatically in your favor. Your beer is still not free, but you are brewing your own beer, so it costs less. And you are part of a beer brewers alliance.

Of course, engineers' time is not free; it’s actually pretty expensive. Phil’s time is not free; it just doesn’t cost him money. This all works okay if you have a hundred such projects, and you hire a small team, and they are always busy. It works less well if you have one or two such projects and your hire sits around twiddling his thumbs and playing Doom unless something breaks.

Also, the total cost of ownership for different open source projects is not always the same. Just like some cars are junkers (Consumer Reports is looking at you, Jeep), some open source projects are also junkers, and you should run screaming from them.

Even top-tier tech companies think long and hard about using an open source software project and often choose proprietary software if something is out there that ‘Just Works.’ Even top-tier tech companies hire other companies to help support their open source projects. There are whole multi-billion dollar industries and companies built around just supporting a particular open source tool or technology (e.g., Red Hat, which maintains the Linux code base that hundreds of companies rely on. It’s a $34b company).

So what does that mean for you as someone considering implementing an open source project at your company? Remember that open source isn’t “free as in beer.” The cost is often unpredictable (just like the cost of a car); some open source products are older, very stable, and very reliable, but even those products need care and feeding. You need to make a decision: are you going to be your own mechanic, or are you going to hire one? Or both? It's all going to cost money.

Proprietary software is like a train, not a car

So, when does proprietary software make sense?

To continue our analogy, proprietary software is more like a train than a car. Trains make sense when many people want to go in the same direction. The infrastructure that supports them (tracks, signals, right of way, etc.) is more expensive upfront. My friend Phil would never build or buy his own train. But if enough people want to go in the same direction, trains end up being cheaper (and more environmentally friendly – ride the train, the planet will thank you). As a user of the train, you don’t have to worry about maintaining the train. You don’t have to know how to drive it. You don’t have to take it to the shop, buy insurance, put gas in it, fix it if it breaks, etc. All that stuff is built into your ticket price or paid for by your tax dollars. You buy your ticket, you get on it, and it just works.

Proprietary software is similar. The software will not try to do everything, just like a train goes only where the tracks go. Proprietary software is generally built to take a person from point A’ish to point B’ish.

For multijurisdictional land management, there is a lot of commonality in where people are coming from and where they need to go. The route is hard enough and far enough that you aren’t going to just walk it. It’s an excellent opportunity for train building.

We understand everyone’s needs are somewhat different. You are probably going to need to take a taxi, a bus, or walk from that station to your true destination, and we need to make that easy for you. We call that “customization,” and all such software will support it. But if you aren’t “generally” going from SF to Sacramento, say you want to go to Honolulu instead; that particular train is probably not for you.

Proprietary software also has its own equivalent of pooling dollars and spreading costs evenly, called Venture Capital (VC). You don’t have to pay upfront to build the train; even the entire first wave of ridership of the train doesn’t have to pay for it; everyone's first ticket isn’t a billion dollars. VCs will fund building the train and laying the tracks with the expectation that they will get that back plus profit over a period of time. The users pay for the train eventually, but the first tranche of users foot only a proportionate amount of the bill. Unlike open source software development, where the organization that creates the project initially tends to shoulder the lion's share of the cost.

And one of the most crucial selling points for trains is that the ticket prices are predictable. We all know the pain of “Oh crap, I just got saddled with a $5,000 mechanic bill that I cannot pay.” When I was managing a large department and a similarly large budget I valued predictability in costs. Costs that can be spread out over time, costs that are clearly forecastable, costs that I can easily explain to my CFO what the drivers are, costs that are linked to the goals I am trying to accomplish, or the size of my workforce. I hated surprises. All of this was a lot more manageable than “yeah, this open source library choked when we had to upgrade Python to patch the security vulnerability, and so I had to pay a consultant $20k; sorry about that, and yes, it will happen again, but I cannot tell you when.”

Finally, a warning: People will lie to you or misrepresent this stuff. They will tell you their train goes to Honolulu when it doesn’t. They will tell you that they can come in and build you an open source thing and then it’s free beer for all of time. Then, they will happily charge you hourly consulting at a high rate to maintain it until the end of time. They will even sell you Jeeps. THERE ARE ENTIRE DEALERSHIPS JUST TO SELL JEEPS! How is that legal?

There is no magic panacea in the real world. Trains make sense under some circumstances; I love trains. Cars make sense under some circumstances, I love cars. Neither is free, no matter what the guy at the used car dealership tells you. Pick the one that is right for you based on your expertise and willingness to roll up your sleeves and get engine oil all over you.  

Our approach at Vibrant Planet

We founded Vibrant Planet out of a sense of urgency to solve the wildfire and climate crisis. To rapidly build, test, and deploy our platform, we attracted early support from top impact-investors.

We’ve structured Vibrant Planet as a hybrid public benefit for-profit corporation and an open source non-profit organization to leverage the best of both worlds to support scientific innovation and accelerate climate and wildfire resilience. To understand how this structure works, we need to dig into both the philosophy of open source and the practicality of maintaining the software as well as building it and compare that to proprietary software, which is a fundamentally different business model.

Traditionally, in the natural resources space, public and private grant funding availability has limited the capacity for rapid response and often encouraged the building of a myriad of small, unsustainable point solutions.

Mandated grant timelines and requirements have been beholden to specific, disparate priorities. Grant-funded solutions often whither when funding runs out.

Grants are also typically too small to fund the building of holistic systems. In our case, we saw the need for a robust system leveraging the best cloud compute and machine learning has to offer to attempt to mimic the complexity of nature. This system needed to support scenario planning, forecast what interventions might work best to protect communities and enhance ecosystem services like carbon sequestration, water, and biodiversity in various socio-ecological contexts worldwide. This was not a grant-fundable concept.  

Our subscription model, supporting a diverse customer base, enables us to continuously improve our products to be more powerful, effective, and adaptable to changing needs.

As a public benefit corporation (PBC), fostering positive social and environmental impact is core to our mission. We sincerely believe this is an all-hands-on-deck moment, and it takes the collective ingenuity of our public and private partners to face the enormous climate challenges at hand.

Part of our public benefit is making novel data products we build publicly available for scientific and educational pursuits. This includes not just the data itself, but the scientific methods that created the data. Peer review is such a critical part of the scientific method, that, regardless of whether the software that executes the science is proprietary or not, the science itself must be publicly available. Whether or not to rely on open source is a choice for software, depending on the circumstances, but open science is not a choice, it’s a necessity. As you will see in our next blog post.