FAQs
Welcome
Welcome to the BigBlueButton project's Frequently Asked Questions (FAQ).
We (the core developers) created this FAQ to quickly answer common questions around installation, configuration, and using BigBlueButton. If you are a developer, you'll find lots of answers herein that have been collected from discussions on our mailing lists.
NOTE: For teachers and students, you'll find the Knowledge Base the best resource for how-to articles on using BigBlueButton. Also check out the Tutorial Videos as well.
What if I don't find my answer here
The BigBlueButton community focuses its support in three mailing lists, each hosted by Google Groups. Each group focuses on a different topic of questions:
- bigbluebutton-setup -- Setup, installation, and configuration questions, such as "How do I configure the BigBlueButton client?"
- bigbluebutton-users -- End user questions, such as "How do I do X with BigBlueButton?"
- bigbluebutton-dev -- All other questions, such as "How do I integrate BigBlueButton with my application?"
The developer mailing list has over 4000 users, so before you post:
- Scan this FAQ to see if your question is answered herein.
- Use Google to search for keywords related to your question -- there's a good chance someone might have already asked your question in the Google groups.
- If you think you've found a bug, first check the issues database to check if it's already been reported.
All of the core BigBlueButton contributors subscribe to all three mailing lists. Please don't cross post to more than one list -- you are only causing more effort to answer all the threads.
Why is this project called BigBlueButton
The name came from the goal of making the process to setup a virtual classroom as easy as pressing a (metaphorical) big blue button.
Why is it spelled BigBlueButton (and not Big Blue Button)
The trademark is written as one word BigBlueButton. Doing so makes it easy for others to use Google to search for information about the project.
Where is the source
The BigBlueButton source code is at https://github.com/bigbluebutton/bigbluebutton. As an open source project, you are welcome to fork BigBlueButton and build your own applications upon it.
What is the open source license used in BigBlueButton
We use the LGPL license Version 3.0. Some of the open source components we build on use different licenses, such as red5phone uses the GPL license.
Will BigBlueButton always stay open source
Yes.
We started BigBlueButton as an open source project, and we intend to keep it that way. One of the main goals we had was to create a large open source community around the project. To further this goal, we are in the process of putting together an independent not-for-profit BigBlueButton organization (similar to the Eclipse Foundation) to oversee and accelerate the growth of the BigBlueButton project.
I tried to join one of the mailing lists and got rejected
To avoid SPAM in our mailing lists, when you apply to join you are prompted to ask a simple question. If we get an application without an answer, we assume the application is from a bot and delete it.
Be sure to provide us an answer so we know your a real person that wants to join our community.
BigBlueButton Development Process
There is a very active BigBlueButton community of members on the developer mailing list (over 2000 members and counting!). In the BigBlueButton community at-large all the members, users, developers, educational institutions, and commercial companies are all collaborating on using and improving BigBlueButton.
As with any open source project, the continued growth of the community depends on the quality of the software. The quality of the software, in turn, depends on the developers involved and the process we use to build a release.
Development Priorities
The core group of BigBlueButton committers have adopted an open source development process with the following priorities (in order):
- Stability
- Usability
- Features
- Modularity
- Scalability
It cannot be overstated that the project's focus is primarily on stability. For a university or college to deploy BigBlueButton for live classes, or for a commercial company to embed BigBlueButton into their product, the software must be extremely stable. To that end, you'll notice from the previous release notes that we tend to spend months testing each release candidate before issuing a release.
Achieving stability is no easy task. BigBlueButton itself is built upon many great open source projects (such as FreeSWITCH, redis, Akka, and others) with sub-systems responsible for sharing of slides, video, audio, text, and desktop sharing. The stability of the product today is a direct result of the committers, the development process, and the community all working together. We release on quality, not dates.
Usability ranks a close second. Without a simple-to-use (we like to call it elegant) user interface, BigBlueButton would neither be adopted, nor viewed as a compelling alternative to more complex (and proprietary) equivalents.
Features are the focus of each release, and we focus on the features that our core market (on-line learning) will benefit from most.
Modularity enables components of BigBlueButton to be developed, refactored, and upgraded in parallel. During each release we invariably rewrite parts of BigBlueButton to improve modularity. Much of this is invisible to end-users, but it keeps the technical debt low, so we can innovate faster with each release.
Scalability is important as our market grows. We designed BigBlueButton to be a highly collaborative system.
BigBlueButton Committer
Like many open source projects, at the core of the project are a team of developers that have responsibility for core development and overall quality of the project. The current committers are as follows:
Committers:
- Richard Alam, lead architect
- Felipe Cecagno, core
- Fred Dixon, project manager
- Jesus Federico, integrations
- Anton Georgiev, HTML5 client
- Tiago Jacobs, core
- Paulo Lanzarin, audio/video
- Pedro Marin, client
- Ghazi Triki, core
- Calvin Walton, record and playback
Past Committers (fondly remembered):
- Oswaldo Acauan, HTML5 client
- Marco Calderon, server
- Chad Pilkey, HTML5 client
- Gustavo Salazar, record and playback
- Jeremy Thomerson, API
- Denis Zgonjanin, client
The committers have earned this responsibility through years of contribution to BigBlueButton and to related open source projects (i.e. red5). In particular, we very much respect Richard's seven year-plus effort to create BigBlueButton. As the Lead Architect for our project, he has the final say.
The committers are very active in the support and mentoring of other developers in the bigbluebutton-dev mailing list. The BigBlueButton project also participated in the 2010 Google Summer of Code (Google paid for two students to work on the project).
The committers group is not closed. Any developer that wishes to become a committer can achieve it through participation. The decision of expanding the committers group rests with the committers.
Process
Each release cycle goes according to the following steps.
1. Planning
During the planning process, the committers decide on the main features for a release by reviewing the BigBlueButton Road Map along with all starred issues and, in particular, issues marked with tags stability and usability.
We review the features according to the development priorities for our target market (see When will feature X be implemented?).
2. Design
After the planning phase, each feature for the release is assigned an issue in the BigBlueButton Issue Tracker (if it does not already have one). This allows the community to track the progress of each release. See List of open issues/enhancements.
For small features, especially bug fixes, the associate issue provides a sufficient record for coordinating and tracking the development effort.
For more complex features, such as record and playback, API changes, or creation of an HTML5 client, the lead developer for the feature would post specifications to BigBlueButton-dev for review and comment.
For examples of previous posts, see:
3. Development
During the development phase, the committers hold bi-weekly (and sometimes weekly) calls as development proceeds towards beta.
The submitter of the pull request is responsible for ensuring the feature works correctly against the target branch. For pull requests that make major changes, the submitter must provide with the pull request additional documentation to make it easy for others to review:
- What the code does (with reference to the associated issue)
- What changes were made to implement the feature/fix the bug
- Document of design changes
Each commit is reviewed by another committer who is familiar as well with the area of the product. Any substantive commit to the core is reviewed by Richard Alam, BigBlueButton's CTO.
If the reviewer of the update believes it will negatively affect stability or usability, the request will be rejected and the developer will need to rework the request based on feedback by the reviewer.
Once an update has been committed, it is tested by other developers in the latest build. In that way a build will iterate through development towards beta. The release stays in development until all core development is finished and all obvious bugs have been fixed.
Before the beta release, the documentation for installation, setting up of the development environment, and overview of new features are all updated for the release. It's ready for others to install and test.
4. Beta Testing
Once a release is moved to beta, the public Ubuntu packages are updated so others in the BigBlueButton community can begin installing and using the build.
The product will go through one (or more) betas until the community reports no more major bugs. Additional work that occurs during this phase includes:
- Localization of the product
- Updating and completing all documentation
- Updating packaging so it installs without errors, both on a new install and an upgrade from a previous version
We strive to have very stable beta releases. As the release moves through iterations in beta, members of the community will start to run BigBlueButton on production servers. (Yes, some run it for months on production.)
When all the bugs are fixed and issues are closed, the product moves to Release Candidate.
5. Release Candidate
For us the release candidate is done -- which means issue a release is changing only the label of the build.
We tend to wait for (at least) two weeks of community use before we change the label to release. Again, stability is paramount for reaching a release candidate build.
During the stage at release candidate the core committers monitor the mailing lists, twitter, and feedback from members to look for any bugs or issues that would impact the delivery of general release.
Many times during the beta and release candidate process we are asked "What is your release date?". Our motto is “we release on quality, not dates.”
6. General Release
After a (roughly) two week period in which no one has reported any issues for a release candidate, the committers change the label (such as 0.9.0-RC to 0.9.0) and announce the release (see release announcement for 0.9 and release announcement for 1.0).
Contributing to BigBlueButton
How can I contribute
BigBlueButton exists because many developers have contributed their time and expertise to its development.
At first glance at the underlying architecture, BigBlueButton may seem complex, but it's not really once you get to know the system. The BigBlueButton client is written in Javascript. The BigBlueButton server components are written in a combination of Java, Grails, and Scala. You don't need to learn all these languages to help out, but you should be very comfortable programming in Java as JavaScript, Grails, and Scala are all similar to Java.
Before you can contribute as a developer, you need to invest some time into understanding BigBlueButton's architecture, and you need to setup a development environment. The source code for BigBlueButton is hosted at github, so you'll need to understand how git works and the workflow for distributed software development.
Like other open source projects, a good place to start is to try fixing an open issue. Some bugs are more important than others. Stability and usability issues are very important to the BigBlueButton community.
I'm not a developer, can I still contribute?
Don't worry if you are not a proficient developer -- there are many ways to help out. You can become proficient in the installation and configuration of a BigBlueButton server. Each month, there are many new users in bigbluebutton-setup that need help with setup of BigBlueButton, especially setup behind a firewall. You can contribute a language file. You could point out any errors to this documentation. Such assistance reduces the support load on us and gives us more time to work on improving BigBlueButton.
Any contribution by external members for inclusion into BigBlueButton will be reviewed by one (or more) of the committers. The process for submission and review depends on the complexity of the contribution and requires that you have signed a Contributor License Agreement.
Why do I need to sign a Contributor License Agreement to contribute source code
Before we can accept contributions to BigBlueButton, we need to ensure there isn't any ambiguity on the ownership of material committed to the project. Therefore, everyone wishing to send us a pull request for review must have a signed Contributor License Agreement in place. For background on our reasons for doing this, please see https://www.oss-watch.ac.uk/resources/cla.xml.
To obtain a committer agreement, download BigBlueButton Inc. Contributor Agreement. Except as set out in the agreement, you (and your employer if you have an intellectual property agreement in place) keep all right, title, and interest in your contribution. If you (and your employer) are in agreement with its terms (be sure to use a physical mailing address for the address
section to make it legal), then sign, scan, and e-mail a copy to cla at bigbluebutton dot org.
Once we receive the signed Contributor Agreement, we can review your submission for inclusion in BigBlueButton. The process for submission depends on whether it's fixing a bug (submitting a pull request) or whether it's an enhancement (submitting a feature).
Submission of a pull request
If you want to submit a pull request, your chances of acceptance are greatly improved if the following are true:
- You are an active participant in bigbluebutton-dev and have demonstrated an understanding of the product by helping others and participating in discussions on other patches.
- Your patch fixes an open issue.
- Before submitting your patch, you have announced your intent to bigbluebutton-dev or commented on the issue itself.
- You have received positive feedback from a committer on your intent.
The ideal patch submission has all the above true, which essentially means you have built a relationship of trust with other BigBlueButton developers and have been visible on your willingness to contribute your skills to the project.
There are a number of must haves for your submission to be accepted.
- You have forked BigBlueButton on GitHub and submitted the patch as a pull request (this makes it much easier for a committer to review and incorporate your patch).
- You have signed a committers agreement so there is no ambiguity that your contributions may be released under an open source license.
- Your submission is LGPL V3 (unless it modifies existing code that is under a different license).
Specifically, for using GitHub, you need to do the following:
- Fork BigBlueButton on GitHub
- Create a topic branch -
git checkout -b my_branch
- Push to your branch -
git push origin my_branch
- Create a Pull Request from your branch
GitHub provides some good help in the above steps, and there is an excellent Pro Git book by Scott Chacon available on-line.
Submission of a feature
Some of the items in our issue tracker are enhancements to the core product. If you are interested in contributing an enhancement, your chances of acceptance are greatly improved if the following are true:
- You have had previous pull requests accepted by a committer.
- You have posted a message to bigbluebuton-dev mailing list signaling your willingness to work on the enhancement. In your post, you have provided (at minimum) the following:
- An overview of the design and implementation of your feature. For examples see: Proposal for Preupload of Documents
- An outline of how you intend to test the enhancement.
- An estimate of how much time you have to work on the enhancement.
- A committer has signaled their intent to work closely with you on the enhancement.
Like other open source projects, the participation of a committer is central to the above process as they will take the responsibility for reviewing and signing off on your contribution.
Testing your submission
Depending on the complexity of your patch or feature, it should be accompanied by test cases or, at minimum, a series of steps to test whether the code is functioning properly.
We are continuously trying to incorporate more automated testing into the BigBlueButton development process, such as using TestNG.
We know that the most important part of any submission is the ability for others to test that it works correctly. Any documentation, sample code, or unit tests that you can provide will greatly reduce the effort of the committer to review your submission.
Coding conventions
Take a look at the existing code in BigBlueButton and follow it as an example of the project's coding and documentation conventions.
For code written in Java, we follow the Java Coding Convention with minor changes. We will be documenting those changes in this wiki.
For documentation of code method -- especially those classes that provides an API to other classes -- should be documented using the JavaDoc format.
Where should I report potential security issues?
If you think you've found a security issue with BigBlueButton, we ask that you do a responsible disclosure and e-mail us directly at security .at. bigbluebutton .dot. org.
We will respond to you quickly, work with you to examine the scope of the issue, and give priority to fixing it as soon as possible.
Installation
What are the minimum hardware requirements for the BigBlueButton Server
See before you install.
What are the minimum bandwidth requirements for the BigBlueButton Server
You'll need good upstream and downstream bandwidth from the server. We recommend 1 Gbits/sec bandwidth in both directions. Having a server with less bandwidth, such as only 100 Mbits/sec, will only lead to audio and video issues with users.
Can I install BigBlueButton on a shared hosting server, such as GoDaddy
Likely not. First, you need root access to install BigBlueButton. If you have a hosting account that only gives you, for example, FTP access and a cPanel/plesk interface, you will not be able to install BigBlueButton.
Can I install BigBlueButton on EC2
Yes. The steps are covered in the install documentation.
OS Requirements
Ubuntu
Older versions of BigBlueButton, up to and including version 2.4, required Ubuntu 18.04 64-bit. The current version of BigBlueButto n2.5 requires Ubuntu 20.04 64-bit. See Install BigBlueButton.
We (the core developers) have not installed BigBlueButton on any other version of Ubuntu. It probably won't work.
CentOS
There is no support for CentOS.
We do have experience with CentOS. In April, 2010, we released BigBlueButton 0.64 with RPM packages for CentOS 5.4. However, based on our experience of developing, building, and testing both Ubuntu and CentOS packages, we stopped supporting RPM packages after that release.
Why?
In a nutshell: quality. We found it very difficult to test and maintain packaging for both RPM based systems (primarily CentOS) and Ubuntu. Rather than try to maintain them both and have them "kind of" work, which leads to many, many posts in our forums when users encounter difficulties with an install, we decided to invest heavily in testing and maintaining the Ubuntu packages. They are now very solid and well tested.
If you really want support for CentOS, you can contact one of the following companies for commercial support. Any financial contribution you make for updating and maintaining the CentOS packages will directly benefit other CentOS users in the community.
You can see further discussion on the support for CentOS in issue 1379. (Update: We are getting increasing interest in RPMs for BigBlueButton. We may be updating this section in the future.)