In a corehackers discussion yesterday, David Golden suggested that collecting, reconciling, and unifying a vision for Perl 5 may lead to improvements in development processes, scheduling, and prioritization.
I know of no better description than James Shore's summary of Vision from The Art of Agile Development:
Every project needs a single vision....
Distance between visionaries and the product manager increases error and waste.
Some projects have multiple visionaries. They need to combine their ideas into a unified vision.
A vision for your project helps you identify success. It expresses what you believe to be important. It allows you to measure your completion of your success conditions. Vision defines what you're building, why you're building it, and when you've finished.
I've worked on several projects without vision. They've all failed to produce anything useful.
Vision in Practice
Vision affects every technical and philosophical decision made about the project. Which features are important? Which features can wait? Does one group of users deserve prioritization over another? Are there long term implications of decisions? What kind of organization works best?
Community-driven software projects with strong leadership often have strong visions. For example, David Wheeler's PostgreSQL Development: Lessons for Perl? expresses one element of the PostgreSQL core team's vision:
[The] PostgreSQL project can be explicit about what versions of PostgreSQL it maintains (in terms of regular releases with bug fixes and security patches) and can quickly deliver new releases of those versions. Because so little changes in maintenance branches other than demonstrable bug fixes, there is little concern over breaking people's installations.
PostgreSQL makes a priority of keeping old installations running. This leads to development practices:
[Every] time a major new version of PostgreSQL ships, a maintenance branch is forked for it; and thereafter only bug fixes and security issues are committed to it. Nothing else.
I write this not to contrast with any other project's vision or development practices; I write this only to demonstrate a strong connection between a well-defined vision and well-enforced development practices.
Vision for Perl 5
David also suggested that a discussion of motivations and goals may help the Perl 5 community converge on a shared vision. Here's my vision for Perl 5.
I would like Perl 5 to:
- Increase in usability and consistency, especially with regard to metaprogramming
- Change its default behavior to improve learnability for novices and to encourage writing maintainable, elegant code
- Become easier to modify and extend
- Allow further optimizations available in other dynamic languages (JIT, better garbage collection, automatic parallelization, serializable bytecode)
- Absorb widely-used and well-designed features tested from the CPAN, perl5i, and corehackers
You could summarize this into a simple phrase: "I want Perl 5 to become a better language for new development."
Now the fun begins: what's your vision for Perl 5 development? Feel free to post a comment here. (Be aware that I will unapprove any comment criticizing another vision; visions are positive statements of what you personally value. Express what you value instead.)