My Open Source Experience Podcast

Software supply chain security has been on the top of minds lately, for a very good reason. With most steps depending on digital infrastructure, there are a lot of opportunities for cyber attacks to happen. At the same time, there is an often silent mistrust in open source software, because it is designed and developed in public environments. People think that because everyone can see the source code, and is aware of some of the bugs in it that aren't fixed yet, it somehow gives them the upper hand to carry out attacks against these projects. There's something odd about this perception though.In this MOSE Shorts segment, Wayne Starr shares his view on the state of software supply chain security in the open source ecosystem. He highlights the XZ incident, and how it was caught because the software was open source. He also highlights that this challenge is also present in closed source software, however, it is much harder to spot. This makes proprietary software even less secure, and you have to work twice as much to ensure that you are well protected when using it. Think about the "SolarWinds vulnerability" as an example.Learn more about:- Why the open environment is an advantage fro security perspective- SBOMs and their applicability and application in different ecosystems, like Go, Python or C- Why it matters how you release software- Can people still be hobbyists in the open source ecosystem?- User experience, air-gapped environments and the Zarf project- The productization work that turns open source projects into products- A case for experimenting with something in the product first, and then implementing it in the upstream project

The recent times in open source have been bringing some changes, which connects back to governments' recognition of the importance to protect the cyber space. As modern life depends more and more on connected digital infrastructure, cybersecurity has become the center of attention, and concern. All digital products and services depend on open source software to varying extent, which brings open source into the spotlight, and highlights everyone's responsibilities in maintaining not just their own proprietary code, but also the open source projects they depend on.In this segment on the My Open Source Experience podcast, Ria Farrell Schalnat, Greg Kroah-Hartman, Michael Dexter and Tom Sadler share their stories and experiences in the areas of legislations, CVEs and cybersecurity, sustainability of open source projects and InnerSource.

Open source isn't just for software developers. In fact, there is a large legal community that is focusing on licenses, intellectual property, legislations and more to understand how these all apply to open source, and what is enforceable and how. However, law and legislations develop and evolve on a very different pace than technology and open source, which makes the intersection of these areas rather tricky. Have you faced any challenges throughout your journey?In this My Open Source Experience podcast episode Ildiko and Phil explore the intersection of law and open source with Ria Farrell Schalnat. Ria started out as a computer programmer, then she ventured over to the field of law, but always stayed close to tech through copyright, intellectual property, and eventually open source. Ria has a comprehensive understanding of these areas and shares some of her experiences throughout her career journey that made a difference for her and the law firms and companies she worked for.Learn more about:- Why learning is not an exercise to do alone- Conferences are often underrated, and how you can organize one yourself if there isn't any available in your area- The conflict between how laws and legislations are created and how software, open source or proprietary, is developed- Why investing in upstream work and participating in open source projects are necessary to be successful- SBOMs and cybersecurity

Maintaining a local fork of an open source project is like maintaining an illusion. It only gives momentarily control and becomes expensive to keep up over time. Have you experienced that already?This My Open Source Experience podcast episode evolves around this topic and explores why and how to invest in open source projects, including how to pick which ones to rely on, what to consider when setting up your organizational structure, and why avoid maintaining local forks.- Austen Bryan covers the benefits of relying on OSS projects, and how to pick the right ones.- Samson Goddy talks about why roles like Developer Relations don't belong in the marketing department- Greg Kroah-Hartman shares why you don't want to maintain a local fork- Federico Gonzalez Waite talks about educating people about open source and guiding a large organization through an open source transition- Michael Dexter shares his thoughts and experience with regulations, patents. copyright laws and how they've been affecting software development and the FOSS movement- Tom Sadler shares the benefits of investing in upstream work, and why maintaining a local fork turned out to be a bad idea for his company

Open source investment and involvement are still considered risky and expensive, even though there are individuals, companies and studies that say the opposite. What's your take on this?In this My Open Source Experience podcast episode Ildiko and Phil explore corporate involvement in the Linux kernel community with Greg Kroah-Hartman. Greg has been a long-term Linux kernel contributor and maintainer, being responsible for the stable branches. Greg had both personal interest in getting involved, as well as motivation from the company he worked for at the time. The Linux kernel has been a popular choice to build an operating system, and therefore corporate investment has been strong in the project with 80% - 85% of the contributors being involved in the community as part of their paid job.Learn more about:- What individuals get out of working upstream- Common mistakes and misconceptions companies have about involvement in open source projects- Cultural challenges and examples to resolve them- What successful companies did to thrive with OSS- How to be proactive to sync product and open source project deliveries

We often talk about collaboration in the context of open source, or at least externally to a company with partner organizations. However, especially in larger corporations, cross-team work is just as important as the teamwork itself. Working with other teams is often more complicated than it needs to be, for various reasons. These teams could be in different countries, or the company's structure might not allow them to work together efficiently. What can you do to fix that?In this episode of the My Open Source Experience podcast Tom Sadler talks about how he explored open source and InnerSource, and how he became an upstream contributor through the latter. Tom also shares how InnerSource helped teams within BBC to work together more efficiently, and how it allowed the company to work upstream as well.Learn more about:- Why and how to roll out InnerSource within a company- Metrics to measure team efficiency- Do you need an ISPO/OSPO?- What you need to know to consume open source safely and efficiently- Why you need to avoid having internal forks of open source projects

If you want your company to be successful you need to deliver value to your customers or you do'n't have a business. Using open source software is appealing, since the source code is available online free of charge. However, as much as it is available to you it is also available to others. So, what's your differentiator? What's your business value?In this episode of the My Open Source Experience podcast Austen Bryan, Ildiko and Phil dig into the challenges of incorporating open source into business, with intention. Austen has a software engineering degree along with an MBA, which has been giving him a very comprehensive insight and knowledge about the software ecosystem. Before moving to Defense Unicorns, he worked for the United States Air Force with a focus on acquisitions, and gained deep insight into how government agencies operate, including the supply chain for software and other resources. Austen learned about open source while he was working for the government, and now he's with a company that based its entire business on open source. So, why and how do they do it?Learn more about:- Defense Unicorns, and how they leverage and embrace open source- How to find business value around open source software- Benefits that don't come in the form of money and income- How to decide whether or not you should open source any of your projects

Building a business strategy is hard in general, and when open source becomes part of the equation it can get even more challenging.In the recent past there were multiple examples of companies changing the license on their open source project to something less or not at all open. This is often harmful to the companies themselves and the pattern is always harmful tot he open source ecosystem.In this episode of the My Open Source Experience podcast Gregory Kurtzer and Kelsey Hightower share their experiences to dig deeper into the challenges and solutions to building a business around open source.You will learn the following:- How to evaluate if your company is ready to get involved in an open source project or open up one of their internal ones- Why it matters who owns an open source project's trademark- Why is lock out sometimes worse than lock in- How to identify the business value when relying on open source projects- How to figure out which open source project is viable to build a business around- Empty promises don't work long term

In this segment of the My Open Source Experience podcast, Kelsey Hightower shares his current adventures, which includes a home improvement project.As Kelsey is now advising startups, rather than working in 9-5 jobs, he highlights the importance to keep your energy and drive, no matter when you retire, and how someone can't stop sharing once they started.While Kelsey talks about his adventures to install new bidets in his house, he also drives analogies to software development and decision making. Always remember before you start refactoring something:- You need to be careful to avoid breaking things- It needs to be backwards compatible- It needs to look better than beforeKelsey and Phil draw an analogy and describe engineers being somewhere between tradesmen and artists. Can you relate?But, does Kelsey have any working bidets in his house yet?