Latest / Chief in Tech Deep Dive Shortcast / Chief in Tech S1E8 - Virginia Mayo, Aysha Khan, Bhawna Singh, Stephanie Domas: AI, Leadership, and the Future of Cybersecurity

Transcript

Chief in Tech S1E8 - Virginia Mayo, Aysha Khan, Bhawna Singh, Stephanie Domas: AI, Leadership, and the Future of Cybersecurity · Chief in Tech Deep Dive Shortcast

• 0:00
  Welcome back to the deep dive. So today we're
• 0:02
  tackling something that is, well, it's pretty
• 0:05
  much the foundational layer of all modern technology.
• 0:08
  We're talking about open source software, you
• 0:10
  know, OSS. And for most of us, especially if
• 0:12
  you're not on a development team, you hear open
• 0:14
  source and you just, you immediately think free.
• 0:17
  Right. Free as in it doesn't cost anything to
• 0:19
  download. But that view is so simplistic and
• 0:22
  it completely ignores the immense economic power
• 0:25
  behind it, the strategic advantages and frankly,
• 0:28
  the critical operational risks involved. OK,
• 0:31
  let's unpack this. We really need to move the
• 0:33
  conversation from thinking of OSS as like a niche
• 0:36
  hobby project to what it actually is. It's a
• 0:40
  global multi -trillion dollar industry and it
• 0:43
  demands an intentional strategy, not just accidental
• 0:45
  adoption. Exactly. So our mission here is to
• 0:48
  give you that strategic framework you need so
• 0:49
  you can really get the benefits of OSS while,
• 0:52
  you know, protecting yourself from the risks.
• 0:54
  And let me just set the stage with something
• 0:56
  I can say with a near certainty. If your company
• 0:59
  develops any kind of software, you're already
• 1:01
  using open source. Oh, for sure. Whether you
• 1:04
  know it or not. Absolutely. It's likely running
• 1:06
  your infrastructure. It's embedded deep inside
• 1:09
  your commercial products. It's in your supply
• 1:11
  chain. The prevalence is just, it's staggering.
• 1:14
  And that's why moving from just passively using
• 1:17
  it to strategically managing it is probably one
• 1:20
  of the most critical decisions a leader can make
• 1:22
  right now. So let's nail down the definition
• 1:24
  first, because the philosophy here is actually,
• 1:26
  I think, pretty profound. It's about capturing
• 1:28
  the world's collective intellectual effort, all
• 1:31
  this creative freedom, but as code. It's brilliant
• 1:34
  people from all over the world collaborating
• 1:36
  to build software that is, by design, open for
• 1:40
  everyone to see, to contribute to, and to use.
• 1:43
  And that transparency is really the key. I mean,
• 1:45
  to be officially called open source, the software
• 1:47
  has to meet several criteria that guarantee that
• 1:50
  freedom. The absolute core principle is that
• 1:53
  the source code has to be available. Anyone using
• 1:55
  it has to be able to look inside. Transparency
• 1:57
  isn't a feature. It's the prerequisite. OK, so
• 2:01
  having the code available is step one. But it's
• 2:03
  the license, right? That's what actually grants
• 2:05
  the rights to do things with it. Precisely. It
• 2:08
  must be free to be redistributed. And crucially,
• 2:11
  you're allowed to create derived work. Meaning
• 2:14
  you can build on top of it. Yes, you can take
• 2:16
  that code, you can modify it, and you can build
• 2:19
  your own innovation on that open foundation.
• 2:21
  But, and this is important, you have to maintain
• 2:23
  the integrity of the original author's source
• 2:26
  code. And our sources are clear this goes way
• 2:29
  beyond just the code itself. It's about a complete
• 2:31
  lack of restriction. It is. The license has to
• 2:34
  be distributed with the code. But it can't discriminate
• 2:36
  against anyone. No discrimination against people,
• 2:40
  groups, fields of work, or even technology. So
• 2:43
  a license couldn't say, you can only use this
• 2:45
  on brand X hardware. Exactly. That would fail
