"It's a brilliant surface in that sunlight. The horizon seems quite close to you because the curvature is so much more pronounced than here on earth. It's an interesting place to be. I recommend it."
Creating a successful company is difficult; but creating a successful company, a successful open source project, and a successful ecosystem all at the same time is much more difficult. This article takes a retrospective look at some of the lessons we have learned in building BigBlueButton, an open source web conferencing system for distance education, and in building Blindside Networks, a company following the traditional business model of providing support and services to paying customers. Our main message is that the focus must be on creating a successful open source project first, for without it, no company in the ecosystem can flourish.
The common portrait of the entrepreneur is someone dreaming of the future, a future somewhere over the horizon. The entrepreneur is portrayed as someone who is constantly looking for that “next big thing” and who is willing to work longer, harder, and with more focus than others to realize it. However, for an entrepreneur to be successful, at some point the dreaming must shift to focus on the near-term horizon of necessary activities to build a viable business. Successful entrepreneurs live in the present, where the horizon is very close, and the sunlight cast from the company’s cash flow is very, very bright.
Shifting to a focus on the near-term and maintaining focus is a difficult and complex challenge. At Blindside Networks, we have faced this complexity many times. In this article, we share some of the key lessons we have learned over the past three years.
Blindside Networks and BigBlueButton
Blindside Networks was spun out of Carleton University's Technology Innovation Management (TIM) program to provide commercial support to BigBlueButton. BigBlueButton is an open source web conferencing system for distance education. Initially, it was developed by the students and faculty in the TIM program. Richard Alam, a co-founder of Blindside Networks, was the first student in the TIM program to complete a thesis on how to make money from open source. He started the project and continues to be one of BigBlueButton's lead developers. The idea for BigBlueButton was simple: reduce costs by providing a viable open source solution for giving remote students a high-quality learning experience. The challenge was to create a viable business around that solution.
At Blindside Networks, we follow the traditional open source business model: make the product freely available and charge for support and services. More specifically, start with a business model that is based on professional services and, over time, gradually shift a portion of our development efforts to offer complementary products and services that are proprietary. Along the way, we partner with other companies to offer a whole product to customers.
As an open source business, Blindside Networks must balance its entrepreneurial activities with its community activities. Unless BigBlueButton itself actually solves problems around distance education (i.e., unless it "works"), the opportunities for Blindside Networks to grow its revenues from services and support are limited. Furthermore, we must nurture the project and encourage participation from many users, developers, and customers from diverse backgrounds and interests. This creates a very healthy ecosystem that, in turn, creates entrepreneurial opportunities for Blindside Networks and others.
As entrepreneurs, the challenges we face at Blindside Networks are threefold:
Leading an open source project that solves a real-world problem.
Creating an ecosystem for the project that attracts others to improve it.
Building a viable business providing support and services to the ecosystem.
In the following sections, we share our experiences in the hopes that others can benefit from knowing what has worked well for us and what we would have done differently if we could start over. Of course, we cannot start over, but we hope that reflecting on these lessons will help others face similar challenges. We include lessons from both the perspective of a business and the perspective of an open source project.
Lessons Learned Operating a Business
Lesson 1: Focus on one market segment. At Blindside Networks, we focused our efforts on the distance education market. Along the way, we received calls from other companies asking, “Don’t you realize that BigBlueButton could be used in market X?" (An example of X would be remote health care.) From a business point of view, they would be correct. At the core of BigBlueButton is the ability to share voice, video, desktops, slides, and chat - these are all features that can be applied to many different markets. But from an entrepreneurial point of view, we adopted Geoffrey A. Moore's “crossing the chasm” strategy and focused on one market to generate awareness and word-of-mouth marketing. Furthermore, our absence in other markets created opportunities for other companies, which we believe contributed to the health of the ecosystem and has lead to partnerships opportunities for Blindside Networks.
Lesson 2: Provide first-class community support for the open source project. This appears to be counter-intuitive: how can a company provide commercial support when its developers (wearing their open source hats) are providing first-class community support? We have seen other companies do it differently: they state upfront that they provide no support in the mailing lists, and if you want their support, you must pay. We believe that adoption of any open source software begins with trial testing and usage. Without a successful trial, there can be no large-scale deployment. Because BigBlueButton is free/libre open source software, it is very easy for a university or college to start a trial if they can get it working properly. We take the perspective that, if we consciously commit a portion of our resources to assisting others on the mailing list, then as their adoption of BigBlueButton grows so does the pool of potential customers that may approach us later on. As an analogy, if you want a bountiful harvest of oranges, you have to be willing to plant many seeds and nurture many trees before they will bear fruit.
Lesson 3: Be upfront with your business model. People buy from people, but they will only buy if you let them know what you sell. When potential customers approach us, they are looking to accelerate their deployment of BigBlueButton to end users and reduce their risks of using open source. We let them know upfront that: i) there is a business model behind the BigBlueButton project; ii) Blindside Networks earns its revenues through support and services; and iii) our revenues are funding the development of BigBlueButton for the long-term. We charge a premium for our support, but the message we try to convey is that you want to pay a premium - and you want to know that others are also paying a premium - to be confident that we have the means to accelerate improvements to BigBlueButton for your benefit.
Lesson 4: Be clear about what you will not do. Early on in the mailing list, we received a lot of requests to help change the brand of BigBlueButton, which usually meant changing the interface to the point where it no longer had any references to BigBlueButton. After a while, we publicly stated that we would no longer volunteer our time for such efforts, explaining that it was tantamount to asking the community to volunteer their time with no benefit to the community itself. While a company could still internally rebrand BigBlueButton itself, given enough time and effort, we point out it would be more cost effective to engage commercial support from other companies in the ecosystem. In this way, companies in the ecosystem earn revenue which, in turn, supports the development of BigBlueButton.
Lesson 5: Hire a designer. There is a story from the early days of Google that the founders lacked the design skills to create a fancy home page, so they left it simple. After a while, that simplicity became part of their brand. In some ways, the same occurred with Blindside Networks: none of the co-founders were graphic or industrial designers, so we focused on improving the technical aspects of BigBlueButton and left our websites (and BigBlueButton) with a very simple interface. The author personally believes the best mix of co-founders is a group that draws from three skill sets: developer skills, sales skills, and design skills. When we look at other companies such as Heroku and GitHub, it is obvious that they have strong designers in the company. Just as you cannot code your way to sales (i.e., you need someone to ask for the money), you cannot code your way to a good user interface design (i.e., you need to have some in-house design skills). We are growing our design resources now, but had we hired a full-time designer early on we could have established a stronger visual brand for both Blindside Networks and BigBlueButton.
Lesson 6: Ask qualifying questions to determine if the prospect has experience with open source. As much as we wish it were true, not every individual who calls or emails our company for support will become a customer. The challenge is to figure out which ones will. To help assess which prospects are willing to pay for services around open source, we (eventually) learned to ask the following key questions:
Have you worked with suppliers of other open source software before?
What is your business model for using BigBlueButton?
What is your daily rate for professional services?
The first question reveals whether they have ever paid for support for open source software. If the answer is "no", then we ask additional questions to figure out if they equate "free" open source software with free (or low-cost) support. In most cases, they are seeking low-cost support because there is no business model behind their use of BigBlueButton. They are simply consumers of open source software. As such, we encourage them to engage the community for support, pointing out that the more they contribute to the community (in the true spirit of open source communities), the more support they get back.
If there is a business model, then we explore whether it is based on cost reduction or revenue generation. Cost reduction is good because most organizations can justify spending money in the short term to save money in the long term. When it is revenue generation, we ask if they intend to generate new revenue from BigBlueButton or incorporate it into an existing product and make revenues later on from increasing their customer base. In the former, there are opportunities for sharing revenue and growing together, but in the latter, any additional support costs for BigBlueButton will likely be viewed as another cost of doing business, and will be more scrutinized and reviewed.
The third question helps determine whether their rate for professional services is in alignment with ours. If the gap is too large, such as when doing business with companies from India, the likelihood that they will pay for our services is low. We are not surprised by this, and, in such cases, we encourage them to focus their resources on generating new revenues with BigBlueButton. This reduces their risk of spending what is perceived to them as large amounts of money without a certain return on their investment, and this positions Blindside Networks as ready to assist when there is a business case to justify acceleration of growth.
Lessons Learned as an Open Source Project
Lesson 1: Treat each release as if it were a product release. As open source developers, a perennial question we faced for each release was: “Have we done enough testing?” Fortunately, Blindside Networks had paying customers right from the beginning, so we established the mindset early on that the recipients of each release were paying customers, not just other open source developers. If it were only developers, we could cut some corners and work on new features. Instead, we spent an average of four extra weeks near the end of each release cycle fixing countless small issues that might be invisible to a developer, but not to a customer using BigBlueButton for a three-hour lecture. This investment in testing meant that we delivered fewer features in an iteration, but it also meant we had fewer issues to patch after a release, and our product was viewed as more solid. Ultimately, this level of polish has lead to a wider adoption of BigBlueButton, which has lead to more support and service opportunities.
Lesson 2: Put on your developer hat when communicating with the community. We are running a business, but when interacting with the open source community, we put on our developer hats and treat other members as peers, not prospects. We have seen mailing lists of other open source projects degrade into a forum where vendors rush to posts unhelpful answers with the tag line: “Contact me off list for help.” Once a community reaches that point, most newcomers quickly conclude that the smart people have all left, one’s contributions will not be reciprocated, and all that remains are the vultures picking over the bones. BigBlueButton has three mailing lists: developer, setup, and users, and we take the perspective that we are not there to sell, but to solve problems. As a result, there is a very healthy exchange of ideas and support on the mailing lists that strengthens the community and encourages others to reciprocate.
Lesson 3: Figure out the licensing model early on. All of the code written for BigBlueButton is open sourced under the Lesser GNU Public License (LGPL), but it did not start out that way. Early on, we integrated another open source project called Xuggler, which, at the time, was licensed under the GNU Affero Public License (AGPL). The AGPL, unlike the LGLPL, is a reciprocal license and requires a company to make available under an AGPL license any code linked with Xuggler, even when offering a hosted product. After incorporating Xuggler, we received a friendly-but-firm call from the Xuggler developers stating that if we intended to use Xuggler, then we must open source BigBlueButton under the AGPL license as well. To avoid having to open source all of BigBlueButton under AGPL, we isolated the desktop sharing component as a module so that BigBlueButton did not depend on desktop sharing. Hence, we only needed to license the desktop sharing component under the AGPL. To make it possible for companies to integrate BigBlueButton into their product, we offered a dual-license for the desktop sharing component: AGPL and commercial. This was all ad hoc. While we did make some sales from a commercial license for desktop sharing, the terms of the AGPL license were restricting others from integrating BigBlueButton into their open source projects. After a few months, we reworked BigBlueButton so it did not require Xuggler and reverted our codebase to LGPL, betting that by accelerating the adoption of BigBlueButton we could earn more revenues in the long term. While it is impossible to pursue both strategies in parallel to determine if this is true, we believe it so. (As an interesting side note, the Xuggler project eventually moved their codebase to LGPL as well).
Lesson 4: Write a list of frequently asked questions (FAQs) from the beginning. The total number of posts in our mailing lists now exceeds eleven thousand. Early on, we saw the high traffic as an endorsement of BigBlueButton; we viewed each question as an opportunity to build a relationship with a newcomer and demonstrate that the members of the BigBlueButton project really cared about ensuring they had a positive experience with the project. Looking back at some of those early threads, such as setting up BigBlueButton behind a firewall, there were over thirty messages of patient support. When the member finally got their BigBlueButton server configured, they were very happy, but it took a lot of effort on our part to achieve it. Now with a FAQ of over 100 answers, we still, for example, answer lots of questions around setting up BigBlueButton behind a firewall, but the threads are shorter, the effort is less, and the members are still just as happy when their installation of BigBlueButton works.
Some of our strategies - such as offering first-class community support in the mailing lists - seem counter-intuitive, but our experience over the past three years suggests that, when an education or commercial institution makes a decision to deploy BigBlueButton, they are more likely to purchase from someone who has invested their expertise in providing them support long before deployment was even considered.
We thought a lot about how to build a strong community. It boils down to this: whatever behaviour we expected of others (professionalism, reciprocity, and non-solicitation), we had to exhibit it ourselves.
We have planted a lot of seeds with BigBlueButton, and our strategy to focus on a single market segment has created opportunities for other companies, which is good for the ecosystem. An ecosystem with only one company is not a healthy ecosystem, and we do not want to be the only company offering commercial support for BigBlueButton, we just want to be the best.