[csw-maintainers] Our core values: providing straightforward experience to the user

[Philip Brown]

On 11/18/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote:
> No dia 16 de Novembro de 2010 21:18, Philip Brown <phil at bolthole.com>
> escreveu:
>
> I think your contributions to the project in terms of examining
> packages and discovering issues, are really valuable.  I admire your
> patience and insight.
>
> However, the 20 years experience argument leaves me unimpressed.  I've
> seen people with 15 or 20 years experience, who, when asked to write a
> shell script, write something that doesn't work, and asked about the
> big-O notation of the complexity of the script, can't work out the
> answer.

I know what you mean. i've seen people like that. :-} usually been at
the same low-level job for those 20 years.
So let me share more detail of my experience, and how that benefits my
position of release manager.

In my 20 years sysadmin experience, I have worked in almost every
segment of the IT industry.
I have worked for 2 fortune-500 companies. I have worked for 3 'higher
education' institutions. I have also worked for a silicon valley
startup company.

I have worked at places where the release process was "Go for it!". I
have also worked at places where you were expected to file a full
change management document, a week in advance, for any changes.
I have worked in places where there were only 10 machines to deal
with. I have worked in places where there are hundreds of machines to
deal with.
I have worked to support machines where the attitude was "eh, its okay
to be down for a while".  I have worked to support machines where the
importance was, "If you screw things up, you'd better clear out your
desk, because the company just lost $1million or more".

I have also supported a wide variety of users. From the highly
knowlegeable set, to the "Where's the 'any' key?" set

And on a general computing competency note: I have a degree in
computer science, and have had assorted chunks of code accepted into
solaris... BEFORE the whole opensolaris source tree type access was
started.

So, there's where my judgement for package quality comes from :)


> At the same time, the 20-years experience people are those who learned
> to put up with crap around them, and would rather continue to do that,
> instead of introducing change.  It's the fresh people who notice crap
> and have the energy to improve.  So, if you want to reason from
> experience, it works against you as well, experience makes you also
> ill-equipped for making decisions.

Erm... I think that a fair evaluation of my track record, shows that I
am highly in favor of change: just so long as it is positive, well
planed, and well managed change.
*cough* I did bring network-enabled automated package installation to
solaris, after all.
Plus suggested the CAS framework. and worked on *some* of them,but
then mostly stood back and encouraged other people to implement their
own.
And other things I'm probably forgetting.

Summary: "change for change's sake=bad. researched and planned change = good"
Most recent example: the pkg namelength change. I didnt block it just
to block change. I wanted to make sure it was fully researched and
thought out.
And good thing I did, otherwise we'd have a 'new standard' that
violated solaris capabilities, hmmm?


> What I asked in the original question, was _how_ do you know what's
> best for the user.

I take my experience I mentioned above, and try to figure out how the
package would best meet the needs of ALL the different types of
environment and users if possible.
If there's a fundamental conflict between "please these folks, or that
folks", things get complicated.
On the one hand, it may make no sense to deploy an application in one
setting, so I ignore that segment if need be. But usually, I keep an
eye more tuned to the "large, corporate style" usage cases.  The
reasons being:

- Most people who work with "open source", have no idea of (nor do
they even care to think about) impact to large scale deployments.
Someone needs to plan it.
- (From the user's perspective) It is easier to take clean methodology
brought on by corporate deployment styles, and then deploy for a
single user... then it is to take a lazy "it works good enough for me"
single user oriented package, and then attempt to shoe-horn it into a
large scale deployment.
Most corporate folks who hit the latter style, will just say to
themselves, "okay these guys are clueless/have no idea what they are
doing... we cant trust them to provide packages for our needs", and
give up on opencsw for any purpose whatsoever
(whereas an individual user may not like one particular package, but
use the rest of them)
That is why I push particularly hard for large-scale-friendly
packages. We cant grow OpenCSW to full potential, if we dont meet the
needs of the large scale deployments well.

Not only is this important as a general customer principle, but it
also affects your interest in web search placement.  "corporate
worthy" sites, tend to get higher ranking.
No corporate buy-in, means we lose writeups, and references. Which
means we will be lower in search engine ranking than otherwise.