• 2:48
  the definition. Open source grants, quite literally,
• 2:51
  freedom of software. Now, when companies use
• 2:53
  this software, it seems to fall into two main
• 2:55
  buckets. The first one is frameworks and libraries.
• 2:58
  Yeah, think of these like components, Lego bricks
• 3:00
  almost. They're these modular pieces of code
• 3:03
  that do one very specific thing. Maybe it's a
• 3:05
  cryptography library or a really sophisticated
• 3:08
  graphing tool. So it's not the whole application.
• 3:10
  Never. They're always meant to be just one piece
• 3:13
  of something much bigger. And the second category
• 3:15
  is solutions. Solutions are the applications
• 3:17
  themselves. They're standalone. A full chat program,
• 3:20
  a database system. You can use it on its own
• 3:23
  without plugging it into anything else. OK, let's
• 3:25
  talk about scale. Because this is where the conversation
• 3:27
  really shifts from a philosophy about code to
• 3:30
  just massive industrial dependency. I want to
• 3:33
  repeat this number because it's wild. It's estimated
• 3:36
  that 96 % of all software code bases in the world
• 3:40
  use open source components. 96%. And even more
• 3:44
  critical for business, commercial applications.
• 3:47
  The software that companies actually sell can
• 3:49
  be made of up to 99 .9 % open source code. That
• 3:53
  99 .9 % number, it often trips people up. They
• 3:57
  ask, why would a company sell something that's
• 3:58
  almost all free stuff? Right. The answer is all
• 4:01
  about efficiency and focus. And this is where
• 4:03
  that medical device example really clears things
• 4:05
  up. Can you walk us through that again? Of course.
• 4:08
  So let's imagine a super complex proprietary
• 4:11
  medical device. The company's core innovation,
• 4:15
  their secret sauce, their IP, is all centered
• 4:17
  on one critical function. Let's say it's ensuring
• 4:21
  the extremely precise timing and dosage of a
• 4:24
  drug delivery. That's what they spend billions
• 4:26
  on R &D for. That's their unique value. That's
• 4:29
  why a hospital pays a premium for their device.
• 4:31
  Exactly. Now, that same device also needs to
• 4:33
  do other things. It has to connect to the hospital
• 4:35
  network, handle security, respond when someone
• 4:37
  presses a button, draw a graph on a little screen.
• 4:40
  All necessary things, but they're basically generic
• 4:42
  IT problems. They are generic IT problems. Yeah.
• 4:45
  And these problems have been solved and debugged
• 4:47
  and optimized thousands of times over by the
• 4:50
  open source community. So why reinvent the wheel?
• 4:52
  Why would you? Why would that manufacturer spend
• 4:55
  its precious time and R &D budget rewriting a
• 4:58
  networking stack? They just leverage robust,
• 5:01
  well -tested open source for all those adjacent
• 5:04
  needs. So when you see that 99 .9 % figure, it
• 5:07
  just means they were being smart. They focused
• 5:10
  their proprietary effort only on that tiny fraction
• 5:13
  of a percent that was their real market differentiating
• 5:16
  innovation. And the economic impact of this model
• 5:18
  is just, it's colossal. There was a Harvard study
• 5:21
  that tried to put a number on this. They looked
• 5:23
  at the supply side value, so what it would cost
• 5:26
  to actually produce all these common open source.
• 5:28
  libraries, and they put that around $4 billion
• 5:30
  a year. Which is a big number. But the truly
• 5:33
  staggering metric, the one that should make everyone
• 5:36
  sit up, is the demand side value. OK, so this
• 5:39
  is the value that the companies using the software
• 5:41
  get. This is the value they capture. So if you
• 5:43
  calculate what they would have had to pay for
• 5:46
  commercial licenses for their own internal R
• 5:49
  &D to replace all that open source, the value
• 5:51
  delivered is estimated at $8 trillion. $8 trillion.
• 5:55
  That single number just fundamentally changes
• 5:57
  how you have to think about OSS. It's not a free
• 6:00
  gift. It's a foundational piece of the entire
