3 MIN READ
Pam Baker | 13 November 2017
Autodesk is undergoing a company-wide shift to open source and inner source. And that’s on top of the culture change that both development methods require.
Autodesk is undergoing a company-wide shift to open source and inner source. And that’s on top of the culture change that both development methods require.
Inner source means applying open source development practices and methodologies to internal projects, even if the projects are proprietary. And the culture change required to be successful can be a hard shift from a traditional corporate hierarchy to an open approach. Even though they’re connected, all three changes are distinct heavy lifts.
They began by hiring Guy Martin as Director of Open Source Strategy in the Engineering Practice at Autodesk, which was designed to transform engineering across the company. Naturally, open source would play a huge role in that effort, including spurring the use of inner source. But neither would flourish if the company culture didn’t change. And so the job title swiftly evolved to Director of Open @ADSK at the company.
“I tend to focus a lot more on the culture change and the inner source part of my role even though I’m working through a huge compliance initiative right now on the open source side,” Martin said.
The history of Autodesk’s open source transformation began shortly after the shift of all its products to cloud began, including its AutoCAD architecture software, building information modeling with its Revit products, as well as its media and entertainment products. The company’s role in open source in entertainment is now so significant that Martin often speaks at the Academy of Motion Picture Arts and Sciences on open source. They want to hear about what Autodesk is doing as part of a larger collection of initiatives that the Academy is working on, Martin said.
At Autodesk, the goal is to spring engineers loose from their business silos and create a fully open source, cloud-centric company.
“Your primary identity detaches from being part of the AutoCAD team or part of the Revit team, or the 3ds Max or Inventor team or any of these products,” Martin explained. “It’s now shaping you into part of the Autodesk engineering team, and not your individual silo as a product organization in the company.”
Talent acquisition is among the top business goals for Open@Autodesk, especially given the company’s intense focus on innovation as well as making all of its products work seamlessly together. It takes talent skilled in open source methodologies and thinking to help make that happen. But it also means setting up the team dynamics so collaboration is more natural and less forced.
“With company cultures and some engineering cultures, the freedom to take an unconventional route to solve a problem doesn’t exist,” Martin said. “A lot of my job is to create that freedom so that smart and motivated engineers can figure out a way to put things together in a way that maybe they wouldn’t have thought of without that freedom and that culture.”
To help create an open source culture, the right tools must be in place and, oddly enough, those tools sometimes aren’t open source. For example, Martin created a single instance of Slack rather than use IRC, because Slack was more comfortable for users in other lines of the business who were already using it. The intent was to get teams to start talking across their organizational boundaries.
Another tool Martin is working with is Bitergia Analytics to monitor and manage Autodesk’s use of GitHub Enterprise.
Martin says the three key lessons he’s learned as an open source program manager are:
- Stay flexible because change happens
- Be humble but bold
- Be passionate.
“I’ve been at Autodesk two years but I’m still bootstrapping some of the things around culture. We have strong contributors in some projects, while in some projects we’re consuming. I think you have to do both, especially if you’re bootstrapping a new open source effort in a company. ”
“The challenge is always balancing the needs of the product teams, who have to get a product out the door, and who (and as an engineer I can say this) will take shortcuts whenever possible. They want to know, ‘why should we be doing this for the community? All we care about is our stuff.’ And it’s getting them past that. Yes, we’re doing work that’s going to be used elsewhere, but in the end we’re going to get benefits from pulling work from other people who have done work that they knew was going to be used in the community.”