PurePerformance - Open Source: Why its the Best Thing that happened to IT with Marcio Lena

Episode Date: October 28, 2024

Open Source is the Best Thing that happened to IT"! Powerful words from Marcio Lena who has been using and contributing back to open source for the past 20+ years. Besides being a vivid advocate for open source, Marcio also knows the concerns of large enterprises when picking open source projects.Tune in and follow our discussion about how to identify a healthy open-source project, how to balance between vendor and community lock-in, the power of open standards such as OpenTelemetry, open source business models as well as that contributing to open source is not limited to code but includes documentation, education and advocacy as well!Links we discussed:Marcio's LinkedIn Page: https://www.linkedin.com/in/marcio-lena/CNCF DevStats: https://devstats.cncf.io/Linux Foundation Events: https://events.linuxfoundation.org/CNCF Ambassadors: https://www.cncf.io/people/ambassadors/

It's time for Pure Performance! Get your stopwatches ready, it's time for Pure Performance with Andy Grabner and Brian Wilson. Hello everybody and welcome to another episode of Pure Performance. My name is Brian Wilson and as always I have with me my wonderful host Andy Grabner. Andy, how are you doing today? I'm pretty good and I just want to say something that I told you like 50 times earlier. Denver in November is I think the new magic word that the two of us will be using from now on. Yes, and if anybody listening is going to be in Denver in November,

Andy Grabner will be here. Exactly. And you can meet him in person and give him a hug. Or go dancing with him. That would be the better thing. There's a really good salsa scene in Denver. Been there before. So definitely want to check this out again. Are we doing an episode about salsa dancing in Denver today? I think that would be really interesting, but I think we have a better one lined up today. So maybe we'll put the salsa episode on the backlog and we can go into the episode that we're going to do today.

But I think maybe salsa and Latin rhythms is actually something for our guest today our guest today marcio lena is shaking his head but you know i a couple of things before i let him speak um i had the pleasure to meet marcio was last year uh at an event in sao paulo in brazil and a little while later a couple of months later, I think, one of my best moments ever on stage in Vegas with Marcio with Dynatrace Perform, where we talked about platform engineering. We talked about how we want to make the lives of developers easier. easier and reading from marcio's linkedin page now it says providing development teams with the tools to understand the products that they build really awesome tagline awesome guest today but now i would actually hand the word over to marcio marcio welcome to pure performance thank you so

much please you know let us know who Marcio is, where you come from, what people need to know about you, besides what they just read off the LinkedIn page. Thanks for having me, Andy and Brian. I think I loved not talking about salsa because although I'm from Brazil,

I have zero dancing skills. My wife rates it like minus one or it's like just horrible that it's not part of my firmament. So let me just introduce myself. I'm from Brazil. I have been working with IT for 25 to 80 years almost and pretty much 20 plus years all around observability monitoring, right? From the stone age, we'll call it this way, when we're doing these things with sticks and stones. And now I work for Dell. We're not going to talk about Dell here. We're going to talk about just an overall conversation about open source,

like we talked before, Andy. And before we do that, I'm guilty of charge. Everything in my place, it's fully open source. I do have a massive home lab. Let's say people build cars, people fix cars, people do a lot of different hobbies. My hobby is data centers and nerd stuff. So I'm a pretty big fan of having and like using or contributing to the open source for, I don't know,

since 96, 97, when I got my first set of Slacker floppy disks. So it's been a while. Were those the 5-inch or the 3? I don't remember. See, my memory is not that good. After two kids, I can barely remember what I did

last week. People are like, how you guys did it? was like manuals but when you didn't have the manual you had to get someone with a printer to print something that someone had internet so we could download it so we could do something and we got to use remember the the modem like tree comb i don't remember the really old ones which were serial you had to change the jumpers and had some really massive, pretty tall LEDs. So, yeah, it's been a while.

So you remember the sound of the modem when you dialed in? Can you repeat? I think those came later on. Okay, okay. Yeah, from the time that if you had a mouse, you could conflict with the serial port of how we configured the modem. So, yeah, it's a long time ago. So maybe... The mouse was something that a friend had.

I didn't have one. Yeah, maybe let me know, what was your first computer-ish, whatever thing it was called back then? What was your first computer that you ever had? Remember that? I didn't have a computer back then. Actually, my neighbor had one. I think it was a 386

or 286. This is where I started playing with it and it was like, sure, I remember playing... What was the name of the one that we used to use cassette tapes? That you need a recorder, so you kind of just play with it. With a little membrane keyboard? My first computer was a You need a recorder, so you kind of just play with it. Is it Sinclair? Yeah.

With a little membrane keyboard? My first computer was a 486, but I was playing since 286 because, I mean, we didn't have the money. It was super expensive. Yeah. It's been a while. It's been a while, yeah. And all these years in open source, and as you said, I remember back in the days, well, back in the days,

this sounds strange, back when we met each other last time, both in Sao Paulo and then also in Vegas, clearly your passion for open source was very obvious. And we talked about open source. We talked about the CNCF, the Cloud Native Computing Foundation. We talked about my role as a CNCF ambassador to really try to connect the global community around topics that the CNCF is obviously bringing to the community. CNCF, for those that don't know, is the Cloud Native Computing Foundation. It's basically when Google, now more than 10 years ago, donated Kubernetes to the Linux Foundation. The CNCF was founded. And now, 10 years later, we have huge events like KubeCon coming up in Salt Lake City. Like this year, also we had it earlier this year in Paris, and next year in London again,

where the global community meets around these topics. Also, we just had last week the Open Source Summit here in Austria, in Vienna. And open source has never been stronger, I guess, as we can say, as today. And so, Marcia, I know you said that open source is a big topic for you in your personal life. You know, you have been playing around for a lot of years. I want to understand also, though, a little bit,

