Guy Martin is the Director of Open Source & Standards at NVIDIA, where we works with the Omniverse product team on helping them navigate the open landscape with projects such as Universal Scene Description, MaterialX, and many others. He also consults with the rest of the organization on open source best practices.
Guy brings a unique blend of 25+ years’ experience as both software engineer and open source strategist to NVIDIA. He has built open source programs for companies like Red Hat, Samsung and Autodesk and was instrumental in founding the Academy Software Foundation while Director of the Open Source Office at Autodesk. He was also a founding member of the team that built the Open Connectivity Foundation while at Samsung, helping to successfully integrate FRAND standards with open source reference implementations. Most recently, he lead OASIS Open as Executive Director, where he helped to merge the best of open source and open standards for that organization. He is a passionate advocate for diversity and inclusion in technology and an accomplished public speaker.
An avid, lifelong athlete, Guy is based near Nike World Headquarters in Beaverton, Oregon, U.S.A.
Authored Comments
I agree with you in principle Rebecca, but let me share the anecdote from my past at Red Hat that caused me to use that as an example.
Note - I *loved* my time at Red Hat - I wouldn't have traded that for the world, as it taught me a ton about open organizational principles, and I really enjoyed working with Jim and others in the company on what would become the (unfortunately) short-lived Open Source Enablement Pathway consulting offering.
When I was building the consulting offering (with open organizational principles), we came to a point that I needed to hire someone to help me in actually delivering it (we had several customers that had signed on). We had to 'borrow' an open req from one of the Cloud consulting teams, and, we got permission both from my manager, as well as our group's Senior VP to hire a specific individual (who was young, but perfect for the job).
What happened next continues to floor me to this day - we explained the situation to the HR team, with an emphasis on the time critical nature of this hire (e.g. - we had customers waiting for delivery who had already paid), and..... they sat on it, then later came back with a 'we don't agree with this hiring decision because the candidate doesn't have the skills sets for this open req.'
Um, yeah, that's what we said when we presented the case to you. Long story short, even though I had the support of a Senior VP to actually make this decision, plus the support of those who'd interviewed the candidate, I almost lost them due to the need for 'everyone to have a vote.'
I think there are cases (like this) that happen all over the company, and that makes it difficult to move the business forward.
Thanks Jono,
These are interesting questions, and having just finished the book (and having been at Red Hat to learn some of these things first hand), I have some thoughts on your queries:
The most effective way I've found to communicate this is to determine what areas in a company would be a good fit to start out with these principles. While I completely understand and respect Jim's points in the book, I also feel that some parts of the organization (legal, HR) aren't good candidates to run in this fashion, as they require too many 'hard real-time' decisions.
That being said, pointing out to senior leadership how a project like the Linux kernel manages to put together high-quality software on a regular drumbeat with worldwide participation is usually an eye-opener for companies that can't seem to communicate even across internal teams.
Clearly, Red Hat is the poster-child for this type of organization, but, as even Jim admits, it's not perfect, and it's constantly evolving. It's *critically* important when 'selling' this to a company that the notions of 'release early, release often' get understood correctly - this is an evolutionary process, not something that happens overnight.
Jim also correctly points out one of the major risks, which is knowing how to 'close debate' and 'move on.' My time at Red Hat (while awesome) was rife with examples of times where it probably took much longer to 'move on' than it should have, costing the company time, money, or both. A major challenge therefore is making sure that there are strong influencers (not just leaders) who can properly corral and harness these discussions.
I look forward to hearing more from other folks in this Book Club. :)