Re: Realizing Good Ideas with Debian Money

[Russ Allbery]

"G. Branden Robinson"  writes:

> My two cents[4] is that DSA should make its purchasing and hardware
> solicitation decisions with the architectural security issue fairly far
> down the priority list.  It saddens me to say that, but this new class
> of exploits, what van Schaik et al. call "microarchitectural data
> sampling" (MDS), is a playground for security researchers right now; a
> big rock has been turned over and bugs are erupting from the soil in a
> squamous frenzy.  It will take months or years for the situation to
> settle down.

> To acquire hardware based on what is known today is to risk buyer's
> remorse.  Plan on inescapable remorse later; every chip vendor will let
> us down until corporate managers learn to treat confidentiality and
> integrity as feature rather than cost centers.  (And count on them to
> forget what they've learned after a few quarters pass without
> embarassing headlines.)

+1 to this.  So far as I can tell, about the only thing that seems to
correlate with being less likely to have side-channel attacks is less
sophisticated scheduling pipelines and processor architecture (read:
simpler, slower processors).  And this area of security research is
changing very rapidly.  I would expect several more novel attacks to
surface.

Processors that don't have a bunch of non-free, unauditable bullshit as a
proprietary control plane would obviously be better, but you'd be paying a
prohibitive performance price (not to mention other issues).  There just
aren't any good options right now.  Buy (or accept donations of) whatever
makes sense for other reasons, and expect there to be mandatory microcode
updates, kernel and virtualization workarounds, and security bugs.

-- 
Russ Allbery (r...@debian.org)   

Re: Realizing Good Ideas with Debian Money

[G. Branden Robinson]

At 2019-06-01T09:04:39+0200, Philipp Kern wrote:
> Are we then looking more closely at AMD-based machines given that
> those had less problems around speculative attacks?

To borrow a phrase from Christopher Hitchens, this comment gives a
hostage to fortune.

My team at work closely follows (and part of it contributes to) the
research in microarchitectural timing-channel attacks; we just covered
the white paper on one of the three new attacks (RIDL)[1] on Friday.

I'll say this now because I don't know of anything embargoed that could
get me into trouble: don't count on AMD's good smell just this second to
last.  Remember that the previous round of embarrassments
(Spectre/Meltdown) didn't entirely spare AMD and ARM, and we haven't yet
seen any ground-up reimplementations of CPU cores with publically
auditable, formally-verified proofs of immunity to microarchitectural
timing channel attacks.

I see no reason to reward AMD with purchases based on what may be an
accidental and temporary lack of egg on the face.  This is the same firm
that followed Intel into the land of unauditable system management
firmware[2] and acquired ATI and shut down the information channels
enabling good free video drivers to be developed[3].

My two cents[4] is that DSA should make its purchasing and hardware
solicitation decisions with the architectural security issue fairly far
down the priority list.  It saddens me to say that, but this new class
of exploits, what van Schaik et al. call "microarchitectural data
sampling" (MDS), is a playground for security researchers right now; a
big rock has been turned over and bugs are erupting from the soil in a
squamous frenzy.  It will take months or years for the situation to
settle down.

To acquire hardware based on what is known today is to risk buyer's
remorse.  Plan on inescapable remorse later; every chip vendor will let
us down until corporate managers learn to treat confidentiality and
integrity as feature rather than cost centers.  (And count on them to
forget what they've learned after a few quarters pass without
embarassing headlines.)

Some day, perhaps, if the universe is less than maximally cruel, we'll
have the option of server-class RISC-V systems with fully-documented,
formally-verified designs.  But that day is not yet here.

In the meantime, always keep a fork with some cooked crow on it ready to
hand, so that the next time you run into one of the many "pragmatic"
people in our community who puffed and blew about how we didn't "really
need" open hardware, you can invite them to eat the stuff and so be
silent.

One wonders how pragmatic they'll feel when it's _their_ private data
being exfiltrated.

[1] https://mdsattacks.com/files/ridl.pdf
[2] https://libreboot.org/faq.html#amd
[3] I don't have a good cite handy for this, but Michel Dänzer can
doubtless tell the story with more accuracy and precision than I
can.
[4] ...further discounted reflecting my rather low level of project
activity.


signature.asc
Description: PGP signature

Re: Realizing Good Ideas with Debian Money

[Russ Allbery]

Jonathan Carter  writes:
> On 2019/06/01 19:55, Russ Allbery wrote:

