This article is based on my speech at the High Availability Architecture Group meeting. I’ve been a person who’s not good at speaking since I was young, and I always feel nervous during public speeches, unable to fully express my thoughts. I admire people who can speak eloquently during speeches. So I’ve organized my thoughts into this article.
I’m a novice in open source. At the beginning of 2016, I released an open source project called go-commons-pool, a general object pool for golang, which now has nearly 200 stars. I’m also a novice in entrepreneurship. At the beginning of 2015, I started as a technical partner to create a team communication and collaboration tool. In one year, while doing development, I also did some product work and some operations work. I feel that there are many similarities between entrepreneurship and open source, so I’d like to share some insights with everyone. The previous speakers talked a lot about practical content, and my project is technically simple, so I followed Tim’s advice to add more “chicken soup”. :)
Whether it’s entrepreneurship or open source, the first question we face is what to do. Where do ideas for what to do come from? There are no more than two ways:
- Observation Observe the people around you, observe your own life and work, observe everyone’s habits, see where there is room for improvement, see where there are pain points. For example, the idea for my pool came from someone asking a question in a group. I searched and found that golang really doesn’t have a general and easy-to-use object pool. Another example: someone found it hard to get a taxi, waiting on the roadside for a long time, so Uber was born. Someone wanted to sync files across multiple devices, so Dropbox was born. Someone found themselves doing repetitive work at work, so various frameworks were born.
- Learning from others Look at other advanced regions and fields to see if there’s anything to learn from, transplanting achievements from advanced regions or fields to backward regions or new fields. The popular “Copy To China” entrepreneurship is this model, using the development trajectory of advanced regions to predict the future trends of backward regions. The sharing by indigo in the High Availability group that day, predicting China’s trends through Japan’s economic and social development, is also this principle. For my pool, I also analyzed the Java community situation, thinking that golang will play a big role in the server side in the future, and will definitely need a robust object pool for connection pools and other purposes.
After figuring out what to do, the next step is how to do it. At this step, it seems that entrepreneurship and open source are quite different, but there are still commonalities. The key point is to evaluate and arrange the resource investment for the “thing”. Resources include money and time. If the thing you thought of earlier is too big and doesn’t match the actual resources, the result may be that the startup fails, or the open source project creates a repository, writes a readme, and then there’s no follow-up. This tests your ability to evaluate the complexity of things and control resources.
After the project is done, what’s next? It’s how to let your user group know about it, which is now popularly called “promoting” or “sharing”. Huang Dongxu from PingCAP also mentioned their marketing methods and channels just now. The core of this step is to know where your user group’s attention is usually, and how to reach your users at the lowest cost. Open source projects may use various open source communities or technical communities, your own social network, technical conferences, and other methods.
After the initial user reach is completed, users know about your project. Some people may have starred it, and these people are potential users. Others may have forked it, probably preparing to use it or do secondary development. How to maintain current users and attract more users? This is what we need to consider at this stage. Including but not limited to the following aspects:
- Improve documentation and teach users how to use it. Don’t complain about users being “stupid”.
- Respond to user feedback and handle issues. For entrepreneurial products, this means having a customer service system.
Gradually, as users increase, a community is formed and a brand is established. Small tools like mine can’t reach this step, but frameworks like PingCAP’s TiDB and Xie Mengjun’s beego have already formed their own communities and brands.
Let’s summarize the key points in this process:
- The idea is not abstracted well. In fact, all tools and products are doing a kind of abstraction, an abstraction of user needs. For example, in the classic example, when asking users what they need, they will definitely say they want a faster horse, not a car. A car is an abstraction of users’ travel needs. But how to do this abstraction? I’ve summarized three levels.
- DRY principle, don’t repeat yourself. It’s most commonly used in code specifications, advising everyone not to copy and paste casually, but to do some abstraction. But in fact, all advanced features of languages, object orientation, modularization, code generation tools, and various frameworks are solving this problem. In other words, if you find yourself doing a lot of repetitive work, it means there’s a possibility to abstract a tool here.
- Don’t reinvent the wheel. This principle seems controversial, but I think the controversy is not understanding the difference between “invention” and “making”. Don’t reinvent the wheel, but you can make new wheels or improve existing ones. This principle means not repeating the work that others have already completed, not working behind closed doors, but making improvements on the basis of predecessors. I’ve always thought that people who invented the wheel are great and it’s very difficult. Their historical status can be compared to the invention of fire-making. After having the wheel, the tools used by humans are fundamentally different from those used by animals.
- After we’ve done not repeating ourselves and not repeating others, the third level is “don’t let others repeat you”. Share your tools, frameworks, and abstractions as open source products or SaaS services, so that others don’t repeat the work you’ve already completed.
- Development speed is slow, competitors appear, or features are weaker than competitors.
- Promotion is not done well, everyone doesn’t know about it, and as a result, it’s overtaken by latecomers.
- The things made have no actual demand. For example, for the pool, some people think that using channels to simulate in Go is very simple, and there’s no need for a complex pool. For example, many Copy To China projects found that they couldn’t adapt to the Chinese environment.
- No maintenance after open source, no enthusiasm, no response to user feedback, and finally all users are lost. Many zombie open source projects are like this.
Therefore, I think engineers who want to start a business can start with open source, using open source as a practice for entrepreneurship. Experience the entire process from conception, development, to promotion, so that you can have some experience with the key points in the entrepreneurial process and evaluate your strengths and weaknesses. After all, as an engineer, you can control your development time, your users are also engineers, the problems you need to solve are in your familiar field, and the community you need to spread to is also your familiar community. If you still encounter difficulties in such favorable conditions, you can imagine how big the difficulties would be if you switch to an unfamiliar field, unfamiliar users, and unfamiliar community.
Another point about technical people starting businesses. I think Wang Anshi’s poem is very good: “The duck knows first when the river warms in spring”. We front-line coding engineers are ducks in the water, and we will definitely feel the changes in the river first, which is an advantage. If you get promoted, stop writing code, and go ashore, you may not feel the changes in the river.
Reprinted with permission: Developer Relations »
