From 6f0d1dc6b922f1b103a8933a03c4ed5e10b290ef Mon Sep 17 00:00:00 2001 From: Jacek Antonelli Date: Thu, 28 Aug 2008 16:49:31 -0500 Subject: Added MANIFESTO.txt. --- MANIFESTO.txt | 178 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 178 insertions(+) create mode 100644 MANIFESTO.txt diff --git a/MANIFESTO.txt b/MANIFESTO.txt new file mode 100644 index 0000000..2a6fdb4 --- /dev/null +++ b/MANIFESTO.txt @@ -0,0 +1,178 @@ + + + THE IMPRUDENCE MANIFESTO + + + THE PROBLEM + + The Second Life Viewer suffers from a stifling atmosphere of + non-change. This atmosphere emanates from Linden Lab, whose + attitudes and policies discourage all but the smallest and most + superficial improvements. This is the result of the nature of + Linden Lab as a corporation; in particular: + + + * A lack of resources to invest in making significant + improvements to the Viewer. Linden Lab is stuck treading water; + they don't have the manpower to spend on making major + improvements to the Viewer. + + * A burdensome Quality Assurance procedure that punishes any sort + of change. The larger the change, the more it's punished. The + simple fact that all changes have to pass through such an + arduous process discourages anyone from attempting any major + endeavor. + + * A vast throng of paying customers who want the Viewer to remain + constant and familiar. If the Viewer changes, they are forced + to spend effort relearning it. The most vocal and abusive users + even meet change with sneers and insults. + + + Combined, these render Linden Lab ineffectual at dealing with the + fundamental usability problems that plague the Viewer: + + + * A cluttered interface that frustrates and confuses both new and + long-time users. It is difficult to learn, frustrating to use, + and obscures the thing that users actually care about: the + world. + + * Crude tools that force users into awkward and inefficient + workflows. The tools bear little relation to the way today's + users want to use them. Whether because these tools are + outdated relics of the past, or just half-baked non-solutions, + very few rise above even the "somewhat usable" mark. + + * Stability and performance problems that make the Viewer + unreliable for any real use. Viewer crashes are an everyday + occurance for many users, disrupting their activities, + destroying their unsaved work, and afflicting their lives with + undue stress and frustration. + + + We don't deny that Linden Lab has made some progress in these areas + over time. But such progress is slow and often superficial, because + Linden Lab cannot afford to make significant improvement. + Encumbered by their own nature, they are forced onto an untenable + road of caution, hesitation, and prudence. This is a path that can + lead only to stagnation. + + These fundamental usability problems will not be solved by Linden + Lab; their atmosphere precludes it. Even the contribution of source + code patches by open sourcers can only address one factor, Linden + Lab's lack of resources. Patch contributors are still affected by + the burdensome QA process and the community's anti-change attitude + just as much as Linden Lab developers are. Any endeavor which + relies on Linden Lab to approve and integrate changes will face the + same bottlenecks. + + + SOLUTION + + As I have described, Linden Lab's approach is characterized by + three factors that put a damper on significant improvement or + innovation: + + * Cautious, gradual changes over a long period of time. + + * Dependence on an overloaded central QA department. + + * Yielding to pressure from large numbers of users to reject + change. + + It stands to reason that a project which removed or reduced these + factors would be more free to make radical, fundamental changes to + the Viewer. Such a project would exhibit the opposite + characteristics: + + * More significant changes over a shorter period of time. + + * A scalable, hierarchical QA process to screen and approve + changes. + + * Less need to satisfy users who demand non-change. + + This is precisely the sort of project we propose to undertake. + Because our approach is incautious, and perhaps even reckless, we + have dubbed the project Imprudence. Goals + + The primary goal of Imprudence is simple: to greatly improve the + usability of the Viewer. In particular, there are 3 aspects of + usability that we intend to address: + + * Approachability. Improving comfort and ease of use, especially + for new or non-technical users. + + * Efficiency. Improving speed and ease of common tasks and + workflows. + + * Satisfaction. Improving the emotional effect of the software on + the user. + + This is not to minimize other aspects of usability, such as + reliability, accessibility, or internationalization/localization. + We recognize their importance, but lack the expertise to properly + address them. We welcome people with such expertise to join the + project and help. + + + METHOD + + In order to achieve these goals, we propose to combine the open and + distributed nature of open source development with the dedication + to quality design usually associated with commercial products. The + main highlights of our approach are: + + * Open, public project management. Our plans, goals, and roadmaps + are laid out on the table. Our code is published in plain view + as it's written. There won't be any sudden bombshells to + disrupt your plans. + + * A pro-change atmosphere. Change is natural and healthy, and it + is the only way to make improvement. We encourage experimental + change, coupled with evaluation to filter out the negative. + Users wanting a static, unchanging viewer should look + elsewhere. + + * Designers, programmers, and users working with each other. Good + software requires more than just a team of programmers. It + needs designers listening to users, programmers working with + designers, and users testing and providing feedback. Every role + is necessary and appreciated. + + * Commmunity involvement. There are many ways to be involved, + whatever your interests, skill set, or level of commitment. + Contributions are welcomed, not looked upon as burdens. + + * A modern, distributed development model. The Git version + control system makes it easy for programmers to work freely + without stepping on each others' toes. Easy and powerful + branching and merging tools mean that releases will never be + littered with untested, half-baked code. + + * A scalable, hierarchical QA model. New contributions work their + way up a hierarchy of approval, which will start small and grow + naturally as load increases. By the time a contribution reaches + the top of the hierarchy, it has been tested, polished, and + approved by multiple people, and is ready to be integrated. + + + A CALL FOR VOLUNTEERS + + Imprudence is an open-source, volunteer effort; it depends on + people like you getting involved! There are many ways to + contribute, and most of them don't require any programming skills + or special knowledge -- just some free time and the will to be part + of something great. + + If you'd like to contribute in any way, have a look at + CONTRIBUTE.txt. + + You have nothing to lose, and a better SL experience to gain! + + + SIGNATORIES + + Jacek Antonelli (August 27, 2008) + McCabe Maxsted (August 27, 2008) -- cgit v1.1