I only really work with downstream projects, I did work on BST prior to
it becoming ASF and through some of the transition. So might be able to
clear some things up. But some one like Sander might be a more
authoritative source.
TLDR;
Sam makes it clear that Buildstream and its down streams are different
projects. But there are multiple long term homes for the plugins.
Plugins can live in ASF buildstream its self or in the ASF plugins repo
but they can also be part of the downstream projects or in 3rd party repos.
Plugins are often developed where ever is easiest to start with and then
move to a long term home but for different plugins that long term home
is not always the same.
Some of the good long term homes for plugins are inside ASF and are in
github.com/apache and some are not in ASF and thus are in different git
forges and/or name spaces.
On 04/09/2026 22:33, Dom Rodriguez via dev wrote:
Hi Rich,
On 04.09.2026 14:32, Rich Bowen wrote:
On Sep 4, 2026, at 1:35 PM, Dom Rodriguez via dev
<[email protected]> wrote:
Hi Rich,
On 04.09.2026 11:57, Rich Bowen wrote:
Oh, also, in the interview Sam mentioned a community plugins space,
but I can’t find any mention of that on your website, or in the git
repos. Can you point me to that? That seems like an important
community entry point.
I'm not sure what definition of 'space' we're talking about. Do you
mean like a Matrix 'Space', or the community namespace for BuildStream
'things'...?
Buildstream is a tool, but it is extensible by plugins and is used to
build projects.
I would call this the Buildstream Eco system, Buildstream the tool is a
ASF project, there is also a ASF plugins repo which I think falls under
the same ASF project, I dont understand how ASF organises its self.
When Sam talks about a "plugins space" I think he's talking about how
the plugins fit into the picture. IE they have to work in Buildstream
but they are often developed by downstream communities to fill the
downstream needs.
There are both ASF project plugin repos and non ASF plugin repos.
Then there are the downstream projects that use bst, Non of which are
currently ASF affiliated (AFAICT).
See https://buildstream.apache.org/ "Who is using buildstream" for
prominent public users.
The "plugin space" is a area were the users and the developers of bst
overlap. Some times there has been creative tension, some times
collective innovation. Plugins can live in Bst as core plugins, in there
own repos, or as part of the down stream projects themselves.
Quite a lot of work has gone in over the years to improve how bst
handles its plugins.
I’m not sure what I mean. Sam said that users can contribute plugins
that go … somewhere … before they are considered for acceptance into
the actual “official” plugins directory. Is that a misunderstanding?
Depending on the plugin the best place for it to live long term might be:
* Core bst plugin
https://github.com/apache/buildstream/tree/master/src/buildstream/plugins
* "Apache" plugins repo https://github.com/apache/buildstream-plugins
* "Community" plugins repo
https://gitlab.com/BuildStream/buildstream-plugins-community
* Others can setup there own plugin repos, in the public or private if
they wish.
* In downstream projects, some public examples:
* FreeDesktop-SDK,
https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/tree/master/plugins
* Gnome-build-meta,
https://gitlab.gnome.org/GNOME/gnome-build-meta/-/tree/master/plugins
But they might start there life in a different one. Eg if a project
needs a new plugin it might start in that project and then if some one
else thinks its useful for them too they might move it to one of the
shared repos. (This might need re licensing etc so can take a bit of
effort, eg "cargo2". Different down streams (Non of which are ASF) might
find it easier add them to a non ASF plugin repos if they share common
license)
One thing that is less clear from Sam's talk is that its Bst Core is not
the best place for all plugins. I can talk about this for ages, but the
TLDR is core is very stable and so has a minimal set of plugins. The ASF
plugins repo might be a good long term home for a lot of plugins but the
longer running buildstream-plugins-community might also be a good long
term home.
Note that the different locations also come with different stability rules.
Note that https://gitlab.com/BuildStream/buildstream-plugins-community
pre dates the core BST repo move to apache and the creation of the
apache plugins repo.
Freedesktop-sdk, which Sam mentions, is one of the biggest projects
using Buildstream in the public. It uses plugins from Core bst, "Apache"
plugins repo, "Community" plugins repo and has its own plugins internal
to the repo.
Yes, so that's
https://gitlab.com/BuildStream/buildstream-plugins-community, which is
what Sam was referring to, I believe.
If its the latter, I can direct you to https://gitlab.com/BuildStream -
you'll find a bunch of community-maintained and related projects to
BuildStream there. `buildstream-sbom` is worth checking out.
So … you’re using Gitlab as well as Github? That’s new info to me. Can
you tell me more? This strikes me as somewhat outside of ASF policy,
but I could be misunderstanding what’s going on here.
Im not a ASF person but to the best of my knowledge:
The Core buildstream repo is Fully Apache and that project has its own
plugins repo which is also Fully Apache. This project also maintains the
buildstream website, mailing list etc in conjunction with ASF its self.
But the existing communities in https://gitlab.com/BuildStream/ pre-date
the move of the "core project" to Apache.
The buildstream Eco system contains at least:
* ASF buildstream
* Various plug-in communities
* Including a ASF one
* Including others which are not ASF affiliated eg
https://gitlab.com/BuildStream/buildstream-plugins-community,
* Many Open and closed Downstream projects, Non of which are currently
ADF affiliated (AFAICT).
see https://buildstream.apache.org/ "Who is using buildstream" for
prominent public users.
