Today’s guest on Cloud Gossip is Tom Kerkhove! Tom works as an Azure Architect at Codit, he’s a Github Star, CNCF Ambassador, Azure MVP and he’s active as maintainer of Promitor and Keda. Tom is going to talk to us about how the world of Open-Source projects works, the importance of supporting them, and his personal experience as a maintainer.
We’re going to learn about KEDA and CNCF Sandbox projects, what they are and how they work, and learn about some of Tom’s insights in the industry.
He’s going to talk about how GitHub is helping the world of Open Source projects and how he uses the platform to engage with the users.
We’re going to hear his opinions about the future of tech as well as discussing how we can use what we already have in a better way.
Enjoy the episode and don’t miss the links and resources that Tom shared with us, you can find them at the bottom of the page.
Guest Bio:
Tom Kerkhove is the creator of Promitor.io , he works for Codit as an Azure Architect and he’s also a maintainer of KEDA and Arcus as well as a GitHub Star and a CNCF Ambassador.
On top of this, he’s also a member of the AZUG crew and he has been a Microsoft Azure MVP & Azure Advisor since 2014.
He’s very passionate about Open Source Projects and Tech in general and he’s very committed to constantly improving them going forward.
You can find Tom on GitHub where he’s very active and you can read the articles that he posts on his blog on blog.tomkerkhove.be where he shares his expertise with the community.
Quote
“Let’s not worry about the next big thing, but let’s make sure we use the current technology at its best .” Tom Kerkhove
Timestamps:
Connect with Tom on:
Promitor and KEDA projects in Github:
Links mentioned in the Episode:
Connect with Cloud Gossip on:
Connect with Annie on:
Connect with Karl on:
Thanks for listening to Cloud Gossip! You can find us from our website CloudGossip.net.
Please leave us a review and subscribe to us at iTunes, Google, or Spotify!
Karl: [00:00:00] In this episode we cover expectations versus reality of open source, the ins and outs of open source giants, GitHub, and Cloud Native Computing Foundation, impact of open source in personal and societal level and habits that we can all pick up to make the maintainers lives easier.
Here's a quick taste of the episode, and then let's get going.
Tom: [00:00:22] "If we don't have the company supporting their own supply chain, then that's a big risk because maybe in half a year or a year, that will not be there anymore. And there's been a lot of discussion with IdentityServer which decided to basically make it an official product and that people will have to start paying. "
Annie: [00:00:43] This is Cloud Gossip, the podcast demystifying the cloud and the people behind it.
Hi, I'm Annie. I'm a cloud native technology marketing manager, and I've worked for tech companies ranging from startups to fortune 500 enterprises.
Karl: [00:01:07] And my name is Karl and I'm a cloud security leader working at a Swiss financial sector company.
Annie: [00:01:12] You are listening to cloud gossip. And in today's episode we're going to talk about open source, GitHub and the life of an open source maintainer.
Karl: [00:01:21] Today's guest is Tom Kerkhove.
And Tom is a CNCF ambassador, a GitHub star. and an Azure MVP.
He's a maintainer of open source projects like Promitor and Kubernetes Event Driven Auto-scaling or Keda. Welcome to the show Tom. Tell us a little bit about yourself. What do all of these things actually mean?
Tom: [00:01:43] Thank you very much for having me, and what does this mean...
Well, let's just summarize it as "I love technology". That's my hobby as well. Let's put it like that.
So I'm Tom Kerkhove, I work for a company called CodeIt and there I've been Azure Architect. So my goal is to bring my customers to the cloud and let them build scalable platforms on top of it. And as part of that, I've seen a few gaps in the ecosystem, let's say.
And that's why I started getting involved in the open source community....so both Promitor and Keda were a goal to solve these customer needs. Which they are using today now.
Karl: [00:02:29] Makes sense. And you said you are an Azure architect and specifically I'm assuming that's building applications on top of Azure, not building the Azure there itself. But I also hear here that you work a lot with Azure product groups and give some...give a lot of feedback from your open source work in there.
That sounds really interesting...as well.
Tell us a little bit more on your day to day work, before we go to our main topics of today.
What does it mean for you? Do you work with a single customer? Do you go...every day is another customer.... or what's your day to day work as an Azure Architect in CodeIt?
Tom: [00:03:07] Yeah, so typically, I have a handful at most customers and I'm more of the...a person who has long-term assignments, because if you built platforms, this typically takes time to design, to build, and also to have this in production and make sure that it is operable.
So I typically have a few customers where I do end-to-end front design, all the way to production. Yeah, I think that's the most interesting customers because then you also see platforms grow and you get to learn from the mistakes that you've made,...which is also super important.
Karl: [00:03:45] And when you say platforms can you give any examples, you don't maybe need to name names, but what would that mean?
Tom: [00:03:52] For example, my current customer is a building a multitenant connected city platform.
I worked for a very similar Swiss company and reinsurance building platform to basically sell flight delay compensation, sell insurance products for hurricanes and floods, and then making them available to their partners.
So not the end-users directly, but to their partners, so they can integrate with that platform and build their products on top of that as well.
So I really liked the multi-geo projects and the multi-tenant projects, which are challenging because I find them very interesting.
Karl: [00:04:38] So you're building software for building software, both in your day-to-day work and your open source activities.
Tom: [00:04:45] Yeah, that's totally correct. Yeah.
Karl: [00:04:48] So, with that segue, let's get to our main topics of the day....and let's start talking about your open source projects and your main projects are Promitor and Keda, or actually, how do you pronounce that? Is it Kada or keda?
Tom: [00:05:04] It depends who you ask. I always say Kada. But, uh, yeah, actually from....I got involved with Keda because of Promitor. So let's maybe start there.
So I was working for that Swiss customer and they were using Azure cloud services at the time, which is...still today very nice services....if you ask me.
That allows you to do message processing. You deploy your application. If you define how it should auto scale and all the rest is handled for you. So it's a true PLA pass platform.
But from the Microsoft side, there is not much investment.
So that customer who's worried should be look at alternatives. And at that point in time, Kubernetes was really gaining a lot of momentum. And we're talking, uh, I think, two or maybe three years ago already. So they decided to go with AKS and we basically ported that platform. We wrapped it in a container, deployed it on Kubernetes, and then they noticed that...Kubernetes...well, actually Azure Kubernetes Service is not a platform as a service, as cloud services was. It's a cluster platform as a service.
So now they add a lot of more responsibilities...like we need to auto-scale the cluster. We need to auto-scale the apps, et cetera, et cetera, et cetera. But then we're using Azure service best queues.
So they had to auto-scale based on those metrics. But there was no way in Kubernetes to auto-scale on external metrics. So there was the concept of metric adapters and at that point in time, there was only a stack driver adapter and a Prometheus adapter. So my proposal was okay, let's make sure that we can bridge the Azure monitor metrics to
Prometheus we deploy Prometheus, and then we can auto scale based on Prometheus.
Then they decided that...that was too much work for the use case....so they just over-provisioned. Which is also fair because it's just queues you catch up anyway. But I visit them a lot on site in Switzerland, so I was in hotels a lot when speaking. So I had a lot of time on my hands on airplanes and hotels and all of that stuff.
So I just figured, "Hey, why not write this thing anyway, it can be fun. What could go wrong?"
Fast forward to today, and I don't do anything else other than that. But um..., so the main goal for Promitor was really auto-scaling, which is one of my most interesting points. So I was building Promitor and then, uh, I think one year and a half or so later...somebody from Microsoft wrote a Azure monitor adapter.
So instead of having the need of Prometheus you could use that instead. So at first I was a bit concerned because I felt like it was trying to compete with Promitor, but then I said, "Hey, if this is going to help people more, why not just help there?"
So that started ramping up. I didn't do much contributions to that project itself.
Um, but then half a year later, Microsoft and RedHat started KEDA, which basically closes that whole gap. So the goal of KEDA was really to make application auto-scaling dead simple... with a main focus on event driven scaling,because it came from the Azure functions team, but I figured this is what all my customers need and what all our future customers need. So we better jump in and guide the project in a way that it will help them.
And then I got involved with that one and I think in January, we...um... donated it to the CNCF as a sandbox project. And we just released a 2.0 version, I think now one month ago or so, and my current customer is also using it.
So it's really nice to see the adoption of KEDA in the whole community, which is for me
a....basically the community saying "you are really solving a big problem now, and we're happy that this is now so simple.
But yeah, it takes a lot of time. Luckily I'm not the only one on that project. So we have Zibneck from RedHat and then other people like Jeff Holland also helping on that.
So it's really nice to have other people as well.
Annie: [00:09:26] Yeah, sounds amazing. And really ....teamwork is the best work, honestly, so.
Tom: [00:09:33] Otherwise it's not really sustainable
Annie: [00:09:35] Yeah...for sure. So what is it like to maintain a popular open source project? So what's kind of like the expectation versus the actual reality of it.
Tom: [00:09:45] There's two types of maintaining an open source from what I've seen. So there is the sponsored projects where companies basically donate manpower, let's say, and money to contribute in them. Red hat and Microsoft are an example with KEDA, but I think 90% or 80% of the whole CNCF is this way....I think that's also the only maintainable way.
There's also other people who do it in their spare time, like me. And then it's a bit more challenging in my opinion, because... it takes a lot of time and typical open source project to maintainers want to..., basically rolled into it because they wanted to code. But if I think how much I do effective coding, I think it's less than 20% because you're the developer, you're the product manager, you're the release officer. Let's say, you're basically doing everything end to end, which is, it's really nice to do it, but. Sometimes you underestimate what needs to be done in running approach. And, you only notice that when you are a maintainer. Before data is like... it's coding all the time and the documentation is written automatically.
The tests are done automatically. So... and then you do a release and then all the bugs start to surface and then they ask and you fix this by tomorrow. And then, yeah, it's really, it's a lot of work, but still it's really nice to do it because I can contribute back to the community and help others fixing problems that they have as well, which also changed my vision on software, where instead of thinking should we open source it?
My vision now is more, why should we not open source it? Is there IP that we cannot release? Or from a strategic point of view that we cannot do? Or do we just opens source it? Because open sourcing also comes with a trade off. If it's public and people start using it, we also have some sort of responsibility in maintaining it.
So it should also not be done lightly. But that's also why I code it. We are now doing more and more open source. We also now happen open source .net. Library to make it easier to do things with Azure.
For example, where half of it is basically, um, seeing what we do with customers and what we do every time.
So we started with templates, reusable components, and now we also open sourced internal scripts, for example, that we have. Where we figured, why is this even open source? From a customer standpoint, it's also dangerous because we're using something proprietary from a partner, which we now have access to, why should we do that?
And that's why we decided to open source it
Annie: [00:12:42] Yeah. It makes a lot of sense. And if this, depending on the viewpoint, grim reality did not deter anyone away. If one wishes to....how would they get started with contributing to an open source project?
Tom: [00:12:55] I would also always say, and again, that's my vision that has changed, but if you're depending on a library or a tool or something, and you have the skills instead of opening an issue and say "Hey, can we get X feature?"
Maybe you should also consider looking at the code and see how much effort it is and then propose, "Hey, can we have X feature?" And I'm willing to contribute it. That allows you to contribute back and help that project. But you'll also learn from other people, how they build certain software or how they do testing.
And it's really nice to then have that shipped version of that library, which has your feature. So that's a starting point. That's also why I strive to use the...."It's just a pull request away" mentality. So all the code tests, source code build and deploy everything is in source control, so that if somebody contributes a feature they can do everything, they don't need me to do anything.
Now, the second thing is Hacktoberfest.
Hacktoberfest is a yearly event where people can join and then for... I think it is five or 10 pull requests that you do, you get a t-shirt at the end, or you can plant a tree by fixing issues, which are marked with the Hacktoberfest label.
This year it went a bit wrong because there was a lot of spammers let's say, were they created new accounts, they created stupid pull requests, which basically exploded a bit... giving a lot of extra work to maintainers. Because you have to review all the pull requests, take the time to go through the ViseNet.
So, if you do it, do it because you want to really add value. Don't do it for the t-shirt, but that's also a good way to get started. And you can also watch for issues which are labeled with "help wanted" or "good first issue". And if you go to GitHub, it also shows you that based on the language. So if you don't have any project that you specifically want to contribute to, but you want to do something. They can basically help you discover those projects.
Annie: [00:15:09] Yeah, that's amazing. Really helpful to get started on that front.
So as mentioned before, KEDA is a sandbox project in the cloud native computing foundation. So how is it working with CNCF? What changes when you go towards a more widely governance project ?
Tom: [00:15:28] For us, it didn't change a lot because with still sandbox....it's fairly simple aone and very.... very small. The only thing that happened was we had to transition the domain name. We had to change the license, and more of the government stuff .For the rest I think it's a positive move because now we are vendor neutral. Everybody can use it. Everybody can contribute back.
Yeah. It's just, it shows that Microsoft and RedHat want to give back to the community as well. And CNCF also helps with things to maintain these projects...like we...... I hacked together a documentation website because everything was just in the GitHub people, but obviously it was ugly, it was just a Jekyll templates, which we published with GitHub pages .
For once we were a sandbox project, we requested some help from them because they have marketing services.
They have design services. So then somebody from CNCF basically created a whole new website, donated to us, clearly documented how we can use it. And even today we are still using that website, which is now more user-friendly. Because, you should not underestimate the value of documentation.
As a developer we typically don't like to write documentation. I don't like to write documentation. What's a product worth without documentation if nobody can figure out how to use it.?
So it is really important. And that's why...um... you should always try to write good documentation. It will help your customers , it will always..... also you in the future because you will not remember how something works, which happens a lot to me.
So that also helps. Um, so more of the services around maintaining projects so that you can focus more on the project itself, which is really nice.
Karl: [00:17:28] Very interesting. And I think I won't be the only one who doesn't really know the backgrounders and the different terminologies there. So, could you maybe explain a little bit, what does a sandbox project mean?
What is required if I would want to get my project to the CNCF sandbox?
Tom: [00:17:47] I think they changed the process since we onboarded, but CNCF has three categories.
So sandbox, and then you can change the incubation if you are more mature and then eventually become graduated. So graduated projects are like Kubernetes, Prometheus and all the like.
And if you do an overview, you'll have, I think they only have...10 ish graduated projects, but in terms of sandbox, it's really gigantic. So what's the criteria?
Basically the CNCF uses a TOC and then you have to propose your project, um, and then fill in what it is. How it basically fits in the CNCF ecosystem. There's some other criteria, which I don't know from the top of my head, but then basically the whole TOC votes.
Should we add this or not? And if you have enough votes, then you basically become part of the CNCF.
Will for example, Promitor be accepted as a CNCF project? I don't have the attentions, but I
think it would be rejected because it's just maintained by me, while with KEDA, it was maintained by five...five people from three different companies. So it gives a different perspective. It gives a higher indication of sustainability because it is not one company....it is three and you have five people. So all these things come into play. They also have a look at the community. Is there a community? Or are we fixing an actual need?
Those kind of things. So there is some work in getting in the CNCF. You also have to present and all of that. But it is definitely worth it.
Karl: [00:19:29] And I think that sustainability of the project or maintainability there, I think that's a good segue to really this elephant in the room of open source.
Open source doesn't usually mean free to use, or doesn't always mean free to use.
In your case, the projects are free to use and you're not dropping your day job, and just living off the licenses of that ....and just working on those contributions. So, when a project becomes more popular and maintaining it can take a lot of time. As you said, fast forward, two years later, you are doing nothing else than that!
So, how do you balance working full-time, being a new parent, keeping up with ever-growing OSS backlog and yeah...all that jazz..
Tom: [00:20:22] Yeah, frankly. It is very hard. It takes a lot of time. Don't do it for the fame as a figure of speech, because you will have to make sacrifices. So my wife is out for work tonight.
So we have this podcast, when the podcast is done, I'll go straight back to work and work on Promitor for a couple of hours...and then that's my day. So, it really takes a lot of time and investment then. And all those free moments that you have will go into the open source project, because there are people depending on me on shipping this new version, for example.
So you should really make sure that you deliver what you promise. So, it takes a lot of time.
And, I used to do a lot of writing. I still love writing, but I just don't have the time anymore. It's really choosing what do you want to do? I had some other opportunities in the past where I had to choose because it is not possible to combine them.
And then I said, okay, I have these customers waiting for me, so I cannot let them down. So, I chose for this, which is super important. And weekends, evenings....all of that is always ...not always, but really a lot spent on open source and yeah....
You have to choose for it. So if you want to start an open-source project, don't take it lightly.
I hope it is super busy because that means then people are using it. But yeah, it really comes with sacrifices. And it's also tricky because in the end I don't earn anything ....because like you said, everything is free. So why should I do it?
Maybe I'm just the moroon let's say, because it's free. Um...but in the end...you also get something back in the sense that people like what you're doing, it's being used.
And it's also nice to see how Microsoft likes it. Because for example, in the past, they invited me to Redmond to do a hackathon. Um, because they liked the project....and they wanted to contribute back. So they had a hackathon with 10 people adding features, because they know it is valuable. And for me that is more rewarding than getting money for it.
But of course you can't eat, gratitude or reputation, or however you say, so....
So, so important...
Karl: [00:22:53] I mean Hackathons have a lot of snacks, right?
Tom: [00:22:56] That is correct. Yes. Uh....maybe that brings me to sponsorship, because I have been very, very, very reluctant to adding sponsorship because it really gives an..... it can give an indication that I'm doing all of these contributions for money.
Well, I'm really not doing it for the money, but it helps me pay for my Azure computes, my domain names, giving stickers to people, getting services to help me build these things. And ...that's why I did it, because then people can also show their gratitude and sponsoring. And thank you Carl, for being one of my few sponsors.
But this really helps and also gives yo...., keeps you motivated in doing it....so, that's why I'm also now focusing a bit on that, on making sure that people contribute back, because if that will not happen, It is not sustainable.
Meaning not because of the money, but because of the gratitude and it's not being shown.
We have a lot of companies that depend on open source projects. Like they the .netcore system has a lot of them. AutoMapper, slash Burchell. All of these are basically written by individuals. If you use it on a day-to-day basis, why don't you can't basically support them? Because the cost of migrating away from it will be higher because you did not support that one maintainer.
So you need to support your supply chain. That's why I'm happy that GitHub is now also starting to focus on that front, which really helps.....helps with that.
Karl: [00:24:40] Yeah, yeah. And you mentioned sponsorship, uh, but... what sort of other relationship do you have with your customers beyond, uh, requests and issues through GitHub and sponsorship.
Do you have like telemetry or do you have like a chat channel somewhere where you can engage with people?
How is that engagement or community around those projects?
Tom: [00:25:05] Yeah, now that's one of the most trickiest things.... I think with open source is ....it is free .
Both Keda and Promitor are docker images. So it's available on Docker hub. So I frankly have no clue who's using it. I fully rely on people opening issues and using GitHub discussions to ask questions.
But for the rest, I have no idea. And that's one of the biggest..... it's not an issue, but it's one of the hardest things in maintaining an open source project. And that's also what I'm trying to change with GitHub as a GitHub star my main focus is sustainability and gaining insights on who is using your project.
Because if you don't know who's using it, how can you make sure that they're getting the most out of it or they are fully.......uh, they get the features they need.
So that's really hard. And I found I'm using a few metrics to get an indication, like GitHub stars. It's not really that valuable, but you can see the adoption, let's say to a certain degree. I won't say that's a real metric, but it gives you an idea. But since we have Docker images, uh, I also wrote a tool which basically keeps on pulling the Docker hub rest API to get the pull counts.
And then I can see the growth over time, which also gives an indication. But then again, if you have CI builds, it's constantly pulling...so... it's not really a full indication. So you really have to depend on those, and your community reaching out. Which is happening, but it doesn't really give you a full idea.
So one of the things that I started doing for that is listing customers on the documentation websites, both for Keda and for Promitor. But something I didn't expect was that, "Hey, if you want to have our logo on the website, you have to go through our legal department and sign this NDA, or this legal document."
And I'm like, "man, you're using free software. Why don't you just give back and just displaying?" Not because I want to brag with the companies, but just to show others that it is already being used .
And they trust this product. You should also trust it because apparently it's serving their....it's closing the gaps they have...so..
It is very hard. That's the summary of it....and I don't know how others do it. I'm still trying to find ways. But I think it's a bit more of a general problem and you really have to rely on the product, uh, on the community. So if you use something, just give them a kudos and let them know. And if they have something where you can list them.....yourself as a customer, just do it to help them.....and give them... get an idea of who's using it.
Karl: [00:28:05] That sounds like a very good call to action. And you already mentioned public pages where you could just add the documentation, evalue yourself as a customer and...just add themselves as a PR or just starting that ....into GitHub.
What does GitHub do? Kind of... What else can you do with GitHub to support this open source?And their ecosystem?
Tom: [00:28:28] So they're improving a couple of things. One is..... they now have, as of yesterday....actually yesterday in this case means with GitHub Universe. They announced GitHub discussions, which is now in public preview. So I had the honor of doing the private beta of this, but basically this allows you to, instead of fully relying on issues, you can now create discussions, which is either Q&A, or it is an endless discussion in general, so that your community can create.
They can basically move the conversation to discussions, so that issues are fully or backlog basically. So the work you have to d.
So this allows you to basically bring your community closer. If you were using something like Discord or Slack for your project, in theory you could now fully rely on discussions.
Is it a full replacement? No. But it basically helps people find frequently asked questions. So that's one thing. Then the second one is, the sponsorship that I mentioned.
And then an other thing they did, and that's a less....optimistic topic, is they now have a successor feature. I don't know if that's the English pronunciation, but basically if I pass away, I have assigned Martin Valeo.
The legendary Martin Valeo as my successor, because I trust he will take care of my projects and make sure he takes the decisions that are needed.
Which is also something that we should not forget about. If people rely on my projects, they should know that either I have passed away or the project is donated to a separate organization or they find a replacement.
But he can now manage, make sure that there is a future for my projects. And then lastly, they are starting to improve the insights. So, if you're using open source, so the public repos, you have some basic insights on your community. If you use GitHub enterprise as an organization, basically there, they really give a lot of insights on who's collaborating.
And all of that. So you get more insights. How long are the pull requests open, and these kind of metrics.
If you are using, for example, a NuGet package. Something else they surface is, if I use Swashbuckle... on the Swashbuckle, um, repo, you will basically see which projects depend on Swashbuckle.
Because they scan the repos and they know from the CS process that my project, for example, Promitor depends on Swashbuckle.
So over there you can already see a bit who depends on what. That's really great with .net, for example, where you can get that information. But with Docker images, you can really do that because there is no depends on if there's somebody creates a Docker image off of mine. So hopefully in the future...maybe who knows they might check Helm charts on which images are being deployed, for example.
And then I could know who's using my helm charts on my container images. So that would already give you an indication on that.
Annie: [00:32:08] Time for the first recurring segment of today's episode, which is future of tech.
So, our MO is to talk to the best people in the business, and we really wanna hear your thoughts on the future of tech. So what are the three things in tech that most make you excited at this moment?
Tom: [00:32:27] Ooooh, that's a whole other topic!
Um, I think the nice evolution that I'm seeing in the last couple of years is that when we went from on-prem to the cloud, which is super great, but not everybody can do that because of regulations and all of those things or latency. They need to keep their workloads either inside the country or still on prem and what we're seeing now, and certainly it's not just Azure.... Google does it as well, and Amazon.... is that they're bringing the cloud on prompt to us.
And they did a few attempts. Like they had Azure back in the early days, then they had Azure Stack. Now we have Azure Arc. So it's really a nice evolution of bringing the clouds to the customer.
And, it fully relies on containers with Azure Arc.
And...if you want it or not, containers are essential. That's why I also started with containers because I saw that. This is not a hype. This is not going away because containers make things super portable. And that's also why Kubernetes is used a lot for this on-prem story.
So that's what I would recommend to people to have a look at, but also be warned that it is a whole new world if you enter it. So....focus on what you want. If you're developer focus on the application side, if you're an IT pro focus on the cluster side. Because there's a lot of heavy lifting that needs to happen to make sure that it is.... you can run it.
And that's also why I think, um, open specifications have become more important. There's the service mesh interface, which basically gives you common features like traffic, management, traffic metrics, regardless of the technology you have to use it. So that it allows you to have a more portable application.
You can use an Azure service for example, but if you decide to go multi cloud or run it on prem, if you're relying on open source specifications, it is easier for you. You don't have to look, you don't have that locking anymore. And that can be very, um, ....on different levels as well because Azure Functions is an Azure Service, but it is also portable. You can run it as a managed service. You can run it on EKS, you can run it on prem. You can run it on maybe even a Raspberry PI, I don't know, but you can use the same paradigm, but just port it ....again with containers.
So, um, there's no way around that anymore. Maybe a little bit smaller, but at GitHub Universe, they also announced sponsorship for enterprises. So until last week you could only as an individual sponsor an organization or an older individual. Now a company can basically say, "Hey, we will support this project, this person, this organization. And that brings us back to what we said earlier. If we don't have the company supporting their own supply chain, then that's a big risk because maybe in half year...a year, that will not be there anymore.
And there's been a lot of discussion with IdentityServer, which decided to basically make it an official product and that people will have to start paying. But if your identity solution, um, is open source and you're not supporting it, then I think you're a bit naive because it is such a fundamental product that you want to make sure that it keeps being maintained. It keeps being patched even.
And if you're not supporting it, then man, I think you can not be surprised that later it gets killed or it becomes a true product. So I think that's really a small step for GitHub and a big step for maintainers.
And then lastly, Azure Event Grid is still one of my most favorite technologies, and I know Karl will be laughing now, but it is an example of how Azure really is becoming an event driven platform with extension points for people who want to extend it. And I think Azure key vault is still the best example, where they will emit events when certificate will be rotated.
It will be expired, sorry. And when it has expired. So instead of the traditional approach where you have a reminder in your agenda to renew the certificate, hopefully in time, now you can fully automate it. When the event fires, you trigger an automation process, it generates a new certificate. Boom, nobody noticed.
And I think that is really powerful. So if you are part of Azure product group and you are listening, please integrate with Azure Event Grid, and you'll make me a very happy person.
Karl: [00:37:28] Excellent. Smaller plug there. And let's hope, all of you in the Azure PAGs heard that in your....right in time for your planning cycles.
Tom: [00:37:39] Let's hope so.
Karl: [00:37:41] All right. Uh, let's go for a more lighthearted question here. Not from the realistic perspective, but what would be your...let's say wishlist of technology. If you could ask anything....wave a magic wand and make any Sci-Fi technology a reality. Think about quantum computing, teleportation, all that jazz. What would you want?
Tom: [00:38:06] I find that's really a hard question. I come from.... initially I got into the community because I was a Kinect developer and the Holo-Lens was what I would have answered then. And I really like Microsoft visionary videos, which are really super!
But I don't really have any suggestions other than we should really use technology more to help improve, and this is really cheesy ,the world.
Where we could use it for...yeah... reducing global warming, for example, by automatically optimizing our electricity. For example, here in Belgium, the lights are turned on and off based on a time schedule, but if we could just have light sensors which detect that it is getting dark.
So we have to shut the...ummm.. turn on the lights, than I think that would really be a first step for example. And if you think about it from a technology side, that's fairly trivial to do. So I think that would be more my answer to your question on this front. Let's not worry about the next big thing, but let's make sure we use the current technology at its best.
Annie: [00:39:25] Wow. That's really inspirational and really cool. A really good way to approach the question as well. Yeah, great, so then we can move on to the second recurring segment of this episode.
So one of the goals of this podcast is to spread positivity and through our actions increase the positive impact of the tech world. This is why we have a recurring segment for diversity and inclusion topics in this podcast. So do you have currently any good favorites or projects that you have encountered that you really like...on this front?
Tom: [00:40:18] I don't have any particular projects but I like how the....how it is involving...and we really try to welcome everybody to contribute regardless of where you are from, who you are and what you do. We welcome everybody. That's also by like Hacktoberfest. And,if I have a look at what all the GitHub stars are doing, for example, they're really doing great stuff and helping people get introduced to the community.
And frankly, it doesn't matter who you are. It matters what you can give back. And that's really what value is to me, what, what the value is to me. And that's also why I try to make it super easy for people to help and try to also educate people on how to do things and guide them a bit. But other than that, I don't really have any specific topics to talk about.
Karl: [00:41:15] He said after listing so many interesting topics and work on improving on diversity and inclusion. Amazing! Would you have any specific tips to us and our listeners, to really help lift others up?
Tom: [00:41:30] Oh, yes! Don't ask for permission. Ask for forgiveness. Don't hesitate to do something. Always be polite, of course.
But yeah, there are no stupid questions. If you want to do something, but you're afraid because it feels like a stupid question, most probably you're not the only one with that question then.
If there is something in the documentation that is not clear, just check to clarify for yourself and maybe just sent that one PR to improve it because other people might also benefit from it.
And that way you also help the maintainers.
Because writing documentation, for example, is very hard because for you, it is very natural and clear because you wrote what you're building, but for your customers, they don't have all that background. So, I think that's a good way to get started there, for example, but never esitate to ask questions.
It's not because I'm a maintainer that I'm super intelligent or anything... on the contrary, but yeah, really be open, be polite and discuss things.
Annie: [00:42:43] Cool really good summary! Then for the third and final recurring segment of this podcast,
Yeah, so no one does this or anything alone, and it really takes a village to raise a child. So would you want to give a shout out to any communities close to your heart or really plug any of your upcoming projects?
Tom: [00:43:18] Always a hard question as well. So, I would give a shout out to Zbynek Roubalikfrom RedHat, who is also a maintainer on Keda, who really did a ton of work for us so that we can ship Keda 2.0.
He's really a smart guy.
And then I would also like to thank Sam Neirinck, which is an ex colleague from me who basically triggered the whole open source mentality with me. Which got me where I am today and yeah I'm thankful because it is really nice too, to be in the open source space and to....to be part of the community and contribute back.
And then what's next. I'm finalizing the Promitor 2.0 release as well. Hopefully it's lightning this year. I still remember designing a feature with Martin Balliauw at Iglooconf this year.... which was really great. Drinking, a lot of coffee...with snow.
So now it's time to make it a reality. And then....for next year, I've been trying to write blog posts for more than a year on my adventures from doing open source.
Which is now growing to a whole blog post series. So now it's finally time to....to get it out of my head and write it out so that people can learn from it and maybe also get into the open source mentality, and contribute back more to projects that they depend on.
Karl: [00:44:51] Wow. Excellent. That was a lot of shout outs.
All right. So it's time to wrap this up.
Today we talked with Tom Kerkhove maintainer of Promitor and Kubernetes Event Driven Auto-scaling. We learned all about expectations versus reality of open source. How cloud native computing foundation, GitHub and open-source standards are bringing open source projects to the next level. Why each Azure product group should implement Azure event grid. And finally, a reminder to all of us, we shouldn't be afraid to ask questions.
Annie: [00:45:25] Yeah. So Tom, truly thanks for being here today!
Karl: [00:45:29] Pleasure to talk with you Tom!
Tom: [00:45:30] Thank you for having me.
Karl: [00:45:37] Hey, thanks for listening to Cloud Gossip. You can find us from our website, CloudGossip.net. Please leave us a review and subscribe to us at iTunes, Google, or Spotify. .