Tag Archives: Open Source

A Different Viewpoint of Lock-In

Posted on by
Reply

First things first: Go watch this great video on lock-in from Ethan Banks (@ECBanks). We’ll reference it.

Welcome back. Still carrying that pitchfork around screaming about how you want to avoid vendor lock-in? Ready to build the most perfect automation system in history that does multi-cloud, multi-vendor, multi-protocol networking in a seamless manner with full documentation? Nice. How hard was is to build that unicorn farm?

I get it. No one wants to be beholden to a specific vendor. No one likes being forced into buying things. Everyone hates the life of the engineer forced to work on something they don’t like or had to use because someone needed a new boat. Or do they?

Ford and Chevys and Dodge, Oh My!

What kind of car do you drive? Odds are good you’re either ready to get a new one or you’re proud of what you’re driving. I find that the more flashy a car is the more likely people are to talk about how amazing it is. And when there are two dominant manufacturers in a market for cars, you tend to see people dividing into camps to sing the praises of their favorite brands. Ford people love their trucks and won’t hesitate to decorate their bumpers with stickers about the uselessness of a Chevy pickup. Chevy owners will remind you that Ford is an acronym for Found On (the) Road Dead. Ferrari versus Lamborghini. Toyota versus Honda. Tesla versus everyone else. Tell me that car people don’t root for their team.

That’s how it’s always been. However, when you buy a car you are locked in. You have to buy the parts for that car to fix it. Ford starters don’t work in Chevy vehicles. You can’t just pull a motor out of Corvette and drop it into a Mustang. Wanna try to put Lambo tires on your Testarossa? Good luck! You’re locked into a system that has parts for your car. There’s even a specific term for the parts division of Chrysler, which you use when you tell people you drive a MOPAR car.

Why is it that no one cares about lock in when they buy their car? How is it that when making choices between Cisco and Juniper or AWS and Azure that we rail against the need to pick a horse and run with it? How is it that people in IT will go to amazing lengths to over-engineer something to use the most obscure open source routing protocols invented for the sake of making their configs portable only to walk into the parking lot and crawl into a vehicle that has parts that can only be found at the dealer with a 1000% markup on price? How does that compute?

I Take It Back

IT pros see lock-in as a by-product of choices that were made without their input. No one complains about lock-in when they were the ones that got to make the call about which gear to install or which cloud to pick. Lock-in usually becomes a sticking point when the IT contributes were cut out of the decision loop or they didn’t get to voice their opinion for their favorite hobby project on GitHub. The disappointment festers into a feeling that the real problem here is that the evil vendor is just trying to keep us from moving to the solution path that I would have suggested if only they had asked me!

Why do we build networks using standard protocols? Is it so we can rip out huge sections of the network every three years when the incumbent vendor has pissed us off for the last time? Or is it because we want the opportunity to plug in a cheaper device when one fails? Why do we build multi-cloud capable networks? Is it because we hate Bezos or Nadella and we want to stick it to them by moving our workloads whenever we feel like they’ve made a poor strategic decision? Or is it really because some workloads work better in some places and we are trying to keep the rest mobile so we can move them to take advantage of cheaper spot prices like a game of instance whack-a-mole?

Lock-in isn’t a huge problem. It’s the boogeyman we use to cover our real problems: Not feeling heard and valued. We fight back against this by creating more work for ourselves. Instead of paying for the solution with money, we create a solution with an investment of complexity and time spent creating it. You wanna save $10,000 by switching out the gear I suggested for this other model? Fine, I’m going to make it completely open and hard for anyone other than me to use!

Ask yourself honestly: When was the last time you had to completely change your entire setup to a new system or new hardware in less than three months? Pandemic craziness aside, most IT departments can’t even figure out which printers to buy in three months, let alone scrap an entire network or cloud deployment for the competitor. And that’s the technical challenge. Let’s say you’ve used OSPF and open standards and avoided anything proprietary because you’re ready to pull the plug the next time that sales drone comes sniffing for a new motorcycle payment. How is your non-locked-in network going to compete with the power of spiffs? Sure, we could rip this whole $VendorA network out right now and replace it with $VendorB and there’s nothing you can do about it! Until Sales Drone mentions they’ll give you 20% off the next license renewal and throw in four new top-of-the-line switches to “test”. All you hard work sunk because Sales Drone and Executive Team speak the same language: money.

I know this sounds dark and ominous. I realize there are some very valid concerns about vendor lock in, like licensing features behind paywalls that are unreasonable or creating dependence on specific features that can be revoked at any time. But that’s not usually where the lock-in discussions go for IT pros. No, they usually go back to “$VendorA made me mad once and I will never use $ProtocolA again just to spite them!” Lock-in discussions are almost always really about the staff not getting exactly what they want and using their skillsets to create complexity as a panacea for what they perceive as the chance to move away when the executives want to listen to them again. What generally follows is a network that is difficult to maintain and doesn’t hit performance metrics. That means the executives’ decisions are punished. Not through sabotage. Not through malice. But through the decisions by their staff to try and create a system that make things portable when they don’t need to be just in case someone changes their mind sometime in the future.