because this was one of the conversations we had, the reasons why also especially enterprises are looking into open source i know one of the reasons that at least i hear is you know they want to avoid vendor lock-in so we're going to open source to open standards i want to later on touch base on some of the open standards like open telemetry which are very important in in the um in our observability space but can you tell me because you've been working for enterprises for many many years is vendor lock-in one of the reasons uh that people are looking into open source on the enterprise or what what have you seen over the last 20 plus years um and remember here my hand is i i this is a personal hat a professional i'm not talking'm not talking in any shape or form about any company here.

But before I jump into that, Andy, I think it's important for us to say one thing here. Open source is the best thing, in my opinion. This is Marshall. This is Marshall the person that ever happened to IT. There's not even a reason. It's pretty hard to convince me otherwise. People tried, I was like, no.

Because it kind of democratized access to things that you will always have to pay for. And if you're a home labor like me, I mean, I don't have millions of dollars to pay for a tool to run my home lab, which has hundreds of EMs. And also it gives people that sometimes use this as a hobby to make some money out of it. So open source is the best thing that have ever happened to us.

But at the same time, it brings its challenges. And since we're talking enterprise, my experience working with many companies like we're doing now and talking to peers in the industry and friends is that vendor lock is one of the reasons. Yes. But the other reason is, in my opinion, again, my personal opinion, is that cost is a factor. So it's reducing your lock to something like a vendor, which also reduces your lock to a fixed cost. Those are the two main things.

The other reason I see a lot in here, a lot from people, is that they are more prone to build instead of buying. This is how open source can help a lot because you can create a product that works for you the way your world works. Your universe is not the same as mine. In Brazil, for example, we have different problems that you guys have some other partners of the globe and different problems to solve. And not every product you just buy from the shelf can fix them or can help you to reduce or minimize the problem. So this is where I think open source plays a really important role on, first, reducing your lock to anyone.

Second, cost can be, open source is not free. Let's face it. You've got to have people doing it. Sometimes you need more people for open source than you would buy a product for someone. And third, if you're more prone to build instead of buying because you have a very specific use case. So those are the things I hear from other companies

on they are adopting or trying to use open source, a large scale. Yeah, I like that you bring this up. And I know that one of the things that, I think we're all in the same, obviously, community. We all like to think around the technology, right? And that's why the whole, that's why we like to to to take individual pieces that people have built and then as you said we know couple them together and try to solve problems that we have in our and you said

it in brazil you may have different problems than he we here in europe and so you try to use the tools that are out there and then to solve a problem that is very specific to you, whether it's a regional problem, an industry problem, a tech stack problem, and so on. The question for me now is, because you also brought this up in one of our conversations, and I really thought, wow, I need to also ask you and bring this up in the conversation.

Vendor lock-in is one thing, right? You can get rid of vendor lock-in. But then you said you need to be careful because in the end, you may end up in a community lock-in. And I wanted to understand this term, community lock-in, as you explained it to me because i think this is super important and also a a big um not challenge but task for organizations like the cncf or any other open source foundation to make sure that when you are deciding on an open source project that you're not kind of see negative impacts of lock negative impacts of locking into a specific community. But first of all, maybe community lock-in.

Can you explain a little bit what you mean with the community lock-in problem or potential problem? Sure. And it's important for us to understand what is a vendor lock. So vendor lock is when you buy something from someone and that solves your problem, or maybe not, depends on who you buy from. And then you're locked to that solution. It's hard to move away from. It is complex to move away from a technology standpoint. You might need to rebuild everything.

You might need to do all these things. Like, for example, when you pick your phone ecosystem. Let's say you're using Android, you're backing up in photo service ABC. Have you ever tried to take your pictures away from it and put in your, like, I am on off-cloud type of guy. My wife, my family, we are all on the Marsha's cloud, like I call it. It's all here with remote backups in my mom's place. So see, when we were all moving away from vendor products, it was an excruciating pain for me to just move away my pictures. That's the reason now I back them up at the same time in two places.

So I am not locked if I want to move. Sure, here's what I call decoupling. However, at the same time, the products I am using to organize my pictures, to make sure I have two AI servers now, like face detection, animal detection, I have dogs, anything like that, I'm actually jumping into a community lock. If they stop building that product or that project, or that project gets forked, and that's the whole reason of being all open, you can fork it, but let's say people drop it.

I am in the hands of the community for a new one because honestly, I don't have the time to build one myself. Back in the days, I used to have a lot of time. With two kids, work, family, and everything, I just don't. And a lot of people that use today are building home labs, they will not build the product. And that's the beauty of open source. You can build something that works for you. But if that piece of that you're using and I always recommend buy coffee for people that build things you're using, donate, be a patron, do that because they need money to pay for their bills. Right. So we've got to help them because they're helping us. But if someone drops that for whatever reason, they quit, they became

millionaires and there's no one supporting that product. Depending on how you build your backhand, you are stuck to it. Then it's not that different of having a vendor behind it. The difference is with a vendor, you have someone who call and say, I want the solution because I'm paying you. If it's fully open source, you might be on your own or you need to be begging help from people all over the place. And then you have a community to look because you're locked to the community. Perfect example, what I have seen in another company is they were using a type of database, which is pretty, I will tell this, it's pretty good. It works really well. But it had a pretty massive vulnerability.

They didn't know how to fix it. And the community didn't have a fix. But that company had a rule that they must, in some regulations, every country has their different ones. They had to be patched in 30 days, mandatory, or they're going to pay a fee for the government. No one was fixing it. They didn't know how to fix it. They had no one to call. So in a way, they were begging for help in the community. So in a way, you're always going to have, again, my experience is that you're always going to have a lock. It's either in the community or in the provider.