>> I very much doubt that our current donation-driven model would generate
>> US $1M per year on a sustained basis, particularly if you subtract
>> DebConf out of the mix (which I think we should, because that money is
>> essentially

> DebConf tends to bring in money for Debian, so not sure why you would
> want to subtract it.

You cut the part where I explained why.  :)  That said, I'm not deeply
familiar with how much of the money that is donated during DebConf
fundraising goes to general project funds instead of to putting on DebConf
itself; perhaps the money is not as earmarked as I thought.

-- 
Russ Allbery (r...@debian.org)   

Re: Realizing Good Ideas with Debian Money

[Jonathan Carter]

On 2019/06/01 19:55, Russ Allbery wrote:
> I very much doubt that our current donation-driven model would generate US
> $1M per year on a sustained basis, particularly if you subtract DebConf
> out of the mix (which I think we should, because that money is essentially

DebConf tends to bring in money for Debian, so not sure why you would
want to subtract it.

-Jonathan

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) 
  ⣾⠁⢠⠒⠀⣿⡁  Debian Developer - https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄  Be Bold. Be brave. Debian has got your back.

Re: Realizing Good Ideas with Debian Money

[Russ Allbery]

Adrian Bunk  writes:
> On Fri, May 31, 2019 at 04:07:54PM -0700, Russ Allbery wrote:

>> I could well be entirely wrong, but the part that I would expect to be
>> the most controversial is that, once Debian starts spending project
>> money to pay people to do work that other people in the project are
>> doing for free, the project is doing a form of picking winners and
>> losers.

> Perhaps I am wrong on that, but I am associating the term "picking
> winners and losers" as an ideological statement used by US Republicans
> and Libertarians. For most people outside the US the underlying
> "government is bad" philosophy doesn't make any sense.

*heh*.  Er, no, not even remotely.  I'm about the farthest thing you can
get from a US libertarian or someone who thinks government is bad.  I'm
sorry to have used a confusing term and muddled my point!

What I'm trying to get across here is that one of the rather fundamental
things about Debian is that everyone works on the things they care about,
and the project is mostly neutral about which of those things are the most
important.  What's the most important is decided in a very practical,
democratic way: it's what people are willing to work on.

This is isn't an unmitigated good by any stretch of the imagination.
Sometimes we really do want to decide that something specific is important
even if no one wants to do it.  And those are probably good places to look
at spending money, so I'm probably being too negative about the idea.  If
we can find other things like LTS where everyone thinks it would be great
if it somehow happened but people are generally not willing to do it for
free, I think those would be compelling places to spend money if we can
sort out the supervision issues.

I'm just quite nervous about breaking down that deep structure of Debian
where we vote with our own time and energy.  It's not perfect and it has
flaws, but we understand it well and it "feels" fair (at least to those of
us who have been in that world for a long time).  I know no one is
proposing this, but a shift towards a model where people pick priorities
for the project and then direct effort to work on those things and not
other things would, for me, start feeling a lot more like a job, and would
hurt my motivation a lot.  I'm not all that productive at the moment, so
that doesn't matter a ton for me personally, but I'd be worried others
would feel the same way.

But what I'm hearing in the thread is that this is probably an avoidable
problem if we're careful to pick and choose the right types of projects.
Janitorial work, as you mention.

(Also, the point is well-taken that "voting with time and energy" is not
particularly "pure" in Debian already, since various corporations vote
with their money to fund people to do various things they care about.  So
this is already complicated and is not a pure volunteer endeavor, to be
sure.  That said, my impression -- on the basis of no actual research, so
maybe it's wrong -- is that Debian is driven much less by corporate
priorities than a lot of large free software projects.  Certainly less
than the Linux kernel, to take an obvious example.)

> My personal experience with real-life self-organizing projects is that
> the hardest part is usually finding volunteers who clean the toilets
> daily.

> There are areas like DSA or security support that are essential, but not
> the "package the cool latest software" kind of work where volunteers are
> easy to find.

Yeah, this is a very good point.

> But this direction of higher-level discussion only makes sense if there
> is a realistic prospect of a reliable long-term money source generating
> at least US$ 1m per year - there are completely different discussions
> depending on whether the additional money available to be spent each
> year would be US$ 0.1m, US$ 1m or US$ 10m.

