Message-ID: <408fd87a40c4957b2a8298e50db465fa2af43755.camel@HansenPartnership.com>
Date:   Tue, 20 Jun 2023 09:00:00 -0400
From:   James Bottomley <James.Bottomley@...senPartnership.com>
To:     Finn Thain <fthain@...ux-m68k.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     linux-doc@...r.kernel.org,
        tech-board-discuss@...ts.linux-foundation.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Documentation: Linux Contribution Maturity Model and
 the wider community

On Tue, 2023-06-20 at 13:48 +1000, Finn Thain wrote:
> 
> On Mon, 19 Jun 2023, Greg Kroah-Hartman wrote:
> 
> > On Mon, Jun 19, 2023 at 07:41:57PM +1000, Finn Thain wrote:
> 
> > > @@ -103,7 +103,6 @@ Level 5
> > >  
> > >  * Upstream kernel development is considered a formal job
> > > position, with
> > >    at least a third of the engineer’s time spent doing Upstream
> > > Work.
> > > -* Organizations will actively seek out community member feedback
> > > as a
> > > -  factor in official performance reviews.
> > 
> > Why are you removing this?  I write more performance reviews now
> > than I have have in my life, all for companies that I do NOT work
> > for. That's a good thing as it shows these orginizations value the
> > feedback of the  community as a reflection on how well those
> > employees are doing at their assigned job.  Why are you removing
> > that very valid thing?
> > 
> 
> I'm not preventing that. That's covered by level 4 and my patch only 
> alters level 3 and level 5.
> 
> Bonuses and salaries are tied to performance reviews so the hazard
> here are clear. Level 5 compels companies to seek feedback and
> naturally they will seek it from companies who share their goals. You
> ask too much of  employees if you expect them to put aside the
> corporate agendas and pursue the interests of the wider community.

Actually, I don't think we are.  Part of the mechanical effects of the
open source revolution was to empower employees over employers: it's
the employees who submit the code and are part of the community, not
the employer.  In many ways employees in Open Source become Ambassadors
and Agents for their employers.  There's a big drive in Foundation
driven Corporate Open Source to try to minimize this employee
empowerement effect, but it's there non the less.  A good open source
employee recognizes this, often moves employers keeping the same open
source community roles and tries to find a synergy between corporate
goals and community ones (the best actually alter the corporate goals
to effect this).

> Countless lawsuits over the last few decades made it abundantly clear
> that the goals of companies often diverge from those of the wider
> FLOSS community.

Yes, but with good employee guidance, convergence can be found.  In
many ways community manager positions at companies are about managing
the company goals rather than the community ...

> Consider all of the open source code thrown over the wall, the binary
> blobs, the binary modules, the built-in obsolescence, the devices
> shipped with vulnerabilities now reduced to e-waste because they
> cannot be fixed,  the vendor lock-in strategies, the walled gardens,
> the surveillance etc.

It's employers' money and time if they want to waste it in this
fashion.  Unfortunately theoretical education isn't always the answer
and some entities need a burned hand as a teacher.

> To my jaded mind, it is obvious that such reprehensible strategies
> can be advanced by co-operative employees given inducements from
> colluding companies. My patch won't prevent this sort of behaviour
> but it does remove a directive that would help facilitate it.

Most things in life can be abused.  When stating something like this
we're trying to encourage people to listen to their better angels even
if it risks abuse.


James

Powered by blists - more mailing lists