You're not going to call vendors as a provider or both at the same time. So that is what I mean by community lock. Unless you code it top to bottom, you're going to have locking on someone. So being lock-free, I don't think we all want to be there, but I don't think that is a reality. There's always a human back there that we rely on or a company. So it's shifting the lock from one location to another, from vendor to community. And then it comes into the idea of weighing what are the risks of each, or the benefits of each. Obviously, there's a lot of benefit to the open community because you can buy

the Lego sets that you want to build your, your dream land, as opposed to here's the full set and you can't swap out, you know? Interesting. Maybe, maybe, I'm sorry. It's okay.

But Brian said something really important is you got to think about the risks. So see my personal life, all my pictures are backed up in folder structures as well. So, I always have a plan. See, if everyone stops doing that, I can go back to folders. Not a big deal. However, when you look at a massive implementation

of in-my-space observability, you've got to weigh in the risks of picking one or another, especially when they are too new and they keep changing. Sure, here's where scale just messes up everything. Because if you look, let's say observability implementation of, I don't know, a thousand servers. They're all brand new. All like, it was answerable for everything, whatever you use. It's like working like a charm. It's different than you have in like 200,000 servers,

which were provisioned all over the place across many different vendors. Some are legacy, some are highly customized, some might be appliances for someone else, like a virtual machine appliance or something like that. How do you actually protect yourself and your company and vulnerabilities, for example, or for whatever other reason, right? So I always weighed in.

This is really critical to me, Brian. I always, every piece I pick, I always look, how many contributors do we have? How many like code check-ins people are having? How is the community? How is the GitHub repo going? It's like, do you have really people asking questions, people collaborating? Is it centralized on someone so I can make decisions on, is

this a good piece for me to build my Lego set or not? So I don't know what to say. But this is the comment I want to make on what you said is perfectly right. You do that with vendors. We all do this with vendors. Which vendors comment I want to make on what you said is perfect. We're right. Yeah. Like you do that with vendors. We all do this with vendors, which vendors we're going to buy stuff from.

We all do that. Open source. I do the same. Sure. Not the same analysis, not the same criteria, but we, when we're going to pick something that is open source, like we really do a study on, okay, this is great as a strength C is aligned to the future, but how reliable it is and how reliable can I make it? As a buffer to not being in 100% community lock in case something bad happens.

I think this is one of the most important messages that has to get out there to do the research. We've talked, Andy and I, with other guests, about just even picking what platform you're going to deploy to. I think it was a recent episode we were joking about the we're going to be a fully serverless shop because we want to be. Not because there's a reason to be, but because we want to be. And people make these decisions, and then down the road they realize, oh, we didn't plan this out right.

We didn't think about it all. We didn't think about how we can observe it. We didn't think about it all we didn't think about how we can observe it we didn't think about security we didn't think about all the other aspects to it and unfortunately I think there are a lot less people like you who are going to do that research who are going to weigh the pros and cons and a lot of people who because of that curiosity because of that passion to explore are just going to jump in and say, I'm going to create this. Again, I'll use the full server list. I'm going to do a full server list to show that I can.

But there was no pros and cons. There was no evaluation behind that. And same thing with open source or vendor, whatever it might be. I think what people are really, really missing is that, excuse me, I think what people are really, really missing is that, excuse me. I think what people are really missing is that diligence to look into what they're, they want to do. Right. I mean, even if I want to buy a new keyboard or something, right.

I spend time looking into it. Is it doing something that I can't already do with what I have? I mean, yeah, there's this stupid freaking, sorry, now my camera's dead again. I got to figure out how to turn that off. You know, if I'm looking to buy a new keyboard, I got to see if it has features or if it could do anything different that I can't already do. And it's not I want to buy because it's shiny and cool. It's because it's really going to serve a purpose for me. And I think, and I know I'm belaboring the point, but I really wish there were more people getting at the conferences,

getting at the call, you know, the DocCon or whatever things people go to, and talk about the decision process. Because I think that's what's really, really missing from all this. Anyway, I'll get off my soapbox now and continue with... I agree with you. Yeah. Hey, one thing, Marcia, too, because you said you're looking, and I think this is great advice for all the listeners,

you're looking into how healthy is the community, how many people have started the Git repository, how many have forked, how many are contributing. For those of you that don't know, there is DevStats. So for instance, for the CNCF, you can go to devstats.cncf.io, where you get an overview of all of the different projects, and you can see who is contributing, how often are people contributing, how active is the community, and also I think how diverse is the community. Because to your point earlier, even if we have a big community, but let's say

one vendor is behind all of the people, and maybe that vendor is then even snitching engineers from that open source project, then the question still is, who is really driving this project? Is it really a community, an open source community, or is it still just one organization? So devstats.cncf.io is one resource at least for the CNCF, and I'm pretty sure for other open source organizations, that's the same thing. And the CNCF itself also has very strict criteria. If you look into the different kind of maturity models where there's like a sandbox incubating and graduated projects.

And in order to become incubating and in order to become a graduated project within the CNCF at least, you have to show not only adoption, but also a good breadth and a good spread of community members and contributors. I think that's also very important. But thanks, Marcio, for bringing that up. There's something you said which is important, right? Like I said, in my opinion, open source is the best thing to ever happen to the IT industry. I'm a big, big, big fan.

And like I said, I don't have the time I used to have. So if I'm using someone else's Lego bricks, I usually go to the repository and I donate. I actually donate money into many different projects because I'm getting the benefit. There's one thing that also people tend to, again, this is more the time I usually get in trouble when I talk about this, but it's everyone needs to eat, sleep, Peterbilt. So there's another misconception where I see a lot of people in the forums just bashing on open source developers and open source projects saying, hey, why this is not fixed? See, sometimes for the people that are in the project, that is a side gig.

