What Keith Lofstrom Is Thinking About for Dirvish.
I fully expect many folks to contribute changes; in fact, the process of learning how to do this correctly will probably in itself be worthy of documentation.
If you want to write a bunch of code contribute, I'm not going to say "go ahead", but that is only because I cannot guarantee how this will go after we decide how to decide. But work will continue on dirvish, and contributions will be welcomed. The specifics of how that happens still needs to be worked out.
I will be at the O'Reilly Open Source Conference next week, and will ask various people about the best way to proceed. My inclination is for us to continue development in whatever way the open source community usually proceeds on these things. What I will have to figure out is what kind of role to take; I am not much of a programmer, but I can read code and run code and patch code, and I can usually smell bad design, if not produce good design outside of my area of competence (integrated circuit design).
Open source, and Linux, operates by an evolutionary process that often produces capabilities much more quickly than it produces robustness. This goes against my training, but I have to admit that it works pretty well, and gets to a robust product faster than the rigid approaches do. Managing this kind of thing will be difficult, but is worth learning how to do.
Dirvish specifics:
Probably one place that I differed a LOT with JW was on the value of comments. JW thought they broke the flow of code; I usually write stuff that is 70% comment. I would like to see more comments in the code, but they may consist of a bolus of explanatory text on top of each script, along with a separate design document, if that is what the consensus of the programmers working on the project.
For style, I can consult with Randal Schwartz, who is a buddy, and with other Perl luminaries, to get a feel for how close to the Perl mainstream this structure is.
Beyond coding style, there are a few things that need doing, IMHO:
1) Gathering contributors and getting a discussion going. Hence the site and the wiki.
2) Deciding how to decide. Managing programmers is like herding cats. Best done by understanding cat/programmer motivation. I don't like dictatorships, and I don't like democracy-by-the-loudest-shouter. So this will be interesting.
3) A lot more documentation, with examples of specific systems.
4) A guide for the co-design of dirvish configs and disk/system config. Some of this might be automated. These functions should remain separate, of course, but they should be part of one system design.
5) A guide for the co-design of tripwire-style functions with Dirvish. (I understand there are better options than tripwire). These functions also should be designed together, and operated together, IMHO.
6) Some general cleanup of config types. Some of the config descriptions are more Perl-centric, and accidents of the data types used, than user-centric. This is dangerous ground, we don't want to break existing setups. In general, I would make things a little more permissive, and easier for non-Perl coding newbies to understand.
7) A test suite. Is Dirvish working? Is it backing up the right stuff?
8) Perhaps some judicious borrowing of extra capabilities from Backuppc . I don't like GUIs, but what do our users want?
All these things are subject to discussion or dismissal. The above is an attempt to make public some of my thoughts, not to make demands or force a particular set of directions.