I very much doubt that our current donation-driven model would generate US
$1M per year on a sustained basis, particularly if you subtract DebConf
out of the mix (which I think we should, because that money is essentially
earmarked for a specific purpose and has a whole sponsorship and
advertising component that works great for the conference but that I doubt
we would be comfortable with in Debian proper).

-- 
Russ Allbery (r...@debian.org)   

Re: Realizing Good Ideas with Debian Money

[Steve McIntyre]

On Sat, Jun 01, 2019 at 12:29:04PM +0200, Tollef Fog Heen wrote:
>]] Russ Allbery 
>
>> These dynamics change a *lot* when the money is coming from
>> the project itself.  That money is special; it's not just one more company
>> or foundation or whatnot that is providing resources to aid in a general
>> volunteer project.  It becomes a loaded statement about what work the
>> project considers the most important and, worse, *who* the project
>> considers important to do that work.
>
>This is a hugely important point: we're already seeing conflicts where
>people conflate the paid-for LTS effort with other team's priorities.
>If we move that funding closer to Debian, we're effectively saying that
>«this funded effort is important and all relevant teams, volunteer or
>not should support it», rather than trusting teams to act in the
>currently more creative anarchic way.  Adding more tension internally in
>the project, which I think spending money in this way will do, is a bad
>idea.

That's definitely my concern, too. I don't want to have to consider
funding when working on stuff for fun, and I also don't really want to
reorganise how things are done to accommodate others who do.

>> Particularly now that my free time is rarer and more precious to me,
>> doing unpaid work for an organization that also has paid staff is
>> hugely demotivating.  It's entirely plausible that paying for
>> resources would mean that Debian would end up with *less* resources
>> than we have now, if other volunteers feel the same way.
>
>Well said, and I feel the same way.

+1

Having said both of these, I think there *are* reasonable places to
spend money that shouldn't affect us so much. The areas in question
are those where we struggle to find any/sufficient volunteer effort to
do what we need - bureaucracy etc. Volunteer book-keepers are few and
far between, IME.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich

Re: Realizing Good Ideas with Debian Money

[Luca Filipozzi]

On Sat, Jun 01, 2019 at 12:29:04PM +0200, Tollef Fog Heen wrote:
> ]] Russ Allbery 
> > Particularly now that my free time is rarer and more precious to me,
> > doing unpaid work for an organization that also has paid staff is
> > hugely demotivating.  It's entirely plausible that paying for
> > resources would mean that Debian would end up with *less* resources
> > than we have now, if other volunteers feel the same way.
> 
> Well said, and I feel the same way.

Same same.

-- 
Luca Filipozzi

Re: Realizing Good Ideas with Debian Money

[Adrian Bunk]

On Sat, Jun 01, 2019 at 09:09:26AM -0400, Sam Hartman wrote:
> > "Adrian" == Adrian Bunk  writes:
> 
> >> 
> >> Talking about the issues involved in paying people to do work.
> >> What the options are, collecting people's concerns etc.
> >> 
> >> I actually think the first round of that can be done without
> >> significant access to numbers.
> >> 
> >> That said, I'd sure like that anual report (actually I'd love it
> >> quarterly) you speak of above.  I'm not volunteering.  Are you?
> 
> Adrian> My biggest high level concern is the income side, since this
> Adrian> is the most difficult part and will likely also be the most
> Adrian> controversial one.
> 
> 
> Ah, I was actually asking if you wanted to volunteer to work on the
> reports since you seemed to value them.  I was only one quarter serious:
> if you did want to do that work, I'd be thrilled, but I didn't really
> expect it.

Ah, seems I misunderstood that.

Yes, I could work on the reports if you tell me how to get access
to the data from the trusted organizations.

>From SPI I get the reports, but for the other I have no clue.

> I think it's actually impossible for a non-profit to reduce income from
> expenses.
> 
> It's a lot easier to do fund raising when you can explain why you want
> the money.
> I think it's no accident that when people learned our sysadmin team no
> longer had hardware donors and  was considering how expensive continuing
> their current strategy was, we got two very large donations, one of them
> intended to make that possible.
> 
> Yeah, unless you want debt (which we almost certainly do not), income
> needs to lead expenses.
> But when people see you spending their money for purposes they believe
> in, it's easier for them to give you more.  When they understand your
> needs they give more.
>...

This works well for one-time investments,
but less so for ongoing expenses like salaries.

