I think it's fair, but it would be nice if the current committers could reach a consensus on the way forward: either be willing to help new contributors get up to speed - with the caveats mentioned - or move the project to the Attic, so that interested people can try to maintain/continue its development outside of the ASF. The current state of the project being in limbo is quite sad and prevents any work from being done. These email threads started 3 weeks ago and so far nothing concrete has been done, at least from an outsider point of view.
Cheers, Charles On Tue, 9 Mar 2021, 09:16 Andrei Sekretenko, <asekrete...@gmail.com> wrote: > I think Benjamin Bannier and Benjamin Mahler are right about the > immediate non-technical issues and how the backing of the project > could/could not look like in future. > > I would say that the main root cause of both the non-technical > troubles and the lack of the backing is the issue of the long-term > direction of the project. Infrastructure components are notoriously > prone (maybe much more prone than some other kinds of software) to the > following feedback loop: the larger the installed base, the more > battle-tested and thus stable the project becomes (despite the growing > complexity), the larger the installed base is. > > Under the current circumstances, this, in my view, means that Mesos > has no long-term prospects unless it manages to shift to a > niche/role/direction in which the problems cannot be reasonably solved > by the Kubernetes-style cluster orchestration. > > Should we - despite the current issue of the long-term direction - > find people/entities willing to support the project in future, there > will be a task of experience transfer, regardless of whether Mesos > continues to be an ASF project or not. In the past, the experience > transfer used to occur from persons with a history of contributing to > the project (i.e. committers) to ones contributing (who, under the > Apache paradigm, eventually became new committers). > > The task of experience transfer IMO is only potentially solvable if > there is going to be a _significant_ contribution coming from a _few_ > individuals. Under other circumstances (say, 20 people contributing 2 > small bugfixes each), the efforts of current committers to review that > - even if some of us will be able to do that on a side - are going to > be spread thin and will not lead to getting more people with > significant experience on the project. The latter, in turn, is not a > good motivation to reviewing contribution on a non-paid basis (and > even on a paid basis, especially given that most committers seem to > have a full-time occupation not relevant - or, like me, no longer > really relevant - to working on Mesos). > > Best, > Andrei Sekretenko > > P.S. Sorry folks, in general I hate to fuel self-fulfilling > prophecies, but what I tried to explain above had to be said > explicitly. > > > On Mon, 8 Mar 2021 at 21:41, Benjamin Mahler <bmah...@apache.org> wrote: > > > > I think the key issues have been brought up by Benjamin and Renan. > > > > Just to add to Benjamin's comments above, achieving those key markers of > > a healthy project requires serious corporate backing such that people > are being > > employed to primarily work on Mesos. It takes a lot of work to keep the > project > > running along and if people are doing that on the side or as a hobby it > is going > > to be unsustainable. > > > > In the initial phase of the project, there was a team dedicated to Mesos > at Twitter, > > which is how the system was productionized and core features were > developed. > > The second phase of the project, in which Twitter was largely absent, > was driven > > by Mesosphere (now called D2iQ) along with a few people making sporadic > > contributions. With the shift in D2iQs priorities away from Mesos, the > project is > > now without corporate backing. > > > > Ultimately, I think with a project like Mesos those corporate backers > tend to be > > vendors rather than users, because vendors can justify the investment as > a core > > part of their business whereas users cannot. The vendors in this space > have > > consolidated around kubernetes. > > > > An alternative model to vendor driven development would be to have a > > foundation that allows users to fund development in the project, but > this model > > requires donations which seems prone to persistent underfunding. (Reading > > the wikipedia sections on freebsd and openbsd funding shows examples of > > these alternative models). > > > > So I see two options related to how the project is backed: > > > > - Vendor and user companies are employing engineers to work on Mesos > > because either they have products based on Mesos, or use it heavily. > > > > - Users / Companies / Other bodies donate to a foundation which houses > the > > project and drives the development using these donations / resources. > > > > The current model of Apache + maybe some folks stepping up to help I > > don't think will work. > > > > On Sun, Mar 7, 2021 at 6:39 PM Marc <m...@f1-outsourcing.eu> wrote: > >> > >> > >> * csi slrp unmanaged driver > >> (unless it is possible to work around enabling SYS_ADMIN in > bounding_capabilities for all tasks) > >> * csi serp > >> > >> > >> http://mesos.apache.org/documentation/latest/csi/#limitations > >> https://issues.apache.org/jira/browse/MESOS-8371 > >> >
