Question (or, maybe, a challenge): Can you "open source"-ify the description of a development _methodology_ so that you get some of the benefits of open source (many eyes, customizability, testing). I sort of envision specifying it via a directory structure plus documentation files, with human-editable file organization (i.e. not too much or too little text in one file) that 'compiles' into one document. Then, put that document source up on github, which would allow me (or someone) to fork it and make my changes, and offer pull requests upstream (to see if you think they or something like them would be valuable), and allow people to fork my repository downstream. Then, in an empirical fashion, you could see what modifications people feel strongly about. I'd envision having one 'index' page in the top most upstream, which additions could be very freely pushed to (unlike other push requests that you'd or a central team would curate and review to keep the upstream up to your desired purity), which anyone could link a url to their github repository, and a paragraph about their fork of the methodology and the reasoning behind it. (For instance, I feel strongly about "doing agile" on something more like a dual-track, one more standard agile team that responds to user stories for UI stuff and the supporting mechanisms, but then a second, separate more "waterfall" library team that standardizes central and shared implementations, responding not to user stories/feature requests but to conglomerate individual implementations that were required to do a particular user story, etc. I would totally fork agile or an agile-replacement to implement rules for this sort of bifurcation of action to produce a maintainable project.)