Abstract
Let’s start with a story about a challenge.
No service or system is ever perfect, or finished. It should constantly be adapting and evolving to meet the needs of its users, and how they work. There’s always something to be done.
And, not too long ago, the Adobe I/O team had some specific changes they wanted to make to improve the product for their users.
“The logging subsystem we previously had inside Runtime was tricky for our team to administer, and needed a bit of improvement”, said senior computer scientist Dan McWeeney.
“As an example, a function logging a large number of log lines could only retrieve them via the command line interface in batches of ten. This obviously made for a tedious experience. And the highly distributed nature of the original architecture made it hard to monitor for failures.”
In this case, Adobe’s own Developer Experience (DevX) team was willing to help.
“They kindly offered to help us make this subsystem fully pluggable, so we could deliver log lines to external systems configured by customers,” said McWeeney.
“So instead of seeing logs in batches of ten at a time, the customers could get them in something like Splunk.”
So far, so good. But how does a collaboration between two such teams work? How would the work be split up? What sort of solution would emerge, and when?
The answer to this lies in Adobe’s commitment to an approach known as “Open Development.”
What is Open Development?
When trying to understand Open Development, it can be helpful to think about it as a way of doing things.
In 2017, Adobe Digital Experience group’s principal scientist Bertrand Delacretaz laid out an “Open Development Manifesto”. This manifesto highlighted some of the key elements of a methodology that had defined Adobe’s culture for several years.
Read Full Blog
Q&A
Please use this thread to ask the related questions.
Kautuk Sahni