Re: Users versus developers (was: Tempo mark alignment)

[Anthony W. Youngman]

In message <address@hidden>, Tim 
McNamara <address@hidden> writes
> On May 23, 2009, at 5:05 PM, Anthony W. Youngman wrote:
>
> > In message <address@hidden>, Ari Torhamo 
> > <address@hidden> writes
> > > > The first option is achieved by handling everything a non-programmer
> > > > can do: managing bugs, helping new users, writing the newsletter, 
> > > > etc.
> > > > The second option is achieved in two ways: helping expand our
> > > > community (and hoping this way more programmers will join on a
> > > > long-term perspective), or hiring someone (with decent money) to let
> > > > him learn the code and implement the feature/fix the bug you want.
> > >
> > > You don't quite seem to get Tim's point: everybody can't and doesn't
> > > need to participate every project they find useful - especially when
> > > they don't consume the resources of the project in question (more 
> > > than
> > > marginally). Most people don't contribute equally to things in their
> > > life - people specialize, which is good, because they have different
> > > lives, situations, skills and talents. It's good to encourage 
> > > people and
> > > make them aware of the ways to contribute - and then leave it to 
> > > them.
> >
> > Unfortunately, Tim's point is at odds with the philosophy of free 
> > software - which can be pretty succinctly stated as "he who writes 
> > the software makes the rules".
>
> Ummm.  That's not the philosophy of free software.
>
> http://www.gnu.org/philosophy/philosophy.html
>
> Indeed, projects governed by Anthony's description of the philosophy 
> tend to die quickly or get forked and the original developer loses 
> control over it.

Well, if somebody's writing code, they're not dead, so if they follow my 
philosophy then by definition they CAN'T be dead ...

And, having been involved in a project (actually one I started), then a 
new developer took over from me and took the project in a direction I 
didn't like, but it wasn't a fork. He took over the coding. The only way 
I could have stopped him was to do more code myself (and I didn't have 
time).
> > And while I think that Graham is often more "bad cop" than 
> > necessary (I've fallen foul of him too :-) he does have somewhat of 
> > a valid point - if you're not prepared to put in any work then why 
> > should other people put in work on your behalf?
>
> Because if those things adversely affect my use of the application, 
> the odds are very good it adversely affects someone else's and maybe 
> lots of someone else's use of the software.  Graham's idea (I am 
> interpolating here, he can correct me if I'm wrong) that "people 
> should be willing to put into the project is very valid."  My point 
> was that the form of those contributions is going to vary with 
> people's abilities.

Agreed. My main contribution in the past was proof-reading, and Graham 
expected me to contribute patches. Bit difficult if I'm proof-reading a 
hard copy and don't have a system that can make patches.

> For reasons already mentioned, I'm not going to  learn Scheme and I'm 
> not going to contribute code.  It is very myopic  to define "helping" 
> as "writing code" (this is a widespread problem  in the FOSS 
> community). On the other hand, I am a psychologist with  some knowledge 
> of how people interact with information and those  skills might offer a 
> way to contribute and I have tried to do that.   Also, my use (and 
> others') of the software, feedback on its  usability, etc. is of utility.
But at the end of the day, if you don't code, you don't have direct 
influence on the project. And as I know from experience, "usability" and 
all the other "soft" stuff is very subjective. What's usable to one 
person is a pain in the neck to someone else.

My example of this is "reveal codes" in WordPerfect (oh - and I hate 
OpenOffice because it's a copy of MS Office and I find their usability 
decisions make the whole thing unusable - the more WordPerfect tries to 
become Word-like the less usable it is). My brother had a similar 
experience with "unusable" emacs - he now thinks its wonderful - it 
hasn't changed, he has.

But at the end of the day, as I say, he who writes the code makes the 
rules. If you're not prepared to get your hands dirty, you are reliant 
on other people doing what you want, and they are free to (indeed, quite 
likely to) ignore you unless you're prepared to make it worth their 
while.

Cheers,
Wol
--
Anthony W. Youngman - address@hidden