Many software developers have their own side projects, which are often open source projects. When those open source hobbies grow too big, how do developers manage them?
All open business and projects face this problem: If they grow too big, more members are necessary for carrying the collective load. Their strategies for scaling are important.
One popular open source community recently faced this problem. And the way that community surmounted it teaches us something about the art of scaling an open organization.
Explosive growth
At the center of this story is the community that formed around virtual private network software SoftEther. SoftEther is the product of students at the University of Tsukuba, and Daiyuu Nobori is the lead developer. Nobori started developing SoftEther 1.0 at the age of 18 (to allow him to bypass the firewall his campus had installed). The software was so powerful that even the Japanese government opposed it—hence, he was not even allowed to release it as freeware at that time. He started his own business, SoftEther Corporation, and sold SoftEther software under it. A few years later, he continued development and also used it as part of his master's thesis research.
In 2013, he decided to open source the SoftEther VPN code under the GNU Public License. The version of SoftEther VPN his business sold then changed names to PacketiX. Within a few weeks, SoftEther VPN gained significant traction and became one of the most popular open source VPN applications that can bypass China’s Great Firewall (GFW).
SoftEther VPN’s huge growth was a surprise for Nobori. Initially, he was happy about it, and he put quite a lot of effort into maintaining the project. As time passed, however, priorities changed, and he could not spend as much time on the project as he would have liked to. A few contributors sent pull requests to his project repository online, but they were left there, waiting for him to accept the changes.
New community, new worries
People were worried that slow change meant that the project was dead. Some even opened an issue, asking Nobori directly if the project was dead. A few days after, Nobori replied that the project was in fact not dead, but that he wanted to focus on the stability of the software. Implementing new features and changes would require thorough testing, and that, in turn, would require a lot of his time.
Dissatisfaction from users and contributors increased, and Nobori realized that he had to do something to resolve this issue that was dividing the community. He was just a developer that runs a business—but was suddenly faced with community management challenges. Running a business that makes open source software is no easy task; now, he had to manage and balance between community expectations and enterprise software stability. On top of that, he had to learn how to trust the right community contributors.
So here’s what he did.
First, Nobori proposed structural changes to the project, mirroring the upstream/downstream model Red Hat uses with its Fedora project. This model allowed for an upstream project that accepts the latest pull requests, proposed changes, and new features, as well as a downstream project would pick certain stable features and incorporate them as necessary and appropriate. This change allowed users who want the latest features to actively develop and test those features and provide feedback to Nobori and the community. On the other hand, companies in need of more predictability could continue using the stable features.
Second, Nobori invited individuals to become upstream project maintainers. Users were excited about this, and offered lots of their own opinions. But now Nobori faced yet another challenge: A flood of varying opinions on how this model should be done. Should the upstream be just a separate branch on GitHub, for example, or should it be a separate repository entirely? The community continues to debate these issues.
Nobori’s predicament reminds us that even the smartest person in the organization has only one pair of hands and 24 hours a day; it is simply impossible for one person to do everything. Even open leaders not involved in the software business or in programming communities can learn from Nobori’s strategies for scaling the SoftEther project. Most importantly, we can learn the importance of trust and delegation in open organizations:
- Create passion through trust. When people feel trusted and receive certain powers, they become more motivated and enthusiastic about their work. Nobori learned to let go of some responsibility (and therefore of some power), and his community rewarded him for it.
- Learn to handle floods of different opinions. Hear others out, try to empathize and reason with them, and make the best decision out of what you learn. In the end, even if your decision as a leader is different from the one’s you heard while listening, your teams will know you have understood their perspectives and are more likely to help you realize your vision.
Most importantly, the SoftEther story teaches us that many people out there are very willing to help you carry your burdens. The question is: Are you willing to listen to their opinions, trust them, and let them help you?
Comments are closed.