It reminds me of NGOs that get drowned in more money than they can spend 
earmarked for a catastrophe that is in the news, but struggle to get 
enough money for running their headquarter.

> --Sam

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Realizing Good Ideas with Debian Money

[Sam Hartman]

> "Adrian" == Adrian Bunk  writes:

>> 
>> Talking about the issues involved in paying people to do work.
>> What the options are, collecting people's concerns etc.
>> 
>> I actually think the first round of that can be done without
>> significant access to numbers.
>> 
>> That said, I'd sure like that anual report (actually I'd love it
>> quarterly) you speak of above.  I'm not volunteering.  Are you?

Adrian> My biggest high level concern is the income side, since this
Adrian> is the most difficult part and will likely also be the most
Adrian> controversial one.


Ah, I was actually asking if you wanted to volunteer to work on the
reports since you seemed to value them.  I was only one quarter serious:
if you did want to do that work, I'd be thrilled, but I didn't really
expect it.


I think it's actually impossible for a non-profit to reduce income from
expenses.

It's a lot easier to do fund raising when you can explain why you want
the money.
I think it's no accident that when people learned our sysadmin team no
longer had hardware donors and  was considering how expensive continuing
their current strategy was, we got two very large donations, one of them
intended to make that possible.

Yeah, unless you want debt (which we almost certainly do not), income
needs to lead expenses.
But when people see you spending their money for purposes they believe
in, it's easier for them to give you more.  When they understand your
needs they give more.

I don't donate to Debian.  (I do sort of donate to SPI, but I'm
considering stopping).  In both cases I value the organizations a lot,
but I don't actually think they need my money.  Both organizations seem
to have funds adequate to meet their own expenses.  So why should I give
them my money?

--Sam

Re: Realizing Good Ideas with Debian Money

[Sam Hartman]

> "Ondřej" == Ondřej Surý  writes:

Ondřej>It might be worth looking on how other organizations in
Ondřej> our ballpark are doing stuff.  f.e. IETF/ISOC is in similar
Ondřej> situation to Debian/SPI.

I'm no longer really involved in the IETF, but I was involved in the
IETF for a number of years and was involved in a leadership role when
the previous structure was set up.  (They are going through a transition
to replace the IASA with the IETF LLC right now, and I don't even
understand why they think that's a good idea; haven't even read the RFCs
involved)

ISOC was careful not to fund any standards work.  So under that model
mapped to us, DPL, RT, all the decisions of ftpmaster, TC, NM, DAM, 
debian-legal, Debconf
content team, and all the
packaging effort would be unfunded.

There was an administrative director who worked on contracts, RFPs, and
who managed relationships.  Then a lot of tasks were contracted.  There
were some fairly long-term contracts for rfc-editor and for the
secretariat (who did debconf local/global team stuff, who ran the
non-RFC parts of the archive (id repository) (other than content
decisions), and helped with administration for bi-weekly document calls
etc).


Then there were contracts for things like tools development.  So things
like DSA, dak development, development of release team scripts would be
contracted out for big projects.  Smaller things and ongoing maintenance
would be handled by volunteers.  Deciding what was wanted, writing
requirements specs, etc, etc would be done by volunteers.


With regard to Russ's concerns,
I think that making short-term grants to work on specific projects might
be much more achievable for us than salaries.  It reduces the factors
he's worried about.
I think there would still be significant risk, but not nearly as much as
if we were actually paying salaries on an ongoing basis.


Factoring in past performance would be easier for new grants than trying
to fire someone.

But I think even given that the concerns would be very real.

That said, even in the IETF community there is very much an in croud for
the administrative stuff.  The same people seem to often be getting the
contracts.  If you actually cared about the business it seems like it
would be very easy to get feelings hurt.

Also, basically all the tasks the IETF pays for are very far from the
actual work of the IETF.

I actually think that Debian could possibly hire  people to do our website on a
contract without it being a huge problem.  We'd explicitly want  the www
team (or hopefully no one in our community) not to bid.  We'd want the
www team to be guiding the process and for the contract to be about
doing the things they don't want to or never get around to doing.
We'd want it to be something we'd be willing to do again in similar
circumstances, so that if it did actually change what people were
willing to work on that would be OK.
In that model, the www team would be more about deciding overall
structure, making the decisions than actually going and implementing
them.


