Made by
Made by
A forest ecosystem
Matt Asay
Adobe may not be the first company you think of when it comes to self-service APIs or open source. After years of building products that work well with each other, Adobe has put open source industry veteran Matt Asay in charge of building a lasting developer ecosystem.
Of course, Adobe isn’t just Photoshop and Illustrator. Whether you loved it or loathed it, for a while Flash had one of the web’s most active developer communities. So it’s not that Adobe is coming to this entirely without experience, but it’s certainly a change in emphasis.
And, as Matt will explain in his upcoming DevXCon talk, building a new developer ecosystem starts with listening both to what external and internal developers need.
For Matt, there’s just one developer ecosystem. Whether a developer is an employee of Adobe or an external developer using, say, the Typekit API, it doesn’t matter. But that approach is not necessarily built into the DNA of most traditional software companies.
“Unless you’re a Twilio or you’re a MongoDB,” says Matt, “most companies just don’t think about third-party developers. And then they one day say, ‘Oh, I saw RedMonk saying developers are the new kingmakers’ and I sure would like a developer community around my product.’ And they realize they’ve done nothing.”
At Adobe in particular, the focus has been on creating products for end-users and not necessarily for developers. “As a general rule,” Matt says, “Adobe’s muscle memory has been very much around, ‘How do I build something to work with other Adobe products?’”
The role of Matt’s team is to help change that instinct.
“We’re working to change the idea that we should ever build something was only for internal consumption. Why would we ever build, for example, an API that was only for internal consumption? It’s getting outside of that mentality of building for someone across the cubicle to someone in some other team in the same company and by extension, to third-party developers.”
In a company the size of Adobe, there’s a question of whether the internal versus external divide even makes sense. “Why would you ever build something in such way that it’s only useful to the person who sits in the cubicle next to you? It doesn’t make much sense. So, how do you get from building for Jane who works across the way, to building for somebody else within the company who may not know what all of my priorities are, who may not work with me on a day to day basis? How do I make my code easy for them to use or to access?”
According to Matt, once you’re building software for internal developers on other teams, the question becomes, “Why not just open it up to third-party developers at that point?”
Such a change is not without its challenges, as Matt acknowledges.
Building for people you don’t know means creating documentation and code samples, as well as crafting APIs to make them accessible to third parties.
It’s hard, as Matt says, to retrofit infrastructure onto existing products and, equally, it’s been hard to retrofit onto an existing mindset.
So, how do you bring along thousands of developers on such a big change?
It’s a mix of making sure engineering leaders are on board and exciting developers about the possibilities of building products that anyone could use.
“On the top down side,” says Matt, “we are spending a fair amount of time with engineering leaders to make the argument, ‘Hey, if you’re building, don’t think of internal APIs as internal.’
“We want to build in such a way that the switch could be flipped and those products could be made accessible to third-party developers.”
Bottom-up, it’s about removing the bureaucracy that inhibits employees from open sourcing their code or contributing to external open source projects. There are tangible benefits for Adobe.
“For us to be a good platform company, we need to think beyond the four walls of our firewall.
And while open source is not a perfect proxy for thinking like a platform company, it is helpful in terms of getting engineers to think about, ‘Oh, I need to write my code in such a way that somebody out there that I don’t know can make use of my code.’”
The key to making such a change work is listening to developers. That includes understanding the needs of the developers who might integrate Adobe’s products or engage with their APIs.
“The customer is critical,” Matt says, “But if I had to focus on just one thing, it’s working on that internal developer culture, because that will change more than anything else.
“It’s the way your company thinks. There are technology aspects of it, but it’s really a cultural thing.”
Matt is no stranger to cultural shifts. After 18 years of working in open source companies including MongoDB, Canonical and Alfresco, he has seen the role of developers shift from basement-dwellers to, as RedMonk dubbed them, the new kingmakers.
The power of developers is now recognised across increasingly diverse organisations, not just tech companies, but at car giants such as Ford, multinationals like General Electric or retailers including Marks & Spencer.
“At the CXO level, there is a fundamental appreciation now for the importance of developers,” he says.
“And it’s not just about placating developers, but finding ways to make them productive. That’s a massive shift over the last 20 years.”
Matt will be discussing his own work to implement a cultural shift at Adobe in his talk “Developer secrets your customers to tell you … if only you’ll listen” at DevXCon 2018 which runs in San Franciso over June 4 and 5.
Matt Asay speaking at DevXcon