• 6:03
  global economy. And that study had another key
• 6:06
  finding. Large companies would have to spend
• 6:08
  three and a half times more on their software
• 6:11
  development if open source suddenly disappeared.
• 6:13
  Yeah. That's the sheer scale of the leverage
• 6:16
  and productivity we're talking about. Here's
• 6:18
  where it gets really interesting because beyond
• 6:21
  just saving money, there are six key strategic
• 6:24
  reasons for companies to adopt OSS. This is about
• 6:28
  competitive advantage. And the first one is fundamental.
• 6:31
  transparency and trust. Because the code is all
• 6:33
  out in the open if you're, say, a major bank
• 6:37
  or a critical infrastructure operator, you have
• 6:39
  the ability to audit and inspect the code running
• 6:41
  on your most vital systems. You can actually
• 6:43
  check it yourself. You can verify its integrity
• 6:45
  yourself, which means you can make a truly informed
• 6:48
  decision about whether or not to trust it. And
• 6:50
  number two, it massively boosts productivity
• 6:53
  and interoperability. It does, because OSS is
• 6:56
  almost always built on open standards. It just
• 6:59
  naturally promotes interoperability, which is
• 7:01
  the exact opposite of getting locked into one
• 7:04
  specific vendor. Let's dig into that vendor lock
• 7:07
  -in a bit more, which is reason four. With proprietary
• 7:10
  software, you often hear about the friction of
• 7:12
  an MSA. For our listeners, what's an MSA here,
• 7:15
  and how does open source get around that? So
• 7:18
  an MSA is a master service agreement. It's this.
• 7:21
  This huge legal contract you sign with a proprietary
• 7:24
  vendor. It defines everything, support, pricing,
• 7:27
  usage terms, and critically, how hard and expensive
• 7:30
  it is to leave them. The switching costs are
• 7:32
  huge. Immense. The legal and financial hurdles
• 7:35
  to pivot away are just massive. OSS completely
• 7:38
  bypasses all that legal friction. So if I'm using
• 7:40
  an open source graphing library and it's not
• 7:42
  working for me anymore, I can just swap it out
• 7:44
  for another one tomorrow morning without months
• 7:46
  of renegotiating contracts. Exactly. No penalty
• 7:48
  fees, no lawyers. That flexibility is a massive
• 7:51
  strategic advantage. Then there's number three,
• 7:54
  open collaboration. This one is fascinating.
• 7:58
  You see developers from companies that are direct
• 8:00
  market rivals. Think competing cloud providers,
• 8:04
  all working together on core projects that push
• 8:06
  innovation forward for the entire world. It's
• 8:09
  an incredible engine for progress. And moving
• 8:11
  to number five, it's often the fastest way to
• 8:14
  get your hands on emerging technologies. That's
• 8:16
  right. When a hardware company like Intel or
• 8:19
  AMD create some new cutting edge capability,
• 8:22
  let's say in confidential computing, the very
• 8:25
  first libraries and code showing how to use it
• 8:27
  are often released straight into the open source
• 8:29
  community. It allows for super rapid experimentation
• 8:32
  long before the polished proprietary tools are
• 8:34
  even ready. And then finally, number six, the
• 8:36
  obvious one, cost reduction. The software is
• 8:39
  free to download and use, which is a powerful
• 8:41
  alternative to expensive proprietary tools. But.
• 8:44
  And this is the crucial pivot point of our whole
• 8:47
  conversation. This brings us to responsible consumption.
• 8:51
  Just because the code is free and available,
• 8:54
  it doesn't mean it's good. It doesn't mean it's
• 8:56
  robust or secure. Not all open source is created
• 9:00
  equal. And not all of it is enterprise grade.
• 9:02
  Not at all. So we should probably define that
• 9:04
  term. If I'm making a strategic decision, what
• 9:07
  makes a piece of OSS enterprise grade versus,
• 9:10
  you know, just something a hobbyist built in
• 9:12
  their garage? Enterprise grade means it comes
• 9:15
  with the kind of features and institutional support
