FOSDEM devroom proposal "Agentic Automation for OSS Maintainers" submitted

[Jarek Potiuk <ja...@potiuk.com>]

Hello everyone,

I have just submitted a proposal for a FOSDEM devroom (30-31 Jan 2027 in
Brussels).

https://fosdem.org/2027/news/call-for-devrooms/

If anyone would like to join me as co-organizer - reach out to me please.
It's fun

J.


--------
Agentic Automation for OSS Maintainers

Something broke in the last two years, and every maintainer felt it before
they could name it. Generating a contribution became nearly free; reviewing
one did not. The result is an inbox "tax" paid in the only currency
maintainers actually have — attention and time.

We get AI-written PRs that compile and mean nothing, CVE reports that
hallucinate a call path, and issue threads where nobody involved has read
the code. Meanwhile the maintainers holding up half the dependency tree are
still doing release management by hand, in the evening, for free.

What unites us is the belief that the answer is not "keep the robots out" —
that ship has sailed and it was never ours. The answer is to put the agents
on our side of the table. Not agents that write features nobody asked for,
but agents that carry the boring, exact, institutional knowledge a project
accumulates over a decade: how a release is cut, which vendored dependency
is important to look at, why that test is flaky on ARM, what a real
security report looks like versus a plausible one.

At the ASF this is turning into concrete work — release automation,
supply-chain scanning across org repositories after Shai-Hulud. Apache
Magpie, an agentic maintainer-tooling platform grown out of Airflow's
Breeze, built around SKILLs: executable institutional memory, reviewable in
a PR, versioned in git, running under governance rather than under a
vendor's API key.

That last part matters. Bus factor one is a knowledge problem, not a
headcount problem, and knowledge that lives only in one maintainer's head
is not open source in any meaningful sense. This devroom is for the people
building the tooling, the people arguing about whether we should, and the
foundations trying to make it survive the maintainer who wrote it. We want
war stories, working code, and dissent — especially dissent. Come with
something running.

Relevant URLs:

https://github.com/potiuk
https://github.com/apache/magpie/
https://magpie.apache.org/
https://airflow.apache.org/
https://www.apache.org/

Special requirements: None

------

Re: FOSDEM devroom proposal "Agentic Automation for OSS Maintainers" submitted

[Matt Topol <zo...@gmail.com>]

Invite accepted! :) looking forward to working with you again, hopefully if
they accept the proposal

On Wed, Sep 9, 2026, 3:22 PM Jarek Potiuk <ja...@potiuk.com> wrote:

> Invite sent Matt :D
>
> On Wed, Sep 9, 2026 at 3:10 PM Matt Topol <zo...@gmail.com> wrote:
>
> > I'm in for Co-organizing!
> >
> > On Wed, Sep 9, 2026, 3:02 PM Jarek Potiuk <ja...@potiuk.com> wrote:
> >
> > > Hello everyone,
> > >
> > > I have just submitted a proposal for a FOSDEM devroom (30-31 Jan 2027
> in
> > > Brussels).
> > >
> > > https://fosdem.org/2027/news/call-for-devrooms/
> > >
> > > If anyone would like to join me as co-organizer - reach out to me
> please.
> > > It's fun
> > >
> > > J.
> > >
> > >
> > > --------
> > > Agentic Automation for OSS Maintainers
> > >
> > > Something broke in the last two years, and every maintainer felt it
> > before
> > > they could name it. Generating a contribution became nearly free;
> > reviewing
> > > one did not. The result is an inbox "tax" paid in the only currency
> > > maintainers actually have — attention and time.
> > >
> > > We get AI-written PRs that compile and mean nothing, CVE reports that
> > > hallucinate a call path, and issue threads where nobody involved has
> read
> > > the code. Meanwhile the maintainers holding up half the dependency tree
> > are
> > > still doing release management by hand, in the evening, for free.
> > >
> > > What unites us is the belief that the answer is not "keep the robots
> > out" —
> > > that ship has sailed and it was never ours. The answer is to put the
> > agents
> > > on our side of the table. Not agents that write features nobody asked
> > for,
> > > but agents that carry the boring, exact, institutional knowledge a
> > project
> > > accumulates over a decade: how a release is cut, which vendored
> > dependency
> > > is important to look at, why that test is flaky on ARM, what a real
> > > security report looks like versus a plausible one.
> > >
> > > At the ASF this is turning into concrete work — release automation,
> > > supply-chain scanning across org repositories after Shai-Hulud. Apache
> > > Magpie, an agentic maintainer-tooling platform grown out of Airflow's
> > > Breeze, built around SKILLs: executable institutional memory,
> reviewable
> > in
> > > a PR, versioned in git, running under governance rather than under a
> > > vendor's API key.
> > >
> > > That last part matters. Bus factor one is a knowledge problem, not a
> > > headcount problem, and knowledge that lives only in one maintainer's
> head
> > > is not open source in any meaningful sense. This devroom is for the
> > people
> > > building the tooling, the people arguing about whether we should, and
> the
> > > foundations trying to make it survive the maintainer who wrote it. We
> > want
> > > war stories, working code, and dissent — especially dissent. Come with
> > > something running.
> > >
> > > Relevant URLs:
> > >
> > > https://github.com/potiuk
> > > https://github.com/apache/magpie/
> > > https://magpie.apache.org/
> > > https://airflow.apache.org/
> > > https://www.apache.org/
> > >
> > > Special requirements: None
> > >
> > > ------
> > >
> >
>

