public inbox for overseers@sourceware.org
 help / color / mirror / Atom feed
From: "Bradley M. Kuhn" <bkuhn@sfconservancy.org>
To: <overseers@sourceware.org>
Subject: Re: BBB instances
Date: Wed, 21 Sep 2022 12:47:51 -0700	[thread overview]
Message-ID: <87bkr8jyqg.fsf@ebb.org> (raw)
In-Reply-To: <87wn9xv1p7.fsf@fsf.org> (Ian Kelling via Overseers's message of "Tue, 20 Sep 2022 23:23:52 -0400")

Starting my response to Elena's inquiry with a bit of background:

One of the reasons for SFC's interest in helping Sourceware (and among the
reasons why our Evaluation Committee offered Sourceware project membership
at SFC) is that SFC has become increasingly concerned in the last few years
at how many FOSS projects (even some of our own member projects) are using
proprietary infrastructure to develop FOSS.  We at SFC see proprietary
infrastructure for FOSS development as one of the biggest threats to
software freedom.

As such, we at SFC were thrilled to see how much effort the Sourceware
Overseers have put into FOSS-only infrastructure.  We discussed it with them
as part of their application their commitment to FOSS-only infrastructure.

It fit well with our approach to this problem: we don't want to insist FOSS
projects already using proprietary software give it up overnight, but in an
effort to coax those projects to give it up, we want to offer reliable,
viable FOSS alternatives for project hosting.  We also believe a diversity
of offerings is ideal (to ward of the tendency toward monoculture that
companies like GitHub rely on to entice adoption).

We at SFC have been working on this on a number of fronts for about two
years — it's a hard problem to solve because the amount of proprietary
infrastructure that FOSS developers now use keeps growing.  We're excited at
the opportunity to partner with Sourceware as another, parallel approach.

Now, with regard to video chat, we have indeed been looking closely at BBB:

Elena Zannoni via Overseers wrote at 13:41 (PDT) on Tuesday:
>> one of the things that was discussed at Cauldron was that it would be good
>> to have BBB easily available for community meetings etc.  … If [we] could
>> just jump onto a BBB room on sourceware it would be a cool thing to have.

>> Any thoughts on doing something like that?

At the beginning to the pandemic, with help of a dedicated volunteer, SFC
was able to get an instance of BBB up and running, hosted on OSU-OSL's
infrastructure.  Many of our member projects are already using it for their
team meetings (switching away from tools like Zoom and Google Meet that they
had previously been using).  We're also using it for all our SFC's video
conferencing needs, and many of you attended our chat sessions about the
Sourceware application.

Our initial findings confirmed the (obvious) hypothesis: scaling is
extremely difficult for video chat.  Right now, we've tested a few
(simultaneous) meetings with 5-10 people and our existing infrastructure can
handle it.  We're currently talking with grant makers and partners about how
we can increase capacity.

Our current assessment is that it's unlikely that we can offer BBB services
to the entire FOSS-developing *public* any time soon.  However, if
Sourceware joins SFC, this is a great opportunity to expand slowly, which is
definitely possible.  We at SFC generally would like to do that, and it fits
with the types of grants and work we're already seeking to improve in our
effort to build “FOSS infrastructure for FOSS projects”.

We also think Sourceware makes an excellent partner to begin working on this
for the reasons I mentioned above and others.

But, it will likely take time (and a little bit of funding) to make this
happen for Sourceware once they join SFC.  Nevertheless, I think SFC is the
best partner for this; we have seen that most other fiscal sponsors simply
use proprietary video chat for their projects, or don't have offering video
chat as part of their plans for infrastructure.  By partnering with
Sourceware, our feeling is that we can expand offering beyond just SFC
projects (i.e., to the guest projects at Sourceware that are *not* SFC
projects themselves) in a manner that allows for time to scale and test.

(If we could do magic, SFC would offer BBB services to every FOSS project in
 the world (whether they were an SFC member or not) tomorrow to get them all
 off Zoom, etc., but, absent magic, offering that without slowly scaling up
 is a recipe for crashed servers and unhappy users.)

Ian Kelling via Overseers wrote at 20:23 (PDT) on Tuesday:
> About BBB, It currently includes MongoDB in it's [sic] server software,
> which went nonfree a few years ago. You can still run an older version
> which is all free software