• 9:17
  you'd expect from proprietary software. So you're
• 9:19
  looking for things like engineering help and
• 9:21
  support, documented and timely security patching,
• 9:25
  a mature feature roadmap with clear timelines,
• 9:28
  and this is maybe the most important, guaranteed
• 9:30
  long -term support or LTS. LTS. So that means
• 9:33
  they'll keep it updated for what? Often five,
• 9:36
  10, even more years. It's a promise of stability
• 9:39
  and access to updates. Okay, so if a company
• 9:41
  hasn't formalized a strategy for this yet, they're
• 9:44
  basically using a critical $8 trillion piece
• 9:48
  of their supply chain without assessing their
• 9:50
  risk. Let's give our listeners the key risk assessment
• 9:54
  questions they need to be asking. The first question
• 9:56
  is purely operational. What are our support requirements?
• 10:00
  If you're using this code in a core business
• 10:02
  function, something that absolutely cannot go
• 10:04
  down, you need enterprise -level support SLAs
• 10:07
  and guaranteed patches. But if it's for an internal
• 10:11
  R &D project? Then you might favor innovation.
• 10:13
  That would be perfectly fine with a community
• 10:15
  best effort model. And that kind of dictates
• 10:17
  the whole stability versus cutting edge trade
• 10:20
  -off. You might use the newest library on a dev
• 10:22
  board, but when that product ships, you have
• 10:24
  to prioritize stability. Exactly. And that leads
• 10:26
  directly into the highest risk area of all, which
• 10:29
  is licensing. The third question has to be, what
• 10:32
  type of license are you OK with, and are you
• 10:35
  100 % certain you are using it correctly? This
• 10:37
  is where the legal risk gets really intense.
• 10:39
  I know there are dozens of licenses, but maybe
• 10:41
  we can talk about the two big families and the
• 10:43
  danger one of them poses. Absolutely. So on one
• 10:47
  side, you have permissive licenses, things like
• 10:49
  MIT or Apache 2 .0. These are generally pretty
• 10:52
  safe for commercial users. They let you use the
• 10:55
  code in your proprietary product without forcing
• 10:58
  you to open source your own work. But then there's
• 11:00
  the other category, the one that creates a significant
• 11:03
  risk for companies that want to keep their own
• 11:05
  code secret. That's the copyleft license family.
• 11:08
  The most famous one is the GPL, the general public
• 11:11
  license. Copyleft licenses are often called viral.
• 11:14
  They have a condition that says if you create
• 11:16
  a derivative work from this code and then you
• 11:19
  distribute it, you might be legally obligated
• 11:21
  to release the source code of your entire derivative
• 11:23
  work. Including your own proprietary code that
• 11:25
  you mixed with it. Yes. all under that same open
• 11:28
  source license. So if you use a copy left library
• 11:31
  the wrong way, you could be legally forced to
• 11:33
  open source your company's secret sauce. The
• 11:35
  very thing you plan to sell. That's a commercial
• 11:38
  catastrophe. Yeah. It is the single biggest legal
• 11:41
  risk in this whole space. The math flips entirely
• 11:45
  when your free library suddenly means you have
• 11:47
  to give away your core IP. You absolutely must
• 11:50
  have your legal team involved to understand the
• 11:52
  precise boundaries of what derived work and distribution
• 11:55
  mean under these licenses. And then there's that
• 11:58
  other risk we touched on, the operational one,
• 12:01
  the abandoned life. Yeah, you build your product,
• 12:03
  the one you're promising to support for 12 years
• 12:05
  on this great piece of OSS. But three years in,
• 12:08
  the main developer gets a new job, moves on,
• 12:11
  and crickets. the project just dies. What happens
• 12:15
  then? Well now you have a critical dependency
• 12:16
  that's not getting any new features and much
• 12:19
  worse, no security patches. So you either have
• 12:21
  to take on the maintenance burden yourself, basically
• 12:24
  funding the project internally, or you have to
• 12:27
  scramble to re -engineer your product with a
• 12:29
  different supported library. It's a huge, tangible
