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
>>

Reply via email to