Indeed, SFC's instance currently does this.  We published our methodology on
how to do it as well.  It's important to note that the main database that
BBB uses is Postgres, and MongoDB is only used for runtime session data.

> However, right now, I wouldn't deploy a new instance of BBB.

Frankly, I think this is an alarmist response.  I don't believe the problem
is urgent, given the limited use of MongoDB by BBB, but if the problem were
to become urgent …

> and BBB upstream is looking at ways to switch to a free database.

… surely this work could be funded?  SFC's plan was that if the problem
became a priority [0], we'd rapidly fund the upstream work necessary to
reduce dependency on MongoDB.

But, it looks like you've in parallel put some effort on this with upstream,
Ian.  Can you post a link to a to BBB mailing list thread or bug ticket on
the matter?

Meanwhile, I noticed the FSF has also done various public-facing events on
your BBB instance … Ian, can you brief us on the FSF's current plans to
handle the MongoDB problem?  Are you looking to abandon BBB entirely, as you
hint above?  If not, what's FSF's contingency plan?

 * * *
 
As a side note, in an unrelated effort that we pursued at SFC, we did spend
substantial effort looking into the viability of maintaining a fork of
MongoDB under AGPLv3 after the SS Public License change.  We decided such a
project wasn't worth the effort. (Curious to know if any other organizations
did the same, and if you came to the same conclusion?)

Specifically, I led that investigation at SFC and determined that a MongoDB
AGPLv3 fork was unlikely to succeed.  One reason is there are a lot of other
FOSS options for NoSQL databases.  While MongoDB, Inc. has a tendency to act
as if their solution is amazingly unique, in practice, it seemed that the
popularity of MongoDB over alternatives seemed to have more to do with their
marketing than their technological superiority.  However, I'm not a NoSQL DB
expert (I relied on interviews that I had with those who were), so if anyone
came a different conclusion on this, I'd be glad to discuss it.

So, that work, which predated my and SFC's interest in BBB, did inform my
conclusion about BBB's MongoDB dependency.  However, I'm always open to
revisit that work, and am very grateful that folks in the Sourceware
community really care about the issues of “Is this solution for development
infrastructure really FOSS, and how do we make sure it *stays* FOSS?” — so
I'm thrilled to be having this conversation with you all!

> For simple web based video conference, I'd look at Jitsi Meet.

FWIW, I also worked with an SFC volunteer on a test instance of Jitsi Meet.
We found it to be more resource intensive than BBB.  While Jitsi Meet's UI
is much better for impromptu meetings and chats than BBB, ultimately we've
been reluctant to deploy a community-facing Jitsi Meet instance for fear
we'd face resource constraints worse than we face with BBB.  However,
FOSDEM's use of Jitsi Meet integrated with Matrix to run their event was
intriguing, and we have it on our long-term list to work with the FOSDEM
organizers on how they pulled that off and if it would be possible to set up
a Matrix/Jitsi Meet combo instance in the manner they used for breakout
rooms at FOSDEM.

Generally speaking, I think we shouldn't be avoiding any FOSS alternative in
the space of software development infrastructure.  Video chat is just one of
many collaboration tools that FOSS projects now often need where the
“default option” is proprietary software.

[0] The only ways I see the MongoDB issue becoming urgent is if there is a
    major security problem/bug with the last AGPLv3'd version where no patch
    is available, or if BBB drifts in its usage such that it relies on new
    features that only newer MongoDB versions support.  Am I missing
    something?
-- 
Bradley M. Kuhn - he/him
Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy
========================================================================
Become a Conservancy Sustainer today: https://sfconservancy.org/sustainer

  reply	other threads:[~2022-09-21 19:48 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-20 20:41 Elena Zannoni
2022-09-21  3:23 ` Ian Kelling
2022-09-21 19:47   ` Bradley M. Kuhn [this message]
2022-09-22 19:27     ` Elena Zannoni
2022-09-22 22:23       ` Denver Gingerich
2022-09-23  0:03     ` Ian Kelling
2022-09-25 23:04 ` Mark Wielaard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87bkr8jyqg.fsf@ebb.org \
    --to=bkuhn@sfconservancy.org \
    --cc=overseers@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).