Tom’s Take

I expect the comments section to light up on this one. Yes, lock-in is a thing. Yes, there are some very specific cases where it’s a Bad Thing (TM). I’m just pointing out that, like the car discussion above, most of the time the average person couldn’t care less about lock-in as long as it was their decision. The same people that will put a sticker of Calvin peeing on a Ford logo on their car chafe at the idea of having to use Cisco’s flavor of OSPF because one area they will never configure isn’t 100% standard. Lock-in is an issue. It’s not the world-ending problem we make it out to be. And it’s certainly not the boogeyman that scares us into making things needlessly complicated to the point of absurdity just to prove a point.

Penny Pinching With Open Source

Posted on by
1

You might have seen this Register article this week which summarized a Future:Net talk from Peyton Koran. In the article and the talk, Peyton talks about how the network vendor and reseller market has trapped organizations into a needless cycle of bad hardware and buggy software. He suggests that organizations should focus on their new “core competency” of software development and run whitebox or merchant hardware on top of open source networking stacks. He says that developers can use code that has a lot of community contributions and shares useful functionality. It’s a high and mighty goal. However, I think the open source part of the equation is going to cause some issues.

A Penny For Your Thoughts

The idea behind open source isn’t that hard to comprehend. Everything available to see and build. Anyone can contribute and give back to the project and make the world a better place. At least, that’s the theory. Reality is sometimes a bit different.

Many times, I’ve had off-the-record conversations with organizations that are consuming open source resources and projects as a starting point for building something that will end up containing many proprietary resources. When I ask them about contributing back to those projects or finding ways to advance things, the response are usually silence. Very rarely, I hear that the organization sees their proprietary developments as a “competitive advantage” that they are going to use to either beat a competitor or build a product that saves them a significant amount of money.

The analogy I like to use for open source is the “Take A Penny” dish that many businesses have next to their cash register. The idea is that people can contribute something small to help out others. If someone needs a penny or two to help make payment for a good or service, they can take one. If they have a few left over they can give back. It’s a way to give back a little now and then.

However, there are a couple of types of people that skew the trend for the penny dish. The first is the person that gives back much more than the norm. That person might put a quarter in the dish or put in four or five pennies at every dish they find. They contribute above the norm often and give a lot. The second type of person takes quite a few pennies from the dish and never gives back. They may see the dish as “free money” to be used to augment their own. They don’t care if all the pennies are gone when they finish just as long as they got what they needed out of it.

Extend this metaphor into the open source community. There are quite a few contributors that put in significant time and effort in their projects. They may have found a way to do it full time or may be paid by their company to participate in projects. These folks are dedicated to the cause.

On the other side of the metaphor are the people and organizations that take what they want from open source and never give back. They never contribute to the project, even if their enhancements are needed and welcome. They take a free or inexpensive starting point and use it to build a product that could be used internally to give the organization an advantage. The key here is that it’s something used internally. The GPL covers distribution of software that is based on GPL code, but it’s not really clear about what happens if that software is consumed internally. An enterprising developer may say to themselves, “As long as I don’t sell it, I don’t have to give my code back.”

Networking For Pocket Change

There are quite a few open source networking projects out there. Quagga, BiRD, and Open vSwitch are great examples of projects that have significant reach and are used by a lot of companies to build great products. However, imagine what would happen if no one gave back to these projects. Imagine what would happen if contributors decided to make their own BGP daemons or OVS-like program and use it without regard for helping others in the community.

Open source software needs developers willing to contribute back to the project. If networking is going to embrace open source projects as Peyton suggested in his talk, it’s going to take a lot more contribution than quiet consumption. Whether or not you agree with the premise that networking vendors are corrupt and evil you do have to concede that they’ve given us mostly stable protocols like BGP and OSPF. These same vendors have contributed ideas back to the standardization process to improve protocols like spanning tree and power over Ethernet. Their contributions helped shape what networking is today.

If the next generation of software based network developers wants to embrace and extend these contributions with open source, they’re going to need to be transparent and communicate with the project leads. They’re also going to need to push back when someone high up the food chain sees the development process as a way to gain an advantage and try and keep it all secretive. If developers aren’t going to give back to the community it negates the advantages of open source and instead takes us back to the days of networks being one-off creations that have no interoperability beyond a few protocols. Islands in a sea of home-grown lava.

Tom’s Take

As anyone that attended Future:Net within earshot of me can attest, I wasn’t overly thrilled with Peyton’s take on the future of networking. I have some deep seeded reservations about the “screw the vendors, build it all yourself” mentality that is pervading organizations today. Not everyone is a development shop. Law firms and schools don’t employ software engineers regularly. If you want to transform those types of users into open source adherents, you need to lead the pack by giving back and talking about what your doing with open source. If you’re not willing to lead the way, stop telling people to take the fork in the road.