The Open Developer Manifesto

As part of the Adobe Experience Manager team, I help drive Open Development. We developed this manifesto to guide our approach which has defined a large part of our team culture over the last few years.

It’s not a magical recipe to make people behave and collaborate nicely, but expressing these principles has helped us clarify how we work and create a baseline for developer expectations.

Most of it applies to other roles, so you could replace the word ‘code’ with many others and it would still work. But don’t start a funny meme around that, please!

Here’s our manifesto:

I love writing software that people actually use and find useful, fun and reliable.

I work in an open way, commit early and often so that others can see what I’m doing while that evolves, and discuss things on our project’s mailing lists instead of using 1-to-1 email. I “talk to the project” instead of talking to people directly.

I’m not afraid of others respectfully challenging my technical decisions and/or my code. Nobody’s perfect, and I’m learning a lot from our ongoing, open and informal peer reviews.

I’m used to living with my code for several years after I write it. Any technical debt will usually be on me.

I thrive for very high quality in my code and in our products, and won’t be shy to respectfully express my disagreement if something puts that at risk.

I’m not afraid of throwing away code when it’s not good, even more so for code that’s at the core of our products.

Whatever I’m working on, it’s backed by a ticket in our issue tracker.

In the tracker, my tickets are granular and organized in graphs of dependent tickets, to make it easy to organize my work, see it progress and farm out parts of my work to others when needed.

Most of my email is throwaway — I create wiki pages, tracker tickets or text files in my source code repository for information that’s durable and useful to others, instead of sending around detailed knowledge in email, so that each piece of relevant info has a permanent URL. Email is where information goes to die, so if it’s durable it belongs elsewhere.

I speak in URLs — using precise references in my on-list emails instead of vague concepts like “last week’s memory issue”.

If it’s not in the shared code repository it doesn’t exist — whatever code I create is there, the rare exceptions being big test data files that won’t reasonably fit in there.

Besides our product development this also applies to our Adobe I/O projects at http://adobe.github.io/ — please have a look and we welcome your contributions there! If you’re interested in learning more about Adobe and Open Source, visit http://adobe.ly/opensource