• 12:32
  risk. Okay, so we've laid out the need and the
• 12:34
  risks. Let's get to the action. What are the
• 12:37
  concrete steps a leader should take to start
• 12:39
  moving toward responsible adoption? The single
• 12:41
  most important first step is creating an internal,
• 12:44
  formalized, open source strategy and policy.
• 12:47
  Every single company that develops software needs
• 12:50
  one. and it can't be ambiguous. So what are the,
• 12:53
  say, three non -negotiable things that policy
• 12:56
  has to lay out? First, acceptable license types.
• 12:59
  It has to clearly state if copy left licenses
• 13:02
  are ever allowed, and if so, only in very specific
• 13:04
  cases, like internal only tools, never in a customer
• 13:08
  product. Second, acceptable use cases. Can we
• 13:11
  use this for R &D prototyping or only for final
• 13:13
  products? And third, required support levels.
• 13:17
  When is enterprise support mandatory and when
• 13:19
  is community best effort okay? And I assume you
• 13:22
  absolutely have to bring your legal team in to
• 13:23
  create this. That is mandatory due diligence,
• 13:26
  yes. Your lawyers need to sign off on the acceptable
• 13:28
  license list and what it means for your specific
• 13:30
  business model. And for anyone listening who
• 13:32
  wants a good template, you suggested maybe a
• 13:34
  surprising source. Yeah, look at the public sector.
• 13:37
  The U .S. Center for Medicare and Medicaid Services,
• 13:39
  CMS, developed this incredibly intentional and
• 13:43
  public open source strategy. They detail exactly
• 13:46
  which licenses and in what situations their organization
• 13:50
  can use OSS. It is an excellent structured template
• 13:53
  for how to do this right. OK, so to put this
• 13:55
  into practice today, we've got three immediate
• 13:57
  action items for our listeners. The first, you
• 14:00
  have to identify where you're already using open
• 14:02
  source. Because if you don't have a policy, I
• 14:04
  guarantee you're using it. So mandate the use
• 14:07
  of software composition analysis SCA tools. Get
• 14:10
  a detailed inventory of every single open source
• 14:13
  component and its license in your infrastructure
• 14:15
  and products. You need to know your exposure
• 14:17
  right now. Second, start looking for new opportunities
• 14:20
  where using OSS gives you the biggest bang for
• 14:23
  your buck, whether that's cost savings driving
• 14:24
  innovation or just reducing that future vendor
• 14:27
  lock -in risk. And third, establish that formal
• 14:30
  policy we just talked about. Be intentional.
• 14:33
  Use that policy to guide your path to a truly
• 14:35
  responsible and sustainable adoption model. So
• 14:38
  we started this by calling open source free code
• 14:41
  and we've landed on a multi trillion dollar industry
• 14:44
  that is the engine of modern technology, an engine
• 14:47
  that requires serious, sophisticated strategic
• 14:50
  management. The freedom and transparency it offers
• 14:53
  are, well, they're invaluable, but that intentional
• 14:55
  due diligence around licensing and support is
• 14:58
  the only way to protect your own interests while
• 15:00
  still benefiting from this incredible global
• 15:02
  innovation. So what does this all mean? Well,
• 15:04
  we established that the demand side value, the
• 15:06
  value captured by commercial companies using
• 15:08
  open source is about $8 trillion a year. And
• 15:12
  yet, the developers and communities creating
• 15:14
  that fundamental software often struggle for
• 15:16
  sustainable funding. So here's the thought I'd
• 15:18
  leave you with. Given the immense financial value
• 15:21
  and leverage these major corporations are getting,
• 15:23
  what is the ultimate ethical and maybe even long
• 15:25
  -term business responsibility of those consumers
• 15:28
  to ensure the sustainable funding, the continuous
• 15:30
  security, and the vibrant community activity
• 15:33
  of the very open source projects they are completely
• 15:35
  dependent on for their own profitability? That's
• 15:38
  the strategic challenges worth exploring long
• 15:41
  after this deep dive is over.