1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
|
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)
|
