Since the summer of 2009 we’ve had many releases of – 0.50, 0.60, 0.61, 0.62, 0.63, 0.64, 0.70, 0.71, 0.71a, 0.80, 0.81, 0.9.0, 0.9.1, and 1.0 – each release improving on the previous, each reflecting the desire by the core developers to build a solid product.
We think of BigBlueButton as a product. We have a development process to ensure we deliver a real-time platform that is both easy to use for end-users and solid to build upon for developers.
This document outlines our road map ahead for BigBlueButton.
The requirements outline herein are largely driven by our target market: on-line learning. We are also often asked “Why are you focusing on only one market – don’t you realize that BigBlueButton would be great for market X, Y, and Z?” We realize that the core features – shared chat, presentation, voice, video, and desktop – are the same core features for many markets (including on-line learning). It is our belief that by focusing and delivering a world-class product for on-line learning, we will, in essence, deliver a world class solution for other markets as well.
What are the requirements for on-line learning? At the highest level it’s to provide remote students a high-quality learning experience. In other words, we think of BigBlueButton in terms of “How can we make on-line learning more effective for teachers and students?”
There actually five distinct roles in any deployment of BigBlueButton: teacher, student, administrator, support, and developer. Each person has a job to accomplish; each person has their own user stories:
As a teacher I want to effectively communicate my content in a way maximizes student learning and engagement. I want interactive classes, not just a one-way lecture (though there are times with larger classes that one-way lectures make sense).
As a student I want to efficiently learn the material so I can gain new skills and (for most students enrolled in an educational institution) obtain good grades to help be build a better career. I want opportunities to interact with the instructor (either one-on-one or during the class). I want to access recorded content to assist in my learning and application of concepts.
As an administrator I want to easy access to BigBlueButton from my educational institution’s learning management system (LMS).
As the manager of support I want BigBlueButton to be easy to teach and support so I can achieve a high satisfaction rating from my users and lower my support effort (and costs) relative to other options.
As a developer I want to install BigBlueButton in 30 minutes (or less). I want to be able to integrate BigBlueButton into my product in less than four hours so I can explore its value with others.
We can measure our success by how easily we enable each person to accomplish their job. We also have goals that that not specific to any role; rather, they underlie all requirements.
Stability - We want rock-solid stability for users. To this end, we do extensive testing for each release. Case in point: BigBlueButton 0.80 had four beta releases and three release candidates over four months, BigBlueButton 0.81 had five months of beta testing, and BigBlueButton 0.9.1 had five months of beta testing. In addition to testing by commercial companies that support BigBlueButton, we also run the BigBlueButton demo server for weeks without reboot.
Usability - Usability touches all human-facing aspect of the product, including the quality of audio and video. We want first-time users to have a very positive experience. A lot of effort goes into the usability in each release. We believe that if we can add features while at the same time making the user experience more consistent and elegant, we are headed in the right direction.
Modularity - BigBlueButton is a large application with many components. We constantly look for to reduce the coupling between components. A good example is the integration with FreeSWITCH, which is done entirely through session initiation protocol (SIP) and FreeSWITCH’s event socket layer – this enables FreeSWITCH to run on completely different server if you wish.
Code Quality - We are constantly learning as we evolve BigBlueButton, and we are constantly applying our increased skill to refactoring and rewriting components as we extend BigBlueButton’s feature set and architecture. We know that for other developers to contribute (and to release a solid product), BigBlueButton’s code must be maintainable.
Scalability - We build BigBlueButton to be a highly collaborative environment. Our uses cases are one-to-one (such as student tutoring or coaching), small group collaboration, and one-to-many (recommend 50 users or less in a single session). Even in the one-to-many, you can have 20 users all sharing the webcams and all able to talk. In other words, we didn’t build a webinar-type application that restricts usage. Still, we think about scalability in each release and add (and refactor) the product to increase it.
API - BigBlueButton’s provides a simple API for integration, and simple is good. The API has enabled a growing list of 3rd party integrations with other open source products. As we work towards 1.0, we want to keep the APIs simple to further encourage integration.
Obviously, we can’t do everything in a single release. If you read through the [release notes](/support/release-notes.html, you’ll see that we sometimes implement features in phases – such as record and playback being release first as capturing slides (v 0.80), then as capturing all content (v 0.81), and then with Start/Stop Record button (v 0.9.1) for moderator.
The following sections outline (in no particular order) the road map for BigBlueButton. If your wondering how a feature gets selected, see how we prioritize features for each release.
If you have feedback on this document, please post to BigBlueButton-dev mailing list.
This section covers the enhancements to BigBlueButton’s core.
High Quality Audio
Thanks to web real-time communications (WebRTC) suppot in FireFox and Chrome, we’ve achieved high quality low-latency audio in BigBlueButton.
Support full-screen mode, similar to hitting F5 in power point. Full screen mode should have optional notifications of new chat messages or join/leave events (1627). Full screen mode should switch back and forth between slides and desktop sharing (depending on whether the presenter is sharing their desktop or not).
Support right-left languages (1441).
For viewers, automatically centre the screen sharing window and make it show original size if there is sufficient on the viewer’s monitor (1658).
Use WebRTC for screen sharing (2943).
Enable the posting of a sub-rip title file (SRT) to the BigBlueButton server to add captions after the meeting is done (see 3864).
Create a shared text area that enables users to collaborate together on a document (see 1630).
Synchronized playback of external media
Enable the presenter to upload an audio/video file and control the playback for viewers so that everyone’s video start/stops with the presenter’s control (see 973).
Record and playback
Add a playback format that creates a single video from the session (see 1655).
The items below are not specific to any one feature but are more about the overall quality of the project.
It should be possible to setup a development environment in under 30 minutes. We made progress on this in the latest release (see developing for BigBlueButton).
We could make this easier with creating a Docker container for BigBlueButton.
Ensure all classes in BigBlueButton, both on the server (Java) and client (ActionScript) – have sufficient javadoc documentation for a developer to understand their role relative to others.
Ensure all classes are documented to the level where another programmer could understand their intent. Create easy-to-navigate documentation that enables other developers to understand the design and purpose of the code.
Close all critical, high, and medium stability issues. In general, keep testing to ensure each release is more stable than the previous. (Our BigBlueButton 1.0 release definitely continues that trend.)
Add unit test to the core modules (voice, video, chat, presentation, and desktop sharing) have unit tests to verify their functionality.
The development environment should enable developers to run the unit tests to verify conformance.
The API should have a complete test suite to verify stability and conformance to documentation.
Verify that a BigBlueButton server can run under heavy load with large number of users for 48 hours without any failure.
BigBlueButton is currently tested through the community, through commercial companies building upon BigBlueButton, and through the developers. Our beta release cycles span months to ensure adequate testing.
Having a repeatable stress test environment could help us shorten our release cycles.
Add an API call to enable external applications to inject messages into the chat window (see 1660).
Add an API call to enable an external application to upload a new presentation.
Add more capabilities to bbb-conf to change the logging levels of all applications, making it easier to spot errors (1661).
Other areas for investigation
This would enable BigBlueButton to integrate with other commercial conferencing systems that support H.323
This would enable us to integrate with other popular IM systems (1676).
Create a rest-based API for BigBlueButton that would implement all the current BigBlueButton API calls. This would make it easier for other applications to integrate with BigBlueButton.