Something that they do because they're really passionate about. They don't make any money out of it. So being hired, and see, this is what I call being called to the mothership. Let's say project A, they're really passionate. You have been working on that for two years. If the company behind project A wants to hire you and make you a contributor, that is a career path. There's nothing wrong with that. I guess

we're in this where I think CloudNative Foundation is critical in this ecosystem is that we need to find, in my opinion, we need to find a way on having someone that regulates it. For example, if I am company XYZ and I have my product and I am making that product open source for everyone to use is one thing. It's my product as a company.

I created it. I am sharing with the community. In a way, it's from me there. It's from closed source to open source. Usually that's how it works. So, yes, you're going to have contributors. They're going to be working with the company, merging code. But still, it started with the company, not at the community that built the whole thing.

So in a way, I think they can't control contributors. They can't control how the product is going to be shaped. But there are situations where you have company ABC that was born on top of open source and they hire all the contributors. That's amazing. That's an amazing recognition of the community. But where is the line where the community wants to take the product in a direction that will impact a revenue stream from the company that is making money and supporting

the community. See, the company needs to make money. People need to make money. So what is the balance between the two? Is it the way to just fork it and create a new thing and people go? But aren't we just increasing fragmentation? Hundreds of things that will build on top of the same thing that now are all different and they're trying to solve the same problem. But I think this is where it goes to the research on understanding how that project is being driven. Because the community driven means the community makes decision, not someone behind it. And if someone is making decisions for the community, prioritizing a revenue stream, that is not a community-driven open source. That is a company-driven open source,

which then is a different approach. And I see people bashing companies. I get like, guys, they're giving us this for free. We can help, but these people need to make a living. Otherwise they don't make the product we use for free. And this is where I think sometimes we got into these really heated conversations, like back in the days where the conversations about Linux and Windows, oh my God, you use Windows, you're a bad person. You should be using Linux for everything. I remember being in endless conversations about this in the past. Thanks God that's gone.

But we still have people bashing developers. I see people bashing companies. But again, I think it's where, where's the line? Should we have a regulating party? That if this is a community-driven software that someone built a product on top, the contributors should be from the community, not from the vendor.

But what happens if the vendor hires them? That's a great thing for the contributors or for the guys that actually manage the code. But do we need a regulated party? Do we need rules? I don't know. I think this brings, I mean, I don't want to get into the whole thing about being people just trying to make money out of other people.

I think this is fair. People need to pay their bills. There's nothing wrong with that. What will make a community-driven open source versus a vendor-driven open source? And then it goes back to the lock. If the vendor is the one driving the open source

product and I'm using that open source product, I still have a vendor lock. In a way. And in some cases, both. But that is the point where people get really angry at me. So stop talking. No, no, that's very good. I think, I mean, Marcio,

I think what's eye-opening is that these are all things and thoughts that people need to have when they are looking into the vast range of open source projects out there. I think some people may have never thought about that the selection process of open source needs to include all of these quality criteria of a project. So how diverse it is, who is behind it, who really makes the decisions. As I said, I think the CNCF is trying to do a good job in putting not regulations in place but basically guidelines in place that then allow a project to

become or get into the next level. So a graduated project means you have a lot of adoption, a diverse community, and therefore that's a good quality criteria for choosing this product and reduces the risk. On the other side, I think what you were also strongly advocating for, if I hear this correctly, instead of just picking from the candy store and then complaining that the candy may not taste to your liking,

maybe from time to time also contribute back. I think just consuming and then complaining if something doesn't work but never contributing is just not the right attitude towards open software towards an inclusive community in a community and i think in an exclusive inclusive and appreciative world we live in right i think as you said you've contributed over many years to many different projects and i think that's just also understanding what it actually means to dedicate free time to something you're passionate about. And then you can also appreciate a little bit more what other people are putting in into those projects that you're using on a day-to-day basis. And therefore, maybe not bash them on the different social media channels

if something doesn't work or doesn't get fixed right away. Instead of waiting for them to fix it, maybe try it yourself. Contribute. And sometimes I understand there's not a lot of people that are coders out there. I still code, but see, that's me. I don't deal with cars.

I don't deal with instruments like Brian because he has a lot of fancy gear for instruments. I don't. I don't have that skill. I don't even dance for Christ's sake. But I mean, I just don't have the time anymore. So contributing, I understand we always talk about code is important, helping to build it.

But see, if these people are working for free, pay them a coffee. I think that is, I mean, this is what I usually do. I don't have enough time as I used to. But if you don't know how to do it, just ask them how can I help? Can you help to build better documentation? Can you just describe the way you implement it and make a better MD file? So someone else that doesn't have like super advanced skills on it can actually take it forward. Actually, I do that all the time.

That's a great point. If I look at some of the open source projects that I'm involved in, bringing up Captain, for instance, we have a lot of contributions on the documentation side. Because engineers, we all know documentation is probably the least favorite we like to write if you try to code. And if you have somebody that likes to use what you built and then write good documentation about it, then that's a great thing. So open source contribution is not limited to writing code.

It's about supporting everything that a good software tool or framework needs. That is good community work, education, documentation, testing. I mean, there's so many things where people can contribute. And here's where it comes to what I said. It's democratizing access to something you would never be able to do before. And see, I was good building my first AI servers. I was scratching my head, how do I even get started? And then I found an open source project that I love now.

This is amazing. Their documentation for a noob like me that was just getting started in that space was pretty awesome. And I was like, oh my God, this is easy for me to use and show to other people how to use it. So building documentation that helps to democratize the usage of that also helps with adoption for new open source standards, for whatever, I mean, whatever product, whatever Lego bricks,

like I really like what Brian said, it's like your dream lane of Lego bricks, democratize the usage of that very specific Lego brick. Because you don't need to know everything, and you just can't. It's impossible nowadays. Have you seen, coming back to, because both Brian, I, and you, we obviously work with a lot of organizations

