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
Hi Seth,
The closet thing I have here on opensource.com is this one: https://opensource.com/life/15/11/my-open-source-story-guy-martin
Here is a video from a recent talk I did at SIGGRAPH this year that talks a bit more about my role at Autodesk: https://vimeo.com/228368053
I hope these help and give you some idea of what we're up to. :)
Thanks for your comment Kevin.
Yes, we did look at a lot of Slack (and other tool) alternatives, but, I could have written the chapter/article above and literally done a search/replace on the word Slack with any of the tools you mentioned. In other words, the most important thing was *how* we built a community around a tool that my co-workers had self-selected. The tool is almost irrelevant in this case.
There is almost no practical benefit (other than cost) to moving to another tool, and, in this case, since my user base doesn't care whether the tool is open source or not, but only cares if their user experience (including API compatibility) is impacted, moving to an open source tool just for the sake of it being open source would end up doing more harm than good in the long run.
The most important thing in this project was changing an entrenched culture that didn't talk to each other before. If that means using a proprietary tool (or any tool - hey, it could have been smoke signals for all cared :)), but we get the benefit of a more 'Default to Open' culture, I'll take that trade-off anytime.
Thanks.