Many people have read Stevey's post. where he contrasts agile with Agile. Stevey does a great job of separating out the important "agile" value system from the methodologies and processes of "Agile" that were created to help the masses implement it.
Because in fact, it is in the implementation of agile that the values sometimes get lost. Ive' seen Agile often bundled with Extreme Programming tactics (Test-Driven Development, Paired Programming, etc.). which muddied the waters and resulted in teams claiming "agility" simply because they have junit tests. When people focus on processes, tools and methodologies too much, they can't see the forest for the trees.Likewise, I believe we need a similar separation between values and implementation in "open development". In the details of the implementation, there are decisions about licensing (GPL or Apache?), and community (Java.Net or Sourceforge?). These can be argued just like people argue over the details of Scrum vs. Lean Devlopment vs. RUP. But in the end, "open development" manifests itself more so within the attitudes of the team members, than in the implementation decisions -- just like "agile".
Thus, humbly, I'd like to propose just such a manifesto:
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
- Open discussion over closed "white-paper" analysis.
- Collaborative contributions to existing efforts over proprietary (re)invention.
- Open sharing of experiences over knowledge hording.
These combine with an overarching desire to commoditize the lower-level functions of the software stack, allowing all software development (and service-delivery) to focus on ever harder more valuable problems.
Enlightened developers often embrace the above values without knowing it, just like many of the same are inherently agile (in the "move fast and react fast sense of the term"). Others operate with a very closed mentality, despite the fact that sometimes they've "open sourced" their code.
For example, we often see "white-paper" analysis performed by the evil genius architects that lock themselves in a room with their crystal ball, carefully considering all options, finally emerging with an architecture that accounts for all the requirements, *and* all of the unforeseen changes to come (notice the paradox). Meanwhile, the enlightened developer has spent the same time discussing the options on a mailing list, effectively forcing some of the "unforeseen" changes forward in time by soliciting input from others and adopting suggestions (even if they don't directly address existing requirements).
Likewise, once an enlightened developer accomplishes a feat, he/she will blog about it to advance the productivity of the community at large, whilst the less enlightened will add this to their little secret bag of tricks enhancing their "job security". (the same developer goes on to prove black is white and gets himself killed in a crosswalk)
I was in diapers when the pioneers were doing the real work on open source. So I feel presumptuous even suggesting such a manifesto and I certainly don't intend to even hint that these are novel thoughts. I'm sure the likes of Eric Raymond and others have been espousing such values for years. My only point (if any) is that the Agile Manifesto did a great job of distilling agile into four statements that could be internalized by all. Open Development might be served well to do the same, separating it away from the "noisy" licensing debates discussing freedoms, and capitalism.FWIW.
No comments:
Post a Comment