and talk with many people in the industry. Have you seen organizations being more successful where they also contribute a certain amount of engineering time of their engineers to open source. So to give an example, we are using internally Dynatrace, a lot of different open source projects and frameworks. Sometimes we make modifications because we need it to adapt to our use case. But then we also contribute back and i actually think it would be just fair to say from an organization hey you know a certain percentage of our software stack is made out of open source projects so why not then also dedicate a certain amount of time of our engineering force to

actively contributing to those open source projects because it has multiple, I think, benefits. A, you're learning that community better. You understand better who is involved and how the whole thing works. But you're also, in the end, kind of reduce the risk, right? Because if you're actively contributing to a project like what you mentioned earlier,

if the key maintainer, all of a sudden, I don't know, something happens with them, but you have actively involved yourself, then then hey, you might be the one now that can fix that security vulnerability and you don't have to pay that fine to your government because nobody can fix it within 30 days. Yeah, I think this changes from, based on my conversations out there, right, it's like it changes from company to company. So if you have, again, there's no right or wrong here. I think it's different companies operating different ways, in different groups.

Let's take companies away from this. We're talking non-profitable organizations as well. There's a lot of open source. A lot of governments, they're pretty much like heavy on open source. I think this is where it's also a funding conversation. Like for example, you have one engineer that let's say real simple. You have one engineer that his job is A.

If he's doing A plus A and a half to maintain another project, I mean, and then you ask that person, like you need to move really fast. How can you do both? But again, I don't have an example where, hey, a company that is contributing is doing better financially or is more stable or offers a better product because they're contributing. I never seen that as being a thing for me. I think each company and each organization has their own challenges and the things they're trying to solve.

And sometimes they just don't have the manpower or even the right person to do that. But I do think it's a good approach. I mean, it is the right thing to do, in my opinion. But again, I can't judge because who am I to judge? I'm not in their shoes. Yeah, I mean, I think it's a really good idea, too, if you have the bandwidth to do that, right? Because everything we have in IT comes from that community feedback.

Even if you go back to your early modem days when it was people sharing ideas on BBS is sharing bits of code other people working on them it wasn't obviously in some cases there were some just like big company top-secret stuff but so much has come out of that community effort I mean look at where kubernetes now. It's ridiculous and that was people tinkering around saying I don't like what we have here we're gonna try it differently and now everyone's using it. Even the idea that everybody goes to these conferences and shares their wins and losses and

problems they've run into and successes they've had for others to learn that is such a important part of the it community that it couldn't survive without that um but i agree you you might if you're one person working at a company or small group you're not going to have that time but you know it comes back to do what you can when you can right and i think it was eye-opening when you you mentioned the idea of working with docs because um yeah i wouldn't i wouldn't say it's quite open source but i use some software for some music stuff and all that that's just like somebody makes right and they say you know they give it away for free and there's the buy a cup of coffee thing um and then it's also hey if you want to contribute and i'm like yeah I'm not a developer though right but now I got to think well let me reach out and say hey I'm not a developer is there anything I can do and that's I think key to keeping this going on because if we lose this

momentum we're going to lose everything oh wow every oh you just did the hand raise too I just figured I am 100% with you there, Brian. This is a pretty big time. You don't do the thumbs up because your camera is going to crash. I figured out how to turn it off. Oh, awesome. Um, and I think, see, this is where it is, where if we work together, we can increase adoption of the products.

We believe it. Like for example, the one you just described, how can you help other people that have the same problem as yours that this open source project can help to solve? If you have an easier to follow documentation or scripts, for example, whatever, you name it, it's like you bring that to more people that wouldn't be able to do before, like packaging them in a Docker image, for example, with like, just run this and you get it. And here's where I, again, right. We also need to understand, we also, again, this is how I see the world is our industry

came out of being people with computer science degree, people with engineering degrees into everyone can do it. So it's expected for people to have different knowledge gaps. What I see a lot, and this goes back indeed to the coffee thing, is when profit gets into the conversation of a community-driven company, community-driven software, is where things start to get hairy because we all need to make money. That is nothing is free. But again, I'll go back to where's the line on this is fully open source community driven. But it's not someone is like ingest and then you get this really cool thing.

You fix a pretty big problem, the open source project. And then you figure out like, wait a second, I can make a company out of this. And bingo, you get a fork and then there's the code, the code is gone and it is no longer community driven, which is, I mean, I'm not going to be naive or a hypocrite here saying people don't need money. Let's do it for the law of the dividend. Like we don't need money,'s do it for the law of the dividend like we don't need money but see where's the line and then to brian's point what are the criterias to pick these softwares so we can build our lego bricks with them and deliver a solution either for for any

type of organization even at home yeah i wanted to add one more thought on this what i mentioned earlier like how much would a company contribute back? If you think about observability, the topic that we've all lived in for so many years now, and I think we had Hans Christian on the recent episode. He's from a Norwegian government agency in platform engineering, all in on open telemetry for very good reasons. But in the end, I think there's still a total cost of ownership. And total cost of ownership, you could do one thing. You could go all in with the vendor and basically, as you said earlier, you can call the vendor, ask for features, and basically you pay them money. Or you could say, you know what, the total cost of ownership for my decision

to go all in open source means, as you said, open source is not for free. You need people to run it, to operate it. And then you may figure out, hey, OpenTelemetry is great, but maybe for my specific runtime, for my specific programming language, currently there's not a good SDK. So who is going to build it for me? Well, then maybe the total cost of ownership will include engineering time that you need to contribute to build that support for open telemetry for this particular technology and then also to maintain it. Ideally, you're contributing this back to the community so that others that have the same requirement for that stack see the benefit, use it, and then hopefully also contribute so that your total cost of ownership actually goes down because you're sharing it with a bigger community. But my point is, I think that's what you said in the beginning, open source is the best thing that happened to IT,