But for a lot of what we do, it's close enough to our core that the mix
of money and power would be problematic.
As an example, even having people work on the dak software seems like it
would run into trouble as they could influence which features got
implemented etc.

When you start funding positions that actually have power to make
project-level decisions, I think you run into a lot of challenges.

--Sam

Re: Realizing Good Ideas with Debian Money

[Tollef Fog Heen]

]] Russ Allbery 

> These dynamics change a *lot* when the money is coming from
> the project itself.  That money is special; it's not just one more company
> or foundation or whatnot that is providing resources to aid in a general
> volunteer project.  It becomes a loaded statement about what work the
> project considers the most important and, worse, *who* the project
> considers important to do that work.

This is a hugely important point: we're already seeing conflicts where
people conflate the paid-for LTS effort with other team's priorities.
If we move that funding closer to Debian, we're effectively saying that
«this funded effort is important and all relevant teams, volunteer or
not should support it», rather than trusting teams to act in the
currently more creative anarchic way.  Adding more tension internally in
the project, which I think spending money in this way will do, is a bad
idea.

> Particularly now that my free time is rarer and more precious to me,
> doing unpaid work for an organization that also has paid staff is
> hugely demotivating.  It's entirely plausible that paying for
> resources would mean that Debian would end up with *less* resources
> than we have now, if other volunteers feel the same way.

Well said, and I feel the same way.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: Realizing Good Ideas with Debian Money

[Judit Foglszinger]

> But yes, it's entirely possible that I'm being too cautious.

I'd say, being cautious in this case is very warranted.

One of the things, that are good about Debian is, that it's _not_ cooperate.
"You will not work for free for a company.  Debian is not a company."

Throwing in money has a high risk of changing culture in a bad way -
work is no longer volunteer work, one has an obligation to do it,
no matter, if one can do it well or even is interested in it any longer.
One got paid and one has to fulfill.

Even too high requirements for bursaries can be destructive -
prove that you are worth this money, promise things
and show that you didn't waste that "money spent on your trip/your 
accommodation".

> There are areas like DSA or security support that are essential, but
> not the "package the cool latest software" kind of work where volunteers
> are easy to find.

> ... continuous tasks to keep the project 
> runnning, like DPL or system administration.

Money seems to be regarded far to much as the ultimate all problem solver.

Not finding volunteers for certain tasks might also be a sign,
that something is screwed up about that task that should be changed.

Long ago, someone suggested to pay AMs, because it was so hard to find such.
From todays prespective it reads quite amusing ;)

> ...  So why not pay for it? 
> So long as the reviewer is respected enough to make a good judgment,
> it shouldn't be impossible to coordinate some direct compensation to
> ease the pain if the task is commonly-agreed to be painful.  People
> pay a fee to take most certifying exams for example.
>
> I wonder if the same could be applied to Debian?
> ...
> What if we
> make an AM salary-pool (open for donations all the time) and pay out
> once a month say 10% of the total pool in proportion to the number of
> people "checked"?

https://lists.debian.org/debian-newmaint/2006/04/msg00168.html

Re: Realizing Good Ideas with Debian Money

[Adrian Bunk]

On Fri, May 31, 2019 at 11:46:02PM -0600, Eldon Koyle wrote:
> On Fri, May 31, 2019 at 5:08 PM Russ Allbery  wrote:
> >
> > Adrian Bunk  writes:
> >
> > > My biggest high level concern is the income side, since this is the most
> > > difficult part and will likely also be the most controversial one.
> >
> > I could well be entirely wrong, but the part that I would expect to be the
> > most controversial is that, once Debian starts spending project money to
> > pay people to do work that other people in the project are doing for free,
> > the project is doing a form of picking winners and losers.  We're deciding
> > as a project that some people's work is valuable enough to pay for and (by
> > omission if nothing else) other people's work is not, and for all the good
> > intentions that we have going in, there are so many ways for this to go
> > poorly.
> 
> I think this is a very real concern.  What if payment was structured as task
> bounties rather than hiring full-time employees? Then the payment becomes
> an acknowledgement that a task is undesirable or time consuming, rather
> than a status symbol.

Bounties can be useful for developing features.

Bounties are not really useful for continuous tasks to keep the project 
runnning, like DPL or system administration.

> Eldon Koyle

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Realizing Good Ideas with Debian Money

[Adrian Bunk]

