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ý <ond...@sury.org> > On 1 Jun 2019, at 06:12, Russ Allbery <r...@debian.org> wrote: > > Ximin Luo <infini...@debian.org> 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) <http://www.eyrie.org/~eagle/> >