but it also doesn't mean that it is for free. There's different costs, and in the end, the total cost of ownership to solve a particular problem is the big question. And in this example just the total cost of ownership to solve a particular problem is the big question. And in this example just given, it's interesting because, see, this is where the business gets in between the open source. Again, like I said, I'm not bashing anyone.

I'm not going to be a hypocrite. We all need money. Let's face it. I want to say this over and over again because people say, Marcio, you sound like you're against open source. I'm actually the other way around. I just think that people need to make money out of the things they build.

But in this example, let's say language ABC, we build our own thing. What if that is the thing that sets you apart from your entire competition? That's an IP. Would you share that? So this is where it goes into, there's no right or wrong. It's a decision that the company needs to make. Do I want to contribute back to everyone so we grow as a community? Or do I want to grow as an organization, whatever that is?

But then again, there's no right or wrong. Each company organization would do it in a different way. Maybe it's an IP. Maybe like from a governance standpoint, that is what keeps your country safer. I don't know. I can't judge. It's different. But you're right.

And here's where we're talking about observability is the total cost of ownership. I'm a big fan of open telemetry. This is the first time ever I see people agreeing to do something that works kind of across. And I get it. Everybody will have its own agent because that's what they support. So if I bought that product, I'm going to call them saying, hey, I'm using this thing. It's not working with your product. They're going to say, are you using my agent, collector, whatever is the fancy name.

People are going to come with the same thing. Again, I would say no. Like, oh, well, I can't support you. And in a lot of cases, it's for good reason, because they will ensure that every vulnerability will think that piece is solved before they give it to me. Because they have an agreement with me that they need to patch it or make it secure, because if there is a problem with their product, my image is impacted and their image is also pretty impacted. And also we need to look from, again, bringing back to observability, you and I had this conversation in Vegas,

is open telemetry is the foundation of a big change, but it's not the only one that is needed. One of the biggest costs, and then again, it depends on scale. When you look of implementations of observability, or SREs, all things go together, and you have 100 users, and you need to migrate from one place to another, you can help, like OpenOwl can help you with that transition, you can keep your data, yada, yada, yada, but at the same time, it depends on what you have built on top of that. Because now it's a different search language.

You cannot just translate one to another. And then when you have like an implementation with 5,000 unique users, then your cost to change a tool is not the largest cost. So OpenTelemetry, in the cases I have seen, and I talk to people, each company is a bit different, right? So don't take what I'm saying with a bit grain of salt here. There's cost everywhere in the stack. Moving from a product to another

that has a different search language, a completely different search language, that you cannot even move copy and paste, it's completely different. If you have a very large user base, there are heavy users distributed in 30 different countries, 5,000 users that have built like thousands of dashboards, thousands of alertings,

like everything is in thousands. To move away from that product, that is the biggest cost, to move away from another product, from one to another. So in our industry, I think there is oh my god, it's the best thing that ever happened to us in a long time. But there are other things that we should be discussing as a community on can we have a standard search language? Or similar, like SQL.

SQL, SQL, everywhere you look. Sure, Oracle, Microsoft, or whatever. They all have different flavors, but it's not the same, but it's very similar. Searching for observability data? Oh, boy, no. They're completely different. I mean, you've got to relearn, in some cases,

just how different they are. That is where I think I would like to see our community driving that conversation. Because I know I'm driving that in a lot of forums. Can we have something that is at least similar? So we reduce the cost of ownership on the top layer, which we've got to retrain everyone. And didn't you mention something once about OpenQuery

as some project somewhere? It sounded like some sort of... and didn't you mention something once about open query as like some project somewhere there's different working groups and I was just trying to find the name also for yet another one that just recently was proposed on because you mentioned dashboards like an open standard to define or declaratively define what you want to see on a dashboard, right?

So there's different working groups within the CNCF ongoing to define standards. I think it's just, I'm pretty sure as with SQL, I mean, I was around at that time, but I guess I wasn't around when that standard was specified. I guess it took a while to come to an agreement on what is the superset or the subset of a language that you need

so that it works for the available databases. But yeah, I think that's exactly, again, coming to the total cost of ownership. It is a big thing to, also the login, whether it's a vendor login or whether it's an open source lock-in. You're locked in. If you're building things on top and you integrate this into the rest of your ecosystem,

it's not easy to just rip it out if you're ripping out a long, non-standard interface lines. It's basically what it is. It's almost like ROI of replacing a product. That goes back to the vendor lock. The community lock is the same. The lock conversation is the amount of work that it's going to take you

and we've got to remember, there are companies with five developers, there are companies with 12,000 developers, like hundreds of thousands of developers. Replacing small scale is a much different problem than large scale. And here comes the total cost of ownership because recreating everything. And remember, if we're doing this for a very long time,

sometimes we don't remember what we have built because it's like documentation, right? Then there's thousands of dashboards, but Oh, wow. There's this dashboard that there's just one person using that person is the key decision maker. If he or she, he does, they, wow, there's this dashboard that there's just one person using. That person is the key decision maker. If he or she, if that person doesn't have the dashboard, we might lose millions of dollars. I'm just making a crazy example, but that happens in every company, right? But the work to replace all of that without dropping the ball might take you two years to three years to replace.

Although we're using open telemetry in the back end, you still need to three years to replace although using open telemetry in the back end you still need to send the data somewhere for someone to build something on top that makes sense or to alert or whatever but um but again this is this is to me a very important topic as we talk about open source and standards for observability this is to me is when we as a community marcio's hat on on, remember, this is not Marcio that works for a company. This is when we as a community, observability community, will be able to say, yeah, now we own our data and we own our future and we can pick the locks we want.