On Fri, May 31, 2019 at 04:07:54PM -0700, Russ Allbery wrote:
> Adrian Bunk  writes:
> 
> > My biggest high level concern is the income side, since this is the most
> > difficult part and will likely also be the most controversial one.
> 
> I could well be entirely wrong, but the part that I would expect to be the
> most controversial is that, once Debian starts spending project money to
> pay people to do work that other people in the project are doing for free,
> the project is doing a form of picking winners and losers.

Perhaps I am wrong on that, but I am associating the term "picking 
winners and losers" as an ideological statement used by US Republicans 
and Libertarians. For most people outside the US the underlying 
"government is bad" philosophy doesn't make any sense.

> We're deciding
> as a project that some people's work is valuable enough to pay for and (by
> omission if nothing else) other people's work is not, and for all the good
> intentions that we have going in, there are so many ways for this to go
> poorly.

I would say "work most people would never do unpaid".

My personal experience with real-life self-organizing projects is that
the hardest part is usually finding volunteers who clean the toilets
daily.

There are areas like DSA or security support that are essential, but
not the "package the cool latest software" kind of work where volunteers
are easy to find.

>...
> I assume the above is the sort of thing that Sam is referring to when he
> says that we need to have a higher-level discussion if we're going to
> pursue this idea.

One higher level topic is the point from my first email that the overall 
handling of money in the project should be balanced and many of the
problems are mitigated if additional money is not spent only on salaries.

"Debian pays much for A but they want me to pay for B out of my
own pocket" can be a problem - I wouldn't pay travel costs for
Debian events out of my own pocket as long as Debian is spending
money for the salaries of Outreachy interns since it would feel
as if I were financing these salaries by paying for the travel
costs myself.

If being a DD automatically comes with the benefit of travel costs
to a DebConf or MiniDebConf always being paid by Debian, then there
would likely be a higher acceptance for salaries being paid.

If salaries are being paid, then there should also be a proper budget 
reserved for people organizing events like a MiniDebConf so that they
don't have to spend much time finding sponsors.

But this direction of higher-level discussion only makes sense if there 
is a realistic prospect of a reliable long-term money source generating
at least US$ 1m per year - there are completely different discussions
depending on whether the additional money available to be spent each 
year would be US$ 0.1m, US$ 1m or US$ 10m.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Realizing Good Ideas with Debian Money

[Ondřej Surý]

Again I would suggest looking at https://tools.ietf.org/html/rfc4071 as a start 
to learn from the experience of others.

It’s a change in paradigm, but somehow I feel that this is needed if we want to 
keep up to par with other parties in the same field.

P.S.: At no point of time I am speaking about packaging work paid by Debian, 
but there are other functions that would benefit from having staff on full time 
dedicated to that function and being accountable to the Debian project and not 
to their employers.

Cheers,
Ondrej
--
Ondřej Surý 

> On 1 Jun 2019, at 06:12, Russ Allbery  wrote:
> 
> Ximin Luo  writes:
> 
>> Nobody is suggesting that it won't be a hard problem to get right, but
>> progress isn't made by worrying about all the things that could possibly
>> go wrong.  Figuring out a blueprint for organising large-scale work
>> using more directly-democratic principles would have lots of benefits
>> far beyond this project.
> 
> Yup, this is fair, and I admit that I tend to see the problems more
> readily than the opportunities.
> 
> My core point is that I personally don't believe this is the right
> experiment for us.  I don't think Debian is the right organization to try
> this.  I don't think we have the expertise and the muscle in the right
> places to be the project to lead in this specific area.
> 
> However, this is just my opinion, and I don't want to try to persaude you
> too strongly, because if you're right and I'm wrong and we can make this
> work, it would be a very neat positive development.  Funding free software
> development is an enormous problem right now that desperately needs
> options other than controlling sponsorship by for-profit companies with
> all the baggage that carries.
> 
>> Then some of the other things you mentioned are not necessarily
>> downsides. Making a loaded statement about what work the project
>> considers the most important isn't necessarily a bad thing, especially
>> if it stands against the loaded statements that Big Tech already puts
>> out worldwide, that give engineers (including open source engineers) a
>> bad name in front of people that don't know there are less monopolistic
>> ways of creating and using technology.
> 
> I think I'm coming from a place where I feel like our community is still
> rather fragile, and I'm worried about putting more stress on it by making
> those sorts of loaded statements.  But yes, it's entirely possible that
> I'm being too cautious.
> 
> I will say this: we only have the energy to make a small number of big
> bets like this.  If we work on funding development, we're *not* going to
> work on most, if not all, of the other big bet ideas that the project
> could work on.
> 
> Now, that's possibly better than not working on *any* big bets, and we do
> have a tendency to default into not changing anything, and that isn't
> going to serve us well in the long run.  I'm in favor of picking something
> big and going for it.  But I think we should pick one or two big things,
> no more, and try those things until they reach some agreed-upon conclusion
> before adding more on.
> 
> -- 
> Russ Allbery (r...@debian.org)   
> 

