If you are a developer, youll find lots of answers herein that have been collected from discussions on our mailing lists.

Doing so makes it easy for others to use Google to search for information about the project.

As an open source project, you are welcome to fork BigBlueButton and build your own applications upon it.

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.

If we get an application without an answer, we assume the application is from a bot and delete it.

In the BigBlueButton community at-large all the members, users, developers, educational institutions, and commercial companies are all collaborating on using and improving BigBlueButton.

The quality of the software, in turn, depends on the developers involved and the process we use to build a release.

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, youll notice from the previous release notes that we tend to spend months testing each release candidate before issuing a release.

BigBlueButton itself is built upon many great open source projects (such as FreeSWITCH, redis, Akka, red5, 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.

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.

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.

We designed BigBlueButton to be a highly collaborative system.

Weve seen examples where there have been 21 webcams shared in a session If we wanted to handle hundreds of simultaneous users, we would have restricted the sharing of webcams and audio channels.

As the Lead Architect for our project, he has the final say.

The BigBlueButton project also participated in the 2010 Google Summer of Code (Google paid for two students to work on the project).

Any developer that wishes to become a committer can achieve it through participation.

The decision of expanding the committers group rests with the committers.

This allows the community to track the progress of each release.

When a feature is ready for commit, the committer sends a pull request to merge the work into the Master branch.

Java Mac For Big Blue Button