Because until we got to the top section, like I said, something really important that I was talking to my team yesterday. It's like dashboards. Can we port them? No, we can't. Anyhow, because if you have a standard language, how do you port it? Marci, I would like to ask you one more question

on OpenTelemetry because this is fresh on my mind. I came out of a meeting with an organization and they basically said, yeah, OpenTelemetry obviously great as a standard to collect the data. So first of all, that's something we need to clarify. It's how we collect the data, but not how we process it, where we store it. But then the question came, and I think you also mentioned it earlier if you build something new then it's easier to start opsability new but what about all these existing legacy systems that have been built and might be hard to modify where open telemetry

is not yet kind of baked in based on what you see out in the community do you think there are still areas where it will take, where it needs more effort to get open telemetry and where we still have kind of like a black box

when it comes to open telemetry in terms of observability? And if there are some, how can we encourage maybe the community to put more focus on that? This is also where people like get really mad at me, but

let's talk about it. I think when you look at, I call them basic telemetry when we talk metrics from servers, from Kubernetes clusters, from holes, from whatever. But if we just talk metrics, it's kind of easier and we made a lot of progress on it.

Sure, there are things like, for example, load balancers. They do not have an open telemetry collector. Defenders didn't do it. Some are doing it, which is great, so we can integrate. So that piece I don't think is the biggest problem. I think when we look at application tracing, is where things get a bit hairy

because although SDKs work really well, depending on the language, sometimes they don't. And as you start to get... So see, here's the scale problem. If you were born cloud native, like standardized on languages, this is what we're going to use, blah, blah, blah. Libraries are going to use blah, blah, blah, blah, blah. It's a lot easier.

I'm air quoting here. Folks are not seeing, but you guys are seeing that I am quoting. It's a lot easier. But when you start to deal with legacy systems with, for example, packaged applications that every major company have, that is where it gets hairy because you just can't do it. And it's not that you just can't. It's about the cost again.

See, I don't want to talk vendors here. So let's say I have open telemetry. I collect my data. I need to send the data somewhere. Depending on the scale, you need a vendor that can support the scale you have. Let's say gazillions of traces a day. So you're going to buy that product. That product comes with an agent or an operator that does bytecode instrumentation.

That does all the heavy lifting for you. So why would you do OpenTelemetry? Isn't that an added cost to the development lifecycle to refactor a lot of that and make sure it works? See, just putting out there is a piece of the problem. It's a piece of the puzzle. You've got to make sure it works. It has the same performance. Then you have a piece of the problem. It's a piece of the puzzle. You've got to make sure it works. It has the same performance.

Then you have a dependency of something else that is community-driven. Someone changes, makes a change and you break like 500 apps. Then testing becomes a lot more complex. Not just application testing, like framework testing, SDK

testing becomes a thing. Vulnerability for these things become a thing. But you'd still need to send it somewhere that can deal with your scale and they have something that it kind of is a plug and play. You don't need to do it. This is where the answer is it will change from company to company.

Some companies will have a more like, hey, let's go do it. We're going to pay the cost to do it. But again, it depends. Organizations see this in a different way. The way you see it is the future is a hybrid. It's a hybrid future. We're going to have open telemetry application instrumentation

alongside bytecode instrumentation. This is how I see it because if it's way too big, you can't run away from it without honestly just recoding and sending them out of your code base. But when you get to scale,

that is probably more expensive than just buying a tool that does it for you. Yeah. And Marcio, thank you so much for kind of confirming

also what I would have answered. And I think if... No, because that's why I wanted to hear from him. And don't take it the wrong way, but I think this was really important that he said this. And I fear that if people just go out, right, and then, let's say, within an organization, they start with new

projects, all cloud-native, and they do everything OpenTelemetry great, but I think one thing that people should not do is then building their own silo. Because in the end, this new stuff that they built should not be seen in a silo to everything else they have that also connects. And if you're building, I see a lot of organizations building new applications, front ends, cloud native,

but eventually they still need to talk to some legacy system. And you need to make sure that you don't end up with completely siloed observability approaches. And I think that's why what you also said earlier, you need to pick a back-end. And there's many open-source solutions out there as well that can consume open telemetry and that can consume things from the legacy system, don't just don't make the mistake to end up with a complete silo. Because then it's going to be hard to troubleshoot to, as you said earlier, provide this dashboard for the business person to make a decision that needs data from both sides. And here's where it then, again, being radical, like we were before between Windows and Linux back in the days, I think that is the thing that slows us down a lot in the open source, especially in Linux adoption. I think that actually hurt us being like really radical, left and right, no, bad person, good person. I think that's something we need to avoid as much as possible.

And we need to, I tend to deescalate conversations like that. Because when we get to this extreme, we start hoarding the image of what we're trying to do as a community. For example, when people say observability is a cost. Remember what I always say, like, would you fly an airplane without instruments? Would you run your company without knowing what's going on? That in a way is observability. But when we become into this fight

between open source, not open source, bytecode instrumentation, this is the right, this is the wrong thing. When you look at the leadership and you talk to people that don't do this every day

like we do, it's hard for them to understand. And when you get into these fights, people will say, hey, this is too complicated.

Why do we do this other way? Why do you actually need this? Because this is just causing more charm, more noise, and more cost. So why we even do it? So that is where I went. Again, my personal belief is sometimes it backfires on us. Because we're not looking at the bigger picture that this is a bright future for us. It's just like it's not one way, my way or the highway.

We got to understand, like I said, we have people with different backgrounds now working in IT for a long time. But even with computer science, when I started, like, if you didn't have a computer science degree, they would not even give you a job because you didn't even have a mouse.

Like, it was a different time. No mouse, no job. Exactly. We don't have that anymore, so we need to make it accessible for people to use. It needs to be simple to adopt, especially at a large scale, but we should not be picking the fight of being this us versus them, open source versus vendor, vendor versus... Like, we need to stop that. Things need to make sense together.