Re: Realizing Good Ideas with Debian Money

[Philipp Kern]

On 5/31/2019 11:04 PM, Luca Filipozzi wrote:
> Before you ask: an insecure hypervisor is an insecure buildd.

Are we then looking more closely at AMD-based machines given that those
had less problems around speculative attacks?

Kind regards
Philipp Kern

Re: Realizing Good Ideas with Debian Money

[Ondřej Surý]

It might be worth looking on how other organizations in our ballpark are doing 
stuff.

f.e. IETF/ISOC is in similar situation to Debian/SPI. I am not directly 
involved in looking into IETF financials, but they have contracts for certain 
functions (Ops, RFC Editor to name few, for full list see 
https://iaoc.ietf.org/contracts.html).

I agree that crunching the numbers must be a first step, then next step might 
be identifying roles within the project that can have clear job descriptions, 
that might also include roles that we currently don’t have because it can’t be 
filled by volunteers work. Then this must also include balancing whether we can 
improve the function if the function is contracted and there are “hard” 
requirements.

Personally, I don’t have any problem with paying people with Debian money if 
the competition for the function is transparent (thus done by third party in 
our case), time-limited and clearly specified so we can end the contract if the 
conditions are not fulfilled by the other party.

Ondrej
--
Ondřej Surý 

> On 1 Jun 2019, at 01:07, Russ Allbery  wrote:
> 
> Adrian Bunk  writes:
> 
>> My biggest high level concern is the income side, since this is the most
>> difficult part and will likely also be the most controversial one.
> 
> I could well be entirely wrong, but the part that I would expect to be the
> most controversial is that, once Debian starts spending project money to
> pay people to do work that other people in the project are doing for free,
> the project is doing a form of picking winners and losers.  We're deciding
> as a project that some people's work is valuable enough to pay for and (by
> omission if nothing else) other people's work is not, and for all the good
> intentions that we have going in, there are so many ways for this to go
> poorly.
> 
> If we're only hiring people from *outside* the project, not each other,
> maybe that avoids the worst of the problems, but it's still an odd
> dynamic.  For example, it creates a perverse incentive for someone to
> resign from the project so that they can be paid for the work they're
> currently doing as a volunteer.
> 
> I'm particularly concerned what will happen if something goes wrong: we
> pay someone to do additional work and that work isn't up to the quality
> standards that we need.  Now what?  If that person is also a Debian
> Developer, we have now introduced an aspect of job performance feedback
> into a volunteer community.  While doubtless there are Debian Developers
> who are also managers in their day jobs, that's not something anyone is
> currently doing *in Debian*.  Managing feedback and consequences for poor
> performance is a skill that we are not currently exercising and that is
> not trivial to learn.
> 
> These problems generally go away with externally-funded initiatives such
> as LTS.  In that case, even when Debian Developers are involved, it's
> clear that the person with the money is making contract and hiring
> decisions, is the person who can decide to fire someone from that contract
> if they don't like the work being done, and any decisions made there are
> entirely separate from one's ongoing Debian work as a volunteer.  People
> still have to decide what they're willing to do for free and what they
> want to be paid for, but it helps a lot that LTS is scoped to one specific
> problem and has resources such that, if everyone else decides they're not
> willing to do LTS support for free, the initiative still survives.  It
> also helps considerably that LTS was something we as a project had decided
> not to do with pure volunteer resources, so it's a pure incremental on top
> of project work.
> 
> Maybe we can find more things like LTS that are pure incrementals over
> what the project is currently doing, but I'm pretty worried about the
> social dynamic of paying people to do core project work that others are
> currently doing for free.
> 
> I assume the above is the sort of thing that Sam is referring to when he
> says that we need to have a higher-level discussion if we're going to
> pursue this idea.
> 
> -- 
> Russ Allbery (r...@debian.org)   
>