This article is based on the author’s speech “Developer Ecosystem Building, Open Source Community Operations and Governance” at the “Global Cloud Computing Open Source Summit” held in Beijing on April 19-20, 2017. The original was published on May 23 in the WeChat public account of the Cloud Computing Open Source Industry Alliance.
Conference speech transcript:
Good afternoon everyone, I am Lin Lvqiang, currently working as an operations manager in the Huawei Developer Community. I am honored to be invited by the organizer OSCAR to share my views and experience in the “Open Source Governance Sub-forum”. Today’s topic is “Developer Ecosystem Building, Open Source Community Operations and Governance”. Now many companies are talking about “ecosystem”, but everyone may not be particularly familiar with the term “developer ecosystem”. Let me start from the familiar history of industry ecosystems.
You’ve all seen these companies, and you’ve all experienced these eras. Why do developers decide the winners? We all remember that in the PC era, Microsoft Windows won big in the desktop field. Windows had many users and many developers, making Microsoft still control the PC ecosystem to this day. This example shows that for the establishment of a developer ecosystem, open source may not be the key. Microsoft was closed source back then. The key is that developers believe this platform has the most users and can get business opportunities in this ecosystem.
Next came the internet era. Foreign companies like Google, Facebook, and Amazon, and domestic companies like Baidu, Alibaba, and Tencent also used their respective fields to accumulate a large number of users and attracted many developers to join their ecosystem circles. In this stage, internet companies started using OpenAPI and Open Source to make developers stick to their platforms and ecosystems. For example, Google provided the Google Map API for other website services to call, and also built Google Code to provide its open source projects to developers.
In the mobile era, Apple and Google won big. I’ll explain in detail later. There are also currently rapidly developing industries, whether IoT or AI, or even some we can’t see yet, very far away. What will the industry be like in 5 to 10 years? Which companies will win? Developers will decide the winners. What technologies and products do developers adopt as the infrastructure for applications? This ecosystem is the key.
How do developers help companies win? Let’s look at the mobile era. In the early mobile era, these six ecosystems were competing: smartphone leader Apple, Android developed based on Linux, BlackBerry which was the first choice for North American business people back then, HTML5 launched by W3C, development platforms across Apple and Android operating systems, and Microsoft’s Windows Phone.
Why did the first two win in the end? First, because developers created “technical demand”. Developers primarily consider user base and monetization: Which platform has the most users? Where is it easiest to launch a successful App? I’ll spend time learning this platform’s technology. At the same time, developers also consider from a technical perspective: Are the development tools easy to learn and use? Does the technology development have advanced nature, can it lead the next generation of technology development, and become a long-lasting general technology field? Therefore, “technical demand” is created from both commercial success and technical prospects.
Then, “competitive barrier” is the Matthew effect in the process from various competitions to oligopoly. An ecosystem that attracts more developers will produce more applications. More applications can better serve consumers and attract more consumers, which in turn attracts more developers to enter this ecosystem to get a piece of the pie. The number of developers in the world is limited. Which company or technology ecosystem they decide to join determines how strong the competitive barrier of this developer ecosystem is.
With hindsight, we know Apple and Android won. One is closed source, one is open source, both won. This again shows that for the establishment of a developer ecosystem, open source is not a panacea. But from the perspective of technology development, open source is undoubtedly an increasingly important means to attract developers. Companies need to think about why we want to open source? If so, how to apply open source, or how to combine open source and closed source to win.
Take Android as an example. It created an environment for commercial monetization. Apps published on Android can make money and can be closed source. At the same time, the Android operating system itself is open source, making Android have the situation of Windows in the PC era in the mobile era. Hardware manufacturers pre-install a lot, there are many users, and developers naturally swarm in.
Compared to Windows, Android’s advantage is open source, standing on the shoulders of giants, using the Linux kernel to rapidly develop mobile operating systems, while ensuring developers’ commercial interests without bearing open source obligations. This is closely related to what the previous two experts, Director Bi Chunli and Teacher Lin Chengxia, talked about regarding open source licenses. For example, in general Linux distributions, if there are pre-installed Apps, based on GPL license requirements, these Apps must be open source; but Android used a clever layered design when using Linux, limiting the scope of GPL application, so that the top-level Apps can be pre-installed and distributed in a closed source manner. In addition, open source also makes hardware manufacturers more willing to use it. Using the Android operating system doesn’t require paying licensing fees to Google, and there’s no piracy issue, much friendlier than Windows.
The choice of technology is also related to technology trends and developer perception. Microsoft has invested in operating systems for many years. Theoretically, investing in mobile operating systems, it should be very strong. Windows Phone didn’t start too late in the mobile wave, but its development speed was relatively slow. On one hand, it wasn’t as early as Apple, and on the other hand, it faced competition from open source Android, and didn’t make developers feel and believe that Microsoft was about to lead the future technology trend.
In comparison, Apple and Android were earlier and made developers believe there was market development and technical leadership, so they had the advantage of creating technology and competitive barriers from the beginning. Therefore, companies facing many technology developments need to consider which new technology fields to get tickets for first? Companies need to invest first and cannot set short-term goals of making money immediately, because with this idea, it will only focus on big customers and project delivery, and the development speed of the developer ecosystem may instead be slow.
From the perspective of the developer ecosystem, whether it’s open source Open Source or open capability OpenAPI, they are both means. Each company’s positioning, strategy, development trajectory, and market environment also have many differences. We need to see what the environment of this ecosystem is and what roles are in it. To put it abstractly, if I want to create a tropical rainforest on a piece of land, or restore a destroyed rainforest, I need to think about what kind of environment, soil, and climate to create to possibly form a tropical rainforest? Even judging from its latitude that it’s not in the tropics and absolutely cannot form a rainforest is also good, at least it won’t be a waste of effort. Also need to consider what species of plants and animals should be in it? The Amazon rainforest and the Java rainforest definitely have different ecosystems.
So this PPT slide explains that we need to identify roles in the ecosystem. This role should be able to help us introduce high-value developers. We also need to identify which types of developers to target and what open source or open capabilities to provide to solve their pain points. Through community operations and interaction with developers, we can guide high-value developers to become core developers, making them loyal to and enjoy using the company’s tools and products. These people will be the company’s best spokespersons and communicators. In Huawei’s terms, our core developers are “Huawei people without employee badges”.
In addition, we need to make developers feel that joining this ecosystem has a future. Just like the smartphone example earlier, BlackBerry might make developers feel that following it doesn’t seem to have a future. Why? Because it targets North American high-end business people. If I’m making mobile games, I’d rather do Android, where more consumers can use my App, and it’s also a Google product. Google itself demonstrates technical height, which is already its brand impression. Therefore, so-called developer ecosystem building is not just about valuing the optimization of development tool performance and experience. The most important thing is to have a future (money), be able to solve pain points, and also have the value enhancement of the technical brand and the strengthening of developer reputation.
The three circles in the diagram are the core area, extension area, and peripheral area. The roles in them are just examples and do not represent the positioning of the Huawei developer ecosystem circle. Each company’s ecosystem may have different roles and be placed in different circles. This model helps us think about exactly which roles to choose for cooperation or guidance. After clarifying the functions of roles and the company’s goals, we need to find paths from community operations. Which aspects of developers to introduce first, and which roles to introduce later?
Each role has its positioning and significance. For example, for Huawei, the most important may be ISV independent software vendors. Why? Huawei has always been selling boxes. In recent years, under the ICT digital transformation and “being integrated” strategy, through the capability open platform, various services and APIs are provided for some partners to integrate and call our services and capabilities into their products and solutions. Our partners make money, and Huawei can make money. So we can identify these and understand these developers. Our developers refer to the developers in the partners. Understanding the direction and needs of ISVs, we can form an introduction path.
Others like consultants, independent developers, and service providers are very important, but may not be in such a core position. More peripheral ones like incubators, media, or community and forum organizers, although placed in the periphery, are very important at certain stages. They are a point for creating a diverse ecosystem. An ecosystem won’t only have elephants but also ants. For some companies, especially B2B companies, they might think ants are not that important, elephants are more important than this. They don’t know how many ants are needed to feed us. This change in thinking is also closely related to the company’s values, strategic planning, and KPI setting.
There are two English words here, Advocate and Evangelist, both are important roles. Advocate refers to evangelists with employee badges, possibly served by pre-sales, solution, or technical support personnel, representing the company in external technical promotion and technical brand building; Evangelist is a core developer, a Huawei fan without an employee badge. They will preach based on actual experience using Huawei products and capabilities, what problems I solved; because of Huawei, my project can land and be done well, while other companies’ technologies and solutions may not be able to do so, thus forming a live advertisement and industry endorsement. Many companies have Evangelists. For example, Google has GDE, Microsoft has MVP, both have been established for years. In comparison, most domestic companies are still considering or just starting to try.
Back to open source communities. I started open source-related research at Taiwan’s Academia Sinica in 2009, covering intellectual property, business models, community operations, and open source governance. I also participated in the actual organizational operation of Taiwan’s open source technology community. Many people were puzzled when they first heard about open source communities. Why would someone invest their own time to contribute to the community without anyone paying them a salary? Are they idle with nothing to do? I thought about this question myself at the beginning.
During the research process, I found that the reason open source communities originated in Europe and America is because the environment and soil there are more suitable for the formation of open source ecosystems. Let me give a realistic example. They don’t need to buy cars and houses to marry wives, and then work as programmers miserably, using all their time to make money. When financial pressure is relatively small and quality of life doesn’t have major problems, there’s room to develop interests. So many developers initially invested in open source communities based on interest. At the same time, the internet is an important infrastructure for open source communities. European and American programmers were the earliest humans to use the internet. Coupled with the hacker culture of not wanting to reinvent the wheel and the atmosphere of openness and freedom, the Matthew effect was produced, and the snowball just rolled.
I believe you’ve more or less heard the stories of famous hackers like Linus Torvalds and Richard Stallman. Today I discovered a technical problem and pain point, discussed it through the internet, and if I solved this pain point, I also shared it. Linus, who was still in college back then, was the same. He said online, I want to make a small and interesting operating system, and always showed the project development progress to show off, and welcomed collaboration, so more people joined him to do it together. Such an environment and culture may not be so booming in current China.
The core value of open source methodology is first to solve pain points. Successful open source communities with industry influence are all because they solved the rigid needs and pain points of that era. Linux was able to flourish because the mainstream operating systems at that time were all proprietary closed source software, and Linux was a good solution and was open source. It solved a pain point of the era. Second, open source is not only free and has low barriers to entry, but also “weakens ownership”. Previous free software still had ownership in companies or organizations. I didn’t have the right to take this code for development; but open source software, as long as it complies with license requirements, is free and open. After all developers come in, they also have a strong sense of belonging in the community because part of the code is my contribution. If you use open source methodology when operating a community or product, you must find a way to “weaken ownership” so that community members have a strong sense of participation and let community members recruit more members.
Everyone can use open source methodology. Sometimes the same pain point will have different technologies and products competing with each other. Just being open source may not necessarily have competitiveness. For example, iOS and Android development languages and tools, only a few people are willing to spend time learning both well. So if your ecosystem is big enough today and developers have already used your technology, they won’t bother to choose another one. Languages are the same as open source technologies; they have their ecosystems. Just like I can speak Chinese and English, if you let me learn Spanish again, I have even less motivation. I don’t think it’s necessary; speaking English is enough for me. So I just need to get everyone to participate, and everyone feels this is my language. Not only British people, but Americans, Canadians, Indians, even I myself feel that English can be my language, and I don’t need to pay UK patent licensing fees to speak English. This is also open source.
The incentive mechanism of open source methodology is first “use”. First, someone needs to use this project to form a certain user group for discussion and exchange; users here are often also developers. Second is “creation”. If no one uses this thing to create, its solutions and development will be very few. Third is “collaboration”. What is the concept of collaboration? I use collaboration instead of cooperation because cooperation often requires reaching consensus to start working together, but collaboration doesn’t necessarily need clear consensus. If the general direction is about the same, you can start. Even if opinions differ, open source also allows everyone to branch and develop in their own approved way. In the end, whoever does better gets liked by everyone. Fourth is “mutual help”. In the process of community operation, people who don’t understand, can’t, or don’t know find possible solutions through the internet, communicate with community members, and community members also love sharing information, which is the fifth point “sharing”, and the snowball rolls.
Today, whether it’s open source, open API, or closed source technology and products, if it can achieve these points with open source methodology, it’s the key to winning. If it’s open source, it will happen naturally. If it’s closed source, you need to find ways to create conditions and environment. The incentive mechanism makes developers have stickiness, inertia, and loyalty to the developer group and ecosystem. This is operated step by step, exerting mass power and opinions, and then introducing more developers. The ecosystem gradually expands and forms barriers, making it harder for other manufacturers to enter.
To build a good developer ecosystem with open source methodology, you need a Developer Program to implement it. My plan here is divided into four parts: “Openness”, “Enablement Platform”, “Developer Promotion”, and “Developer Operations”.
The “Openness” part is to clearly state what we have opened. Listing Open Source and OpenAPI is just the first step. You must also clearly explain what problems these projects and capabilities can solve and what cases can prove it; when developers want to try, the “Enablement Platform” provides related tools, SDKs, sample code, concise and easy-to-read and complete teaching and documentation. Of course, having a laboratory and testing environment is best.
In the “Marketing Promotion and Community Operations” part, you need to create an environment where developers can communicate with each other, such as community forums and technical exchange meetings. WeChat groups or QQ groups commonly used in China are also a way. Abroad, Slack or Facebook Groups are used to achieve communication goals. If developers want to learn related technologies, the developer program also needs to provide training, whether it’s Step by Step CodeLab self-learning services or training courses by professional lecturers, you need to find ways to let developers invest in learning without hesitation. After learning, we can guide developers to practice through programming activities like hackathons and developer competitions to make Demos. If there are problems during the learning and development process, you can also solve problems through official support and community support channels.
In this table, we selected the Top 5 most praised by developers and most strongly supported. This is the part developers care about most and is the focus of the developer program. Simply put, it’s providing good tools, solid content, free resources (such as cloud computing, training certification, etc.), and developer rewards. But don’t forget, everything must be based on the premise that the ecosystem you created can really let developers make money, solve developer pain points, and have technical future and development, otherwise these are all empty.
Let’s change the angle and stand in the developer’s position to experience a developer program with a customer-centric approach. First is discovery. There are many channels and ways to discover. I might see a post shared on CSDN or Open Source China. I might see and hear a technical research at an InfoQ Developer Conference booth. I might even see a WeChat article in my friend circle or a programmer group introducing a technology and tool he’s interested in. The second step is installing tools. If the tool installation process is annoying or has errors, he won’t install it. The third step is that after installation, he must learn related technologies. The fourth is identifying tasks. What tasks and pain points need to be identified and solved, because I use this thing maybe to solve some problems. The fifth is getting support. During use, there will definitely be problems. This support comes from third-party support, especially community support is better than only official support. The reason is that someone is willing to help you for free. On one hand, it shares the support work, and on the other hand, the atmosphere of sharing and mutual help makes this community more human. Of course, official support is definitely still needed, just reserved for VIP and commercial cooperation customers. Finally, if developers feel satisfied after experiencing these, they will recommend to other developers.
Standing from the company’s perspective, we break down the developer program according to the stages of engaging developers, step by step, what exactly we need to do with these things to ensure that after this developer is introduced, they will gradually move to the next step. It’s called the AAARRRP model.
The first step “Awareness” is marketing promotion and brand work. For example, we publish soft articles, hard ads, and EDM in media and IT communities, go to developer conferences for technical sharing and booth promotion, do SEO to increase community traffic, and introduce developers in third-party technical Q&A websites, etc. The purpose is exposure and increasing community awareness. The second step “Acquisition” is to let developers register accounts and download our related tools, and then connect to the third step “Activation”, letting developers really use it for the first time. This is the most critical step.
When developers try to use our product tools for the first time, they must be easy to learn and use to leave a good impression. A friend heard I was in the Huawei Developer Community and went to browse the community himself. He found an API for sending short messages. After his first trial, through simple guidance and use, the short message was sent. In the future, he might consider calling this function in his App.
There’s a term here called DX, Developer eXperience, developer experience; the most important metric for measuring DX is TTFHW, Time To First Hello World, which is the time spent from first trial, successful operation to the end, getting the so-called “Hello World” result. Of course, the shorter the better. Here writing less than 15 minutes is just an example. The Hello World time for each different API is not necessarily the same; but for simple functions, if he can’t successfully try once within 15 minutes, he basically won’t go to the next “Retention” stage.
To guide developers from the “Activation” to “Retention” stage, we need to provide various SDKs, API guides, quick starts, guidance documents, code samples, IDEs, and laboratory environments to help. “Retention” means that through training, forums, and certification, developers are really kept. So we need to understand who the users are and what their needs are, so that they can get help during the development process, persist, improve their abilities, and get certified, then they can enter the “Revenue” stage.
“Revenue” is key. We need to confirm first that in this ecosystem, developers can make money and solve problems. If they can’t make money and solve problems, no matter how convenient your tools are and how good the experience is, they won’t use them. So we must display some successful application cases, hold developer competitions, and encourage them with substantive plans. After they make money, they will “Refer” in the industry, and at the same time, we can also “Acquire” and “Activate” more developers from referrals.
The “Participation” stage may not be necessary for every ecosystem. Some products, if they are open source or plan to recruit external developers, they will participate in the product building process. For example, Huawei’s Apache CarbonData project recruits external developers to work together on the big data project. Because it’s open source, it also belongs to everyone. So open source projects can get developer support during the development process without waiting until after they’re built to listen to developer feedback. Xiaomi’s book “Participation Sense” talks about this.
The Huawei Developer Community launched a project in 2016 called HDG Huawei Developers Gathering, positioned as a unified activity platform for Huawei value developers. From the words “Gathering” in both Chinese and English, you can see that our purpose in organizing activities is to gather developers, and then connect developers with Huawei to create an ecosystem. When developers gather together, we not only send Huawei experts to discuss technology together, but we also let developers in the Huawei developer ecosystem share how they use the capabilities and resources provided by Huawei to achieve project success. Let Huawei and developers form a network and create a community.
At the same time, HDG is not just a technical exchange meeting. We also hold Workshops for developers to learn and use Huawei products together, and through hackathons, everyone’s creativity is landed as Demos and project prototypes. In addition, the Huawei Developer Community also has developer competitions, developer training certification, developer forums, and developer support centers, allowing developers to experience, communicate, learn, develop, and get support end-to-end in Huawei’s ecosystem.
Many people tell me there are too many activities, and Huawei’s is not missing. I tell them that there are many activities out there, but little solid content, and even fewer valuable people. The value of HDG is not in organizing activities, but in Huawei’s value developers. These people can gather together, generate a sense of belonging, inspire innovative solutions and projects, and create commercial value. This is what really matters.
To let our partners and developers understand what capabilities Huawei has, we released the “Huawei Capability Open White Paper” at the Huawei Ecosystem Partner Conference held in Changsha in March this year. It introduced the capability opening of Huawei’s seven ecosystem circles including cloud computing, IoT, enterprise cloud communication, video surveillance, eLTE broadband trunking, enterprise mobile security, and big data. You can also follow the Huawei Developer Community website and WeChat to download the white paper, and there’s also a lot of content to refer to.
Finally, I’ll end with these three sentences.
“Software eats the world.” This sentence makes me feel quite deeply. Huawei, which has always been making hardware and selling boxes, understood this trend early on. Rather than being eaten, it’s better to embrace ICT digital transformation. The next sentence, rather than saying “open source eats software”, it’s better to say that open source software is what developers need more and is the key means of developing ecosystems. Besides software, even hardware, data, and content copyrights are trending towards open source, such as Open Hardware, Open Data, Creative Commons, etc.
What’s the last sentence? “Community is better than code.” I think what’s more important and many companies haven’t paid attention to yet is “Where does the code come from?” Code is created by people. Where do these people come from? They might be from companies or individuals. For example, 75% of the Linux kernel code is contributed by companies, and 25% is contributed by individuals. There are also many open source projects contributed by individuals. So you need to figure out your ecosystem and product positioning, evaluate what developers you need to introduce to form a community, let the community collaborate with the company, and your ecosystem can possibly succeed and become a weapon for the company. Therefore, I think this is a very important closing statement.
I believe friends present are interested in developer ecosystem building and community operations. Today, due to time constraints, I can only sing a solo. Although we may not be able to chat with everyone after the meeting, I hope to continue communicating with everyone. Here on the left is the Huawei Developer Community WeChat public account, and on the right is my personal WeChat. In addition, if there are Huawei ISV partners present, or you have some possible cooperation projects, please also contact us. The purpose of the developer ecosystem, of course, is to transform into a win-win and mutual benefit for the company and partners. I’m very glad everyone listened to the end of today’s speech. Thank you all again.
Topic: Developer Ecosystem Building, Open Source Community Operations and Governance
Speaker Introduction: Lin Lvqiang
Company Position: Huawei Developer Community Operations Manager
Conference: Global Cloud Computing Open Source Summit
Time: April 19-20, 2017
Location: Beijing International Convention Center
Reprinted with permission: Developer Relations »