Otherwise, you don't get an ecosystem. You got just pieces just stitched together with high cost. And then when you go into budgeting discussions and just not like everywhere I talk about this with other people, like, Hey man, how do you justify observability? Because they don't give us money to do it. Then the question is, how are you guys doing? Like, yeah, we don't talk about it. Why you don't talk about it? Oh, people say it's too complicated. Sometimes we are creating that problem as folks in the industry.

There's this war between things. It's not a war, it's a hybrid, it's a combo. These pieces need to coexist for a long time so yeah this is where i think you need somebody with vision on on a lot of the stuff right you you said ecosystem right and i think that's the important things i was going to talk about when you said windows and linux picking the right tool for the right job but you have to pick the right tool for the right job that you're working on, but also that fits into the bigger picture. Right? And Andy, it reminds me of a conversation, I forget the topic, but it was a year or two ago when there was the idea of you're going to pick some things as SaaS, you're going to build some things, and other things you're going to do like maybe out-of-the-box

vendor solutions, right? And I think the same thing comes into play here. Some things are going to make, you know, what makes sense to do open source? What makes sense to say, well, just take and throw a vendor agent or something like that on that one. Maybe it's less, you need less flexibility. It's a low cost or, you know, but there has to be those decisions that go into, it doesn't have to be all or nothing is what I'm getting at, right? Look at what's going to be best in those places, but not from the Catholic versus Protestant,

this is best, more from the what are our needs and which does this fit? And that's where, again, if you don't have somebody who's been in it who's seen the outcomes of those fights or at least not even heard the antidotes of all that infighting

you're going to very often fall back onto that so that's another hard thing to to overcome but yeah this has been great

by the way this conversation I see why he talks so much in Vegas with Marcio and not only in Vegas with Marcio. And not only in Vegas, I keep talking about... Let's put it this way.

No, but opinionated, but also in, you know, I think igniting thoughts. I think, you know, it's... We are nearing the end of the podcast now. It's amazing how fast an hour flies.

But I believe when we go back to the very beginning, you opened up the podcast with a statement saying, open source is the best thing that ever happened to IT. You've lived through this for many, many years. And I think this is just a great statement and a reminder that open source has always been here, will always be here. We should not take it for granted, meaning just take it and never contribute back. So I think one of the takeaways that I want to highlight here is contribute back, whether it is through code or documentation. There's other ways to contribute other than code.

Not everybody is a coder contribute back with feedback i've seen people in our communities you know just create a short video and say hey this is why what i like like brian you said you're using this music tool maybe just create a short video and say this is what i what i love about this and you help the community by extending the reach um and yeah i believe this was an awesome conversation, Marcio, and I hope you inspire more people to think about open source. Also, the way to select open source projects is similar, maybe some different dimensions and metrics to look at when you are picking commercial tools.

But in the end, you want to look into the health the diversity who is behind it because in the end you want to reduce risk and also costs and that's yeah yeah thanks for having me and and indeed brian this is a very good conversation that my opinion again this is just marcel just a person right we need to have more often so we remove the, in my opinion, there's still this fogginess around what open source really is. And Brian, to your point,

people just say, I'm not saying people are not well informed. What I'm saying is, if you haven't lived this long enough, you usually get something like, oh, this is magical. We're going to use it. It's going to work. But there's a person on the other side using their weekends, with their kids,

building that for you. So at least we buy them that. If we're using a package, just buy them a coffee at like $2, $5, whatever. Just do that because otherwise this is how this community is maintained. If we don't do that, sure, not everyone is a coder,

but man, we can spare a cup of coffee or $5, $10 or whatever it is to save you maybe 25, 30, 60 hours to build something. That is worth at least a cup of coffee. Just think about that. Or whatever people like to drink. Some people ask for beer. Yeah. And thanks to Starbucks for making a cup of coffee. Just think about that. Or whatever people like to drink. Some people ask for beer. And thanks to Starbucks for making a cup of coffee five bucks.

Yep. You know, really quickly, I have a business idea based on open source business idea for you now. And anyone, feel free to take it and then I'll be like, I'm such an idiot that I didn't do it. Hire yourself a bunch of people who are experts

in these different open source projects, and then you offer them as services to help people implement open source. But since they're so tapped in, they can also very easily submit changes or bugs or all that, so they're contributing back to the community all the time. But for all the people who are like, I want to use open source, but we don't quite know if we have the time to do it, or we don't have the bandwidth to wrap our heads around it deeply. We have all the experts, you can hire them out. Now you're not being evil, you're not privatizing open source,

but you're helping other people use it. So there you go, somebody consulting open source consultancy firm. Cool. I like the idea. And one additional, because I see these organizations too, sponsor your local open source community. There's typically always some local, like the open source summit just happened in Vienna this last week. The local meetup scenes that are centered around certain open source projects.

The KCDs of the world, the Kubernetes community days, the DevOps days of the world, right? These are all community driven events. So, you know, if you look into those, sponsor them, and you're supporting a great community. Yep. Awesome. Awesome.

Good. Well, Marcio, thank you very, very much. You have something else there, Andy? No, I just wanted to close it up, but I think it's time for you to close it up because I already did my, my summary. Yeah. Well, yeah, the summary is back. Thank you so much, Marcio. We really appreciate it. This was a great conversation. There's so much more to open source than I knew before we did the show. So I hope a lot of our listeners did as well.

Really appreciate you sharing your own opinions, not based on anyone else. I know you're stressing that very hard, so I want to respect that. And I hope our listeners really enjoyed this one. So thanks everyone for tuning in today. Ciao, ciao. Thanks for having me.

Thank you. Ciao me have a good one