Re: FOSDEM devroom proposal "Agentic Automation for OSS Maintainers" submitted

[Jarek Potiuk <ja...@potiuk.com>]

Invite sent Matt :D

On Wed, Sep 9, 2026 at 3:10 PM Matt Topol <zo...@gmail.com> wrote:

> I'm in for Co-organizing!
>
> On Wed, Sep 9, 2026, 3:02 PM Jarek Potiuk <ja...@potiuk.com> wrote:
>
> > Hello everyone,
> >
> > I have just submitted a proposal for a FOSDEM devroom (30-31 Jan 2027 in
> > Brussels).
> >
> > https://fosdem.org/2027/news/call-for-devrooms/
> >
> > If anyone would like to join me as co-organizer - reach out to me please.
> > It's fun
> >
> > J.
> >
> >
> > --------
> > Agentic Automation for OSS Maintainers
> >
> > Something broke in the last two years, and every maintainer felt it
> before
> > they could name it. Generating a contribution became nearly free;
> reviewing
> > one did not. The result is an inbox "tax" paid in the only currency
> > maintainers actually have — attention and time.
> >
> > We get AI-written PRs that compile and mean nothing, CVE reports that
> > hallucinate a call path, and issue threads where nobody involved has read
> > the code. Meanwhile the maintainers holding up half the dependency tree
> are
> > still doing release management by hand, in the evening, for free.
> >
> > What unites us is the belief that the answer is not "keep the robots
> out" —
> > that ship has sailed and it was never ours. The answer is to put the
> agents
> > on our side of the table. Not agents that write features nobody asked
> for,
> > but agents that carry the boring, exact, institutional knowledge a
> project
> > accumulates over a decade: how a release is cut, which vendored
> dependency
> > is important to look at, why that test is flaky on ARM, what a real
> > security report looks like versus a plausible one.
> >
> > At the ASF this is turning into concrete work — release automation,
> > supply-chain scanning across org repositories after Shai-Hulud. Apache
> > Magpie, an agentic maintainer-tooling platform grown out of Airflow's
> > Breeze, built around SKILLs: executable institutional memory, reviewable
> in
> > a PR, versioned in git, running under governance rather than under a
> > vendor's API key.
> >
> > That last part matters. Bus factor one is a knowledge problem, not a
> > headcount problem, and knowledge that lives only in one maintainer's head
> > is not open source in any meaningful sense. This devroom is for the
> people
> > building the tooling, the people arguing about whether we should, and the
> > foundations trying to make it survive the maintainer who wrote it. We
> want
> > war stories, working code, and dissent — especially dissent. Come with
> > something running.
> >
> > Relevant URLs:
> >
> > https://github.com/potiuk
> > https://github.com/apache/magpie/
> > https://magpie.apache.org/
> > https://airflow.apache.org/
> > https://www.apache.org/
> >
> > Special requirements: None
> >
> > ------
> >
>

Re: FOSDEM devroom proposal "Agentic Automation for OSS Maintainers" submitted

[Matt Topol <zo...@gmail.com>]

I'm in for Co-organizing!

On Wed, Sep 9, 2026, 3:02 PM Jarek Potiuk <ja...@potiuk.com> wrote:

> Hello everyone,
>
> I have just submitted a proposal for a FOSDEM devroom (30-31 Jan 2027 in
> Brussels).
>
> https://fosdem.org/2027/news/call-for-devrooms/
>
> If anyone would like to join me as co-organizer - reach out to me please.
> It's fun
>
> J.
>
>
> --------
> Agentic Automation for OSS Maintainers
>
> Something broke in the last two years, and every maintainer felt it before
> they could name it. Generating a contribution became nearly free; reviewing
> one did not. The result is an inbox "tax" paid in the only currency
> maintainers actually have — attention and time.
>
> We get AI-written PRs that compile and mean nothing, CVE reports that
> hallucinate a call path, and issue threads where nobody involved has read
> the code. Meanwhile the maintainers holding up half the dependency tree are
> still doing release management by hand, in the evening, for free.
>
> What unites us is the belief that the answer is not "keep the robots out" —
> that ship has sailed and it was never ours. The answer is to put the agents
> on our side of the table. Not agents that write features nobody asked for,
> but agents that carry the boring, exact, institutional knowledge a project
> accumulates over a decade: how a release is cut, which vendored dependency
> is important to look at, why that test is flaky on ARM, what a real
> security report looks like versus a plausible one.
>
> At the ASF this is turning into concrete work — release automation,
> supply-chain scanning across org repositories after Shai-Hulud. Apache
> Magpie, an agentic maintainer-tooling platform grown out of Airflow's
> Breeze, built around SKILLs: executable institutional memory, reviewable in
> a PR, versioned in git, running under governance rather than under a
> vendor's API key.
>
> That last part matters. Bus factor one is a knowledge problem, not a
> headcount problem, and knowledge that lives only in one maintainer's head
> is not open source in any meaningful sense. This devroom is for the people
> building the tooling, the people arguing about whether we should, and the
> foundations trying to make it survive the maintainer who wrote it. We want
> war stories, working code, and dissent — especially dissent. Come with
> something running.
>
> Relevant URLs:
>
> https://github.com/potiuk
> https://github.com/apache/magpie/
> https://magpie.apache.org/
> https://airflow.apache.org/
> https://www.apache.org/
>
> Special requirements: None
>
> ------
>