【2014】GitHub China Developer Annual Report

[[127311]]

Produced by GitHuber.info team

Preface

I don't know when GitHub became a trend, and you'd feel embarrassed to say hello to people on the street without a few stars. Since we created GitHuber.info, we have access to a lot of GitHub data. With the advice of @Python enthusiast, we decided to crawl and analyze the data ourselves and make a report to let everyone have a more specific understanding of the current situation of Chinese developers on GitHub.

Currently, the number of registered users on GitHub has exceeded 10 million. For accuracy, we captured the personal information of all users and screened out all Chinese developers, Chinese organizations and American developers, and American organizations, and then captured all their public project information for analysis.

The content of the report is divided into three parts. The first part is the current situation of Chinese developers, the second part is the comparison between Chinese and American developers, and the third part is interviews with outstanding domestic open source project authors.

The first part counts Chinese developers from three aspects: personal information, project information, and organizational information. Since the amount of data is long-tail, we merged similar intervals to make the chart more readable.

The second part also compares Chinese and American developers from three aspects: personal information, project information, and organizational information. We hope that this will help everyone better understand the similarities and differences between us and American developers.

In the third part, we interviewed several authors of excellent domestic open source projects. We intentionally selected different types of projects so that we can show different development paths of open source projects and let different types of developers gain something. At present, the domestic open source environment is still in its development stage, and there are still many aspects to explore. I hope to use this as a starting point to encourage everyone to think deeply about open source.

Since this is the first time we have made such a report, and there are some time and equipment limitations, we have not been able to produce all the report content and presentation effects we expected. However, as you can see from the title, we will continue to do this report. There are too many failures, and this one is not a big deal. But what if it succeeds, what if it brings some value to everyone? You still have to try what you want to do.

This is version 1.0. We will continue to improve and update the content based on your feedback. Therefore, we very much hope that you can put forward various opinions and suggestions. You can use any one of WeChat, Weibo, email or website. We will record them all.

I would like to express my sincere gratitude to Junqing Luan and Xia Tianhan. As members of the GitHuber.info team, everyone has contributed so much to this report. I would like to thank all the authors who were interviewed for taking time out of their busy schedules to patiently answer our series of questions. I would like to thank all the consultants for providing many useful suggestions for this report. Although not everyone speaks up, even as an audience, they have given us endless motivation. I would like to thank He Bin for assisting in data mining. Finally, I would like to thank each of you who read the report. The report itself is worthless. It is your attention that injects energy into it and allows it to shine. Thank you, thank you everyone!

Liang Jie

2015. 1.29

Chinese developer statistics

personal information

The two pictures above and below show the active time periods of programmers in China. The legend on the right shows various events on GitHub. The highest gray is Push, and the second highest orange is Watch. It can be seen that the activity is the lowest on Saturdays, and the activity on Sundays is higher than on Fridays. There are three peaks of activity every day: morning, evening, and midnight. The highest peak is midnight, which shows that everyone is a night owl.

Polyrabbit has used 129 languages ​​because his project polyglot contains a corpus of programming languages, which collects code snippets in various languages.

Since projects may include third-party libraries, the number of languages ​​counted will be slightly higher than the actual number of languages ​​used. However, even so, there are still many people who master multiple languages.

We use bytes instead of lines because that's what we get from GitHub's API, and we think bytes are more accurate than lines.

It can be seen that the total amount of code of most developers is concentrated in the range of 100,000 to 1 million bytes. You can count the amount of your code here to see which range it is in.

The difference between forking and not forking is huge. After removing forks, the number of forks basically drops by an order of magnitude, which shows that everyone likes forks. In our understanding, forking means that you want to submit code to the project. If you just want to pay attention, a star is enough. Forking a project will interfere with viewing your own project.

The friend who forked the most has more than 8,000 projects. It’s hard to imagine what it’s like to open your own project list. You can go and experience it.

The number of followers of most developers is less than 10, and it is extremely rare to find developers with more than 1,000 followers. Facts have proved that mutual following can only reach the third level at most, and to reach the fourth level, you must have excellent open source projects. GitHub is a place where code speaks.

Star counts show that most developers have less than 500 stars. Stars are like favorites, too many contents will affect the use. There are already some good Star project management tools, such as Oh My Star, which can help you fully utilize the value of Stars.

What is the value of following? It seems that you can see what the masters are doing every day. However, as a social platform for programmers, GitHub seems to be a little heavy in terms of interaction and is not as easy to use as Weibo. Using GitHub's API to implement a mobile version is a good choice.

Project Information

The code size of a single project is mostly concentrated in the range of 10,000 to 100,000 bytes. Most front-end projects are short and powerful, which may be related to this. Later, we will count the distribution of project code size in different languages ​​to see how cumbersome each language is.

In terms of branches, most projects have less than 3 branches, which reflects that most projects are still purely personal development and have not reached the level of requiring standardized branches. As the project continues to expand, branch management will become a very important part.

The distribution of PRs and issues is not surprising. 90% of the projects have almost no PRs and issues. We also discussed this issue when we interviewed Li Chengyin. Feedback is very important for an open source project. Even if you are not able to raise PRs, you can try to raise issues to make the project better and better.

Organization Information

The overall distribution trend of the organization part is very similar to that of the project, but the statistics are slightly worse than the project information in terms of proportion. It stands to reason that the projects in the organization should be easier to attract members to participate, so as to have better performance in PR and Issue. On the other hand, the current Chinese organizations have not fully played their role and have not promoted the development of open source projects. At present, the excellent open source projects in China still rely mainly on the cooperative development of offline teams, which is still a little behind the crowdsourcing model of American open source projects.

#p#

Comparison between Chinese and American developers

Personal comparison

The order from top to bottom in the legend on the left side of the figure is the ranking of languages, and the clockwise direction in the pie chart is also the ranking of languages.

It can be seen that JavaScript and CSS are in absolute advantage, and the two together account for nearly 1/3. The biggest difference between China and the United States is Java and Ruby, and the rankings of these two languages ​​are almost completely symmetrical. It is not surprising that Java, a popular language in China, ranks at the top, but another popular language PHP is not at the top, and its usage rate is even lower than that of PHP in the United States. It seems that domestic PHP enthusiasts are not very keen on open source.

On the right is a comparison of personal statistics between China and the United States. The distributions of China and the United States are very similar in the first and third figures, but there are slight differences in the second and fourth figures. In the first interval, China's proportion is smaller than that of the United States, while in other intervals, China's proportion is larger than that of the United States.

The first interval is for inactive users, and we can see that the proportion of inactive users in the United States is larger than that in China. From the second interval onwards, there are active users, and the proportion in China is larger than that in the United States.

The reason for this is that there are a large number of developers in the United States. We filtered out about 67,000 Chinese developers, while there are about 360,000 American developers. In this case, it is understandable that the United States has a larger proportion of inactive users. An increase in quantity often leads to a decrease in quality. I hope that when the total amount is equal, we can still lead in proportion.

Project Comparison

On the left is a comparison of project statistics between China and the United States. You can see that the comparison results of the three pictures are very similar: in the first interval, China's proportion is greater than that of the United States, and in other intervals, China's proportion is often much smaller than that of the United States.

The comparison results in the following figures show that the number of active projects in the United States is greater than that in China in all aspects. Starting from the second interval, the proportion of the United States can be up to three times that of China, which means that the absolute number ratio is more than ten times.

In general, the United States is slightly weaker than China in terms of personal information, but stronger than China in terms of project comparison, which shows that the activity of active users in the United States is indeed much higher than that in China.

The comparison of code volume is quite special. We have counted about 220,000 projects in China and about 1 million projects in the United States, which means that the vast majority of codes in the United States are concentrated in the second and third intervals, and the number is much larger than that in China.

In terms of the number of branches, the comparison between the United States and China is not much different. However, the number of branches is more concentrated in the second interval. We have said before that an increase in quantity often leads to a decrease in quality. From this perspective, we are currently at a disadvantage in both quantity and quality, and we need to continue to develop.

Organizational comparison

We are slightly inferior in terms of organization. We counted 2,500 organizations in China and about 25,000 organizations in the United States, which means that the number of organizations in the United States is ten times that of China. The number of people is four times that of China, but the number of organizations is ten times, and the various indicators of the organization are also stronger than those of China, which shows that the overall form of the organization in the United States is very good.

Comparison of average values

#p#

Interviews with authors of outstanding domestic open source projects

ECharts

G: Please introduce yourself.

Lin Feng: Lin Feng, Open Source China @Kener-林峰, GitHub @kener, Weibo @Kener-林峰, Baidu Business Front-end General Technology Group, Data Visualization Direction Leader, Senior Front-end R&D Engineer. Likes design, loves programming, ZRender, ECharts author, currently focusing on data visualization research.

G: Can you briefly introduce ECharts and its application scenarios?

Lin Feng: There are many data visualization products. ECharts is positioned to meet the needs of reusable commercial data visualization. It is at the same level as the existing Highcharts and FusionCharts in the industry. Of course, they are all mature commercial paid products. We have opened it for free, but we are just starting out, and there is still a big gap in perfection. But I am not modest to say that ECharts' highly personalized and interactive capabilities have become the industry leader in many aspects. Drag-and-drop recalculation and large-scale scatter plots have obtained national patents. Data views, value range roaming, and sub-map modes are also the first in the industry and unique functions. As for the application scenarios, they are relatively broad, and different industries have various needs. There is no need to say much about the Internet. Report systems, operation and maintenance systems, and website displays can basically be used as long as there is a need for data display. Like the media, data news has also been mentioned more and more in recent years. Caixin.com is very advanced. They are the first to use ECharts as a visualization tool for data news. In fact, all walks of life have various application scenarios such as marketing display, corporate brand promotion, and reporting and analysis of operating income. Regardless of whether big data is over-hyped, data has indeed become one of the most valued assets of many companies, and wherever there is data, there will basically be demand in this regard.

G: How did you first come up with the idea of ​​developing ECharts?

Lin Feng: When I joined Baidu, I was assigned to a product that was very important to the company: Phoenix Nest System. After more than two years of hard work, I went from a rookie to a senior rookie, and became the technical leader of Phoenix Nest front-end. I dealt with all kinds of data all day long and began to understand the value and power of data. It was the end of 2012, and the term big data had just surfaced. Data visualization was not popular (at least in China). Boss Steve Jobs did not allow Flash to run on the i series, and HTML5 began to become popular. We needed to find a solution for the visualization of Phoenix Nest system data reports, the visualization of Phoenix Nest system user experience monitoring data, etc. The combination of programming + design + data seemed to be tailor-made for me, so I turned to the research of data visualization. After returning, Erik, the leader of Baidu's front-end, formed a general technology group for the commercial front-end and deliberately planned the direction of data visualization. It was natural for me to switch from the role of Phoenix Nest technical leader to my current role, and then I dug a very deep pit (ECharts function design), and then I started to fill this pit little by little with the team in the past year.

G: ECharts has developed into the best domestic open source project. Everyone must be curious about how ECharts has come to where it is today. Can you talk about this process? What events have impressed you the most?

Lin Feng: I don't dare to claim the title of the best. I just keep doing something that I am interested in and that is valuable to the company and the field. This is the 19th month of ECharts. I habitually check the number of stars of ECharts every day, and record it every time it reaches 100. It seems that it has been integrated into my life. Thanks to the trust of the leaders, most of our team can work as we please. We don't have to worry about checking in. We can go out for exchanges or even go to an exhibition to be influenced. If you like, you can stay in a cafe for a day. The freedom given by this trust does not reduce working hours or reduce efficiency. I believe that the partners in our team have long been accustomed to working anytime and anywhere (restaurants, subways, airports and even hospitals). The key is that everyone is willing to work spontaneously. Perhaps this is also the factor that has created many imaginative features of ECharts. I can't count how many masterpieces created by my partners suddenly popped up in hi late at night (we have already exhausted the words to flatter each other), and I have forgotten how many times I got up in the middle of the night to write code because of sudden inspiration. Programming itself is a creative job, not to mention that we do it in combination with art. If you don’t really like it and just treat it as a nine-to-five job, you won’t be creative.

I am very grateful to everyone who has accompanied ECharts all the way, including Shen Yi, Zu Ming, Dong Rui, Su Shuang, Hong Qi, Yang Ji, Ding Ding, Huang Yue, Tong Bing, Tai Yun, Zhou Yang, Shi Wei, Hu Yao, Senior Brother Decheng, General Manager Li Zhan, General Manager Zhi Min, Teacher Chen Wei, etc., and of course, you may also be included. All the impressive events are also related to you. The Weibo post of ECharts 1.1.0 was our first Weibo post to be forwarded more than 500 times (luckily we were not arrested). After 1.3, we were praised as "a rising star in the field of visualization" and appeared in major mainstream technical media, and won the top 10 popular open source projects in China that year. After 1.4, there are already three versions of ECharts in different programming languages. Why ECharts was shared at conferences such as R language and database. On the eve of 2.0, we put a poster on the electronic screens of the company saying "Charts that are better than ECharts are coming soon", which attracted many friends who care about us to "support" us. It was a big surprise. After the release of 2.0, we were on the headlines of almost all the big V public accounts related to big data on WeChat. This was a challenge and transcendence we launched against ourselves. On June 30, 2014, we held the first birthday party for ECharts, and since then we have the image of a little whale. After 2.0, our team launched Baidu Tushuo, an application based on ECharts, and started public testing. We have shared it countless times in various activities and companies in Beijing, Shanghai, Guangzhou, Hangzhou, Wuhan, Harbin, and Xi'an. We also took the little whale to Silicon Valley to let American students know how powerful we are. We went to Guangzhou, and we stayed up all night in the hotel to prepare for the sharing the next day, and officially released Tushuo. What made us happy was that it was on the headlines of Guangzhou Daily the next day. 2.1.8 ECharts' English official website was finally launched, which also started our internationalization journey. We became the first and only open source project in China to be selected into the GitHub Explorer Data Visualization section. Just 2 months later, Jaroslav Benc brought Datamatic ECharts edition (English version of the picture description), which made us feel more pressured. Foreign (here is a respectful title) programmers are too NB! Log in to the GitHub hot list, the star exceeds 5,000, Baidu popularity, knowledge graph, World Cup and other cooperative projects are launched, etc. Looking back, there are too many memorable moments. Thank you for being there.

G: What problems is ECharts currently facing? What development plans are there for the future?

Lin Feng: For our own project upgrades and maintenance, the code size and feature function coupling in the main module are the biggest problems. We need to further break it up and split it into more fine-grained parts to provide dynamic and on-demand assembly capabilities.

For developers to develop projects, more detailed and friendly documentation and help, I think I should make some tutorials (I have been planning it for half a year...).

For chart readers, ECharts 2.2 has done a lot of work on mobile device optimization, artistic aesthetics, and big data performance response. ECharts-m (ECharts Mobile) will be available soon. I will keep the rest of the news a secret for now, and soon you will see a more interesting ECharts.

G: ECharts must have encountered many difficulties during its development. How did you overcome them?

Lin Feng: There will always be an unfinished task list. This is what I have been mentioning since I wrote ECharts. I used to be extremely skeptical that I would never be able to clear this task list, but now I am convinced of it -_-.

Whether it is a team or an individual, the ability and time will always be limited in a certain period of time. There are many things that can and should be done. You can and should collect as many requirements and feedback as possible, but you must learn to distinguish which are real needs and which are false needs or even unreasonable needs. Don't be swayed by users, learn to do subtraction, and maintain your own rhythm.

In addition, many people see anything from Baidu and start with a sentence like "Whatever Google has, Baidu produces", regardless of whether it is good or bad, and then add "It's obviously a copy of xx, it's weaker than xx". At first, I politely replied to them that ours is different, with features and so on. They will continue to find faults. If they can't adjust it, they will blame the documentation. If it doesn't meet their expectations, they will say there is a bug. Later, I found that there is no need to waste time serving them. Just do your own thing, be patient and let them do what they want. When you do your job well, they will slowly shut up. If they really need ECharts, no matter how badly the documentation is written, they will find it themselves or ask through various channels sooner or later.

This may have neglected some people, but I later realized that focusing on more important things is responsible to more people. In the words of Zu Ming, this is "the responsibility at our fingertips."

G: Can you summarize the development model of ECharts? For example, starting from interest and then getting company support, or being supported and operated by the company since birth, etc. If other developers also want to follow this model, what do you want to say to them?

Lin Feng: You can read for yourself how ECharts came about. I am very lucky. This is my own interest and also the need of the company. I met many good leaders who let me give full play to my abilities and provided continuous support and help when things got bigger and bigger.

To complete a project, the most important thing is the power of the team. You need to find like-minded and talented partners to work with you. The ECharts team is a cross-departmental virtual organization. We recruit all FEs in Baidu. When we formed the team, I set a rule: "If you are busy or don't have time to do this, please leave temporarily. We welcome you back at any time." In the first few months, I cleared the site every two weeks, and there were many people coming and going. But after half a year, the team was basically stable until now. In Ding Ding's words, we have become a small family.

G: Finally, let's talk about open source. What do you think is the significance of open source for most ordinary programmers? We have all heard of open source and GitHub, but just like those big principles, they are often not combined when we actually do it. How do you think programmers should make full use of GitHub?

Lin Feng is so meaningful, learning! It is a kind of happiness to read the code of experts. From imitation to understanding and integrating into your own program, this is growth. Many experts around me regard GitHub as an amusement park or a toy store. It is not a child's play, but you need to have a player's attitude and enjoy the joy of playing. You need to learn to toss on it. There are countless good projects on GitHub. Do more hands-on, toss more, try to integrate into these open source communities and make some contributions. At the beginning, even if you just join in the fun with the issue, give some feedback, and correct typos in the document, it is meaningful. Then contribute your own ideas and help others solve problems. When you start to contribute code, maybe you can realize the meaning of open source to you.

G: In 2014, many excellent open source projects emerged in the domestic open source community, and most of them seemed to have the involvement of companies. This is also similar to excellent open source projects abroad, where programmers from large companies are often the core contributors. What role do you think companies play in open source projects? In the current domestic environment, how can you create a successful open source project in a company?

Lin Feng: For the company, it is both a contributor and a beneficiary. The company will not start a project that is irrelevant to its own business or that it cannot use for no reason. A good project can get more attention, feedback, and code contributions. If the project can be developed better after open source, it will not only be meaningful to the company's own project needs, but can even allow the company to establish its own technical leadership in a certain field (think about Android, Linux, jQ, Bootstrap), which is undoubtedly a great thing for the company.

Whether a company can run an open source project depends on the company's situation and genes, which is hard to say. I can only say that when doing an open source project within a company, the key is whether the project itself brings value to the company, both in the short term and in the long term.

PS: We are still far from success, so it is not time to share our success experience yet.

ThinkJS

G: Please introduce yourself.

Li Chengyin: My name is Li Chengyin, and I have been working for 7 years. I used to work at Baidu, and now I work at 360. I don’t know what I will do in the future. I used to work on the backend, but now I mainly work on the frontend and Node.js. What I want to do and have been doing is engineering, tooling, and process-based things, hoping to improve the team’s development efficiency.

G: Why develop ThinkJS?

Li Chengyin: When I used Express, I felt that the framework's functions were limited and that it was not possible to quickly implement specific business needs. In addition, the asynchronous writing method of Node.js itself was not easy to write or use. In addition, I had used ThinkPHP before, so I wanted to develop a similar Node.js framework that used Promise.

G: How did ThinkJS develop?

Li Chengyin: I started it as a hobby, not as a project. In April 2014, I found that many people in and outside the company were using it, and everyone really had such a demand, so I continued to work on it and made it a formal project of the department. On September 22, 2014, 1.0 was officially released, marking ThinkJS as a formal development project. Before 1.0, it mainly realized some of my personal ideas, but as a formal project of the department, the department will have more time and manpower to invest, and will also consider merging some PRs.

G: Why did ThinkJS decide to adopt open source form?

Li Chengyin: Actually, companies now encourage open source for things that do not involve company secrets. For the front-end, the code cannot be hidden. Since it cannot be hidden, why not open source it and embrace it with a better mindset. This is actually the reason why there are the most front-end projects on GitHub. Although ThinkJS is a back-end framework, because we have such a mindset, we naturally decided to open source it when we first started.

G: What does open source bring to ThinkJS?

Li Chengyin: Open source can bring more users, so that we can discover more problems and needs that we cannot find through internal use, so that the project can develop better. In addition, open source projects have a great improvement effect on the team and the maintainer itself. In addition to technology, there are many things to do in open source projects, such as writing documents, communicating with users, etc. These things will actually exercise many important abilities. In the long run, it is very beneficial for the personal development of developers, and it will be effective when doing bigger things later.

I also don’t like writing documents, because I have to update them when the code changes. But in fact, many users only read documents and not the code, so the quality of your documents directly affects the difficulty of getting started and the effect of using the project.

G: Has ThinkJS received any help from the company, such as promotion?

Li Chengyin: ThinkJS is actually open sourced in the form of a department, not a company. The advantage of doing so is that it is more free and not particularly closely related to the company, which is a good thing for the development of the project itself, because if the relationship between the project and the company is very close, once the project leader leaves, the project is likely to be unable to continue to develop. Although doing so may reduce some support from the company, it is more beneficial to the development of the project in the long run, and the main support comes from the community.

G: How did ThinkJS transform from a personal project into a formal project of the department?

Li Chengyin: There are two main reasons. On the one hand, some people were already using ThinkJS at the time, and we saw the actual effect of this project. In addition, Node.js was becoming more and more popular, so we thought this project had a good future development prospect, so it became a formal project of the department. This is actually a very natural process. If a project based on personal interests is recognized by everyone in actual use and has great potential, it is very likely to be recognized by the department.

Relatively speaking, product-based projects are more likely to be recognized because they are more likely to show results, while technology-based projects are sometimes difficult to count, as some companies do not disclose the technologies they use. But in general, as long as a project can demonstrate its own value, it can easily become a departmental project.

G: What do you think of the current situation of open source in China?

Li Chengyin: Currently, most domestic open source projects are developed internally by the team. Even for very successful projects, there are very few PRs. Therefore, the domestic open source environment is still not active and open enough. A project will be criticized by many people, but the key is that we don’t know that others have criticized us, so we can’t improve. We think that criticism itself is not a bad thing. It means that users still need your project, but the project is not good enough. But the key is that the criticism should also be made in the issue, so that we can see it. In general, the domestic open source environment is better than before, with more issues and some PRs, but it is not mature enough at present, and it cannot complete many functions through PR like foreign projects.

Actually, we can't blame everyone. The working conditions in China and abroad are different. People abroad treat programming as a hobby, and work is not as busy as in China, so they have more time and interest to invest in open source projects. In China, people often work overtime and are under great pressure, so people are not very enthusiastic about open source. They treat open source projects as a treasure trove. When encountering problems, they look for ready-made solutions instead of participating in them.

In addition, there is another reason why people prefer to use foreign open source projects, which is that foreign projects are more stable and less likely to be unmaintained. Domestic open source projects sometimes have developers give up and stop updating, which makes it difficult to deal with projects that rely on these projects. However, even if the maintainer of a foreign open source project stops updating, he will find someone else to continue maintenance, such as Express some time ago, which makes users feel safe.

Cocos2d-x

G: Please briefly introduce yourself.

Lin Shun: Lin Shun, co-founder of Cocos2d-x, has loved playing games since he was a child. He is a Blizzard fan and a die-hard fan of StarCraft. He recently fell in love with Heroes of the Storm. He likes to write code without being disturbed and likes digital electronics.

G: Everyone must have heard of Cocos2d-x. To be honest, when I first heard of it, I thought it was an open source project from abroad. Later, I was surprised to learn that it was developed by Chinese people. Although Cocos2d-x is already very famous in China, most developers who have not been exposed to games may not know much about it. Can you introduce Cocos2d-x and the entire product line extended from it?

Lin Shun: Cocos2d-x is a professional cross-platform mobile game engine that uses the MIT protocol. Since the first line of code was submitted to GitHub in July 2010, it has been completely open source and free. It currently has a market share of over 25% in the world, and over 70% in China. More than 400,000 developers around the world are using this engine to develop games. X stands for Cross, which provides cross-platform support for developers. Game logic can be compiled once in C++ language and run on iOS, Android and more mobile platforms, and the running performance is the most efficient. In early 2012, Google sponsored the Cocos2d-x team to create the Cocos2d-html5 branch, and completed the development of the JSB (JavaScript Binding) product with the help of Zynga, realizing the one-time development of JS script games, which can not only cross all platforms originally supported by Cocos2d-x, but also be published to the Web.

Currently, the tool chain of Cocos2d-x has covered the entire process of game development from new projects to game SDK access and packaging and release. The integrated development tool Cocos Studio supports rapid prototyping and verification. The debugging script code and application packaging use Cocos Code IDE, and AnySDK can quickly and efficiently access a large number of channels. In addition, the Cocos community also has Cocos Play and Cocos Runtime to achieve the click-to-play effect of the game and improve the game conversion rate. In 2015, 3D and 3D editors will be the development focus of Cocos2d-x. Adhering to the advantages of the most efficient and smallest size, it provides more powerful 3D functions and supports users to use the 3D version of Cocos2d-x to create excellent 3D game works.

G: Cocos2d-x should have been a project operated by the company since its inception. Why did the company initially choose to make a game engine, and how did it decide to open source it?

Lin Shun: Cocos2d-x has been completely open source and free since the beginning. At that time, the goal of the Cocos2d-x project was to provide game content for the operating system company where Wang Zhe and I worked. A new operating system and a new ecosystem, without good game content, is not high-end at all, but lonely at the top, so we developed Cocos2d-x, a cross-platform development tool, so that developers can quickly publish games to iOS and Android at a low cost. Finally, they can import game content into our operating system with a simple editing process, so as to achieve zero gap and simultaneous import of the best game content.

G: Currently, there are already a set of mature companies participating in or even leading open source in foreign countries, but this is still a relatively new concept in China. The uncertainty of open source itself and the controllability required by companies should be contradictory. How does Chukong Technology deal with this contradiction?

Lin Shun: There is no big contradiction between uncertainty and controllability in open source engines. The goal is to improve efficiency, reduce costs, and better serve commercial game development.

The advantage of an open source game engine is that it can get the most direct needs from the community, be down-to-earth, and drive the product to develop rapidly in the right direction; community code contributors can also share their achievements together, thereby accelerating product upgrades. The development of Cocos2d-x is inseparable from the promotion of the "Fishing Master" series of games by Touch Technology. "Fishing Master 1" is based on Cocos2d-x v1.0. All the technical pitfalls of the engine were first overcome by the fishing game. The adaptation and performance optimization of various domestic exotic models are also verified based on the Fishing Master.

G: The entire Cocos2d-x product line has grown to its current size and popularity. What role do you think open source has played in this?

Lin Shun: Open source plays a decisive role in this. First of all, the demand-driven model of the open source community provides us with the best demand reference. Secondly, more than 300 outstanding engineers from all over the world contribute code to the engine, which is an inestimable wealth. If it were not for the open source model, I believe no company would allow so many outstanding engineers to contribute code to the same project. Finally, the open source and free model allows more people to benefit from it, and their word of mouth has created today's reputation and user base for Cocos2d-x.

G: Everything has its pros and cons. What do you think are the advantages and disadvantages of company-led open source projects compared to individual or community-led open source projects?

Lin Shun: The advantages of open source projects supported by companies or capital compared to open source projects without capital: more resource investment is crucial to the later development of open source projects. It allows more full-time R&D personnel, and the iteration cycle and quality of the product can be well controlled, providing more sustainable and long-term maintenance, which can make open source products go higher and further. As for the disadvantages, it depends on the attitude towards open source projects. If we promote industry upgrading in the service industry and use an open mind to do open source projects, there will be no disadvantages. There are also many open source projects supported by various companies around the world. At that time, our operating system company was not doing well, but the engine project was developed very well. There were several willing to invest in us. But in the end, I still felt that Chen Haozhi had a very open mind and could insist on not making an open source project a closed source commercial project. Finally, he worked with him. Along the way, he found that our original choice was the most correct.

G: If other companies also want to take the open source route, do you have anything to say to them?

Lin Shun: We are very welcome to join the open source route. Open source projects can learn a lot of valuable knowledge, whether for individuals or companies. The wisdom collected in the community is huge and valuable. Foreign senior programmers teach you two tricks and you will find that the original code can be written like this and the framework can be designed so elegantly. In addition, interacting well with the community and effectively collecting user needs and feedback is the key to promoting the development of open source projects in the right direction, and it is also a shortcut to productization and ease of use.

G: Finally, let’s talk about open source. What do you think open source means to most ordinary programmers? How should programmers make full use of GitHub?

Lin Shun: Participating in open source projects is an efficient and rapid learning method for programmers. Not only that, if you are a technology enthusiast, you may find your own interests and good at combining points in open source projects. Of course, it would be even more exciting if you can find a combination point with business and then do your favorite job, which is rare.

Generally, orderly open source communities provide a good platform for exchange of knowledge and experience. In-depth participation in open source projects will be of great help to individuals' technical growth and vision.

GitHub is popular around the world without having to do many tables. It provides a very efficient project development collaboration mechanism, which is a good entrance to understand the operating mechanism of open source projects. On GitHub, developers can share code with people around the world at any time, and allow people from different places around the world to contribute various ideas and code snippets, which is also the basis for community communication. More and more open source projects are migrated to GitHub. Finally, you are welcome to join the Cocos2d-x open source project community to become a part of our community and realize your game dreams.

Pen

G: Please briefly introduce yourself.

Xiaoyu: Everyone calls me Xiaoyu. Most websites that require ID are called sofish. After graduating from law school, I kept writing codes.

G: You have done many open source projects, so let’s talk about Star at most Pen. There are many related projects in Markdown, but this is indeed the first time I have seen a project like Pen. Let’s briefly introduce the purpose of Pen.

Xiaoyu: Pen is a visual (real-time compilation) editor that supports Markdown.

I wrote Pen because I thought that the experience of posting by Baixing.com users should be better. GitHub had a ZenPen project that was very popular at that time, so I was ready to use it. However, the code coupling of this product is too high, and CSS/JS cannot be separated, and I cannot customize the functions. I felt that it was very useless, so I had to write it myself. The goal is to edit the same as the results released, the real WYSIWYG, and supports custom functions, and CSS/JS is also easy to separate. Some of the syntax of Markdown is relatively concise, so I directly supported it. At that time, when I was on Trending, the GitHub employee gave a very powerful PR, supporting the display of Markdown.

However, I felt it was too troublesome and was not integrated into the product, so I didn't update it. Until Teambition was used, Yan Qing contributed a lot of code and solved many hidden bugs.

G: How did you think of doing a project like Pen? What interesting or impressive things during the process? Share it with us.

Xiaoyu: As mentioned above, the direct reason is work needs. Most of my open source projects, except for Typo.css, are directly because they want to abstract some functions in their work into modules and open source along the way. For example, the earliest AliceUI has been used on Alipay on a large scale before it is open source. To be impressed, I think open source projects must be used on a certain product, especially commercial projects, so that they can become truly useful, because both open source and closed source require the motivation to ensure quality, and work is one of the motivations. Any open source project that is not really used on commercial products must be used with caution, and it is not good.

G: How did Pen get so many Stars? Have you done any related promotions?

Xiaoyu: No, I just posted on Weibo and V2EX, and then many people followed it.

G: As a top ten developer in China, you should be very busy with your daily work. How did you complete the Pen project under this situation?

Xiaoyu: I am busy at work, but I don’t have time at all. The busiest stage in my life seems to be in the first 6 months of writing this sentence. Because I have to bring people while making products, I usually go home after 10 o’clock, so I have not produced much recently. Except for m.ele.me, it has been online, and there are no open source projects. Compared to thinking about what Pen should be and what level of experience it should be, writing Pen is not much time, and 300 lines of code is not difficult for me. Let’s talk about it, ZenPen should be at the level of thousands of lines at that time, but its functions are not as good as Pen.

G: Do you think it is difficult to develop and maintain an open source project as an individual developer? Are there any times when you want to give up?

Xiaoyu: The difficulty depends on the project. But I believe that many people may not solve the problem, because technical problems generally have ceilings. For core ideas and technologies, in most cases, the core technologies should be produced by fewer people. If the ideas are determined, the core technologies are determined, adding functions may not be as difficult as imagined. And for whether to give up, I usually think this way, and the worst thing is to give up. There will be many beautiful things happening when persisting, such as writing a blog. If there are many important things and there is not much time, sometimes I can only give up and only do what I think is important.

G: What is the essential difference between purely personal development open source projects and open source projects with company background? How should a developer choose?

Xiaoyu: In essence, they are all open source. I have never counted that personal open source things are more successful, or that company open source things are more successful. However, most codes like ElasticSearch are written by one person, which is very successful; Docker is maintained by a company, which is very successful; Bootstrap is developed by two people, which is maintained by the company, which is very successful. In essence, I think that open source products are really useful, and people will use them; if there is a company that provides time and money support, it is quite good; and the best thing is to have a community that everyone can maintain together. For example, you can find almost all the answers about jQuery on Google, which is the power of the community. So if you have a good project, then try to cultivate a community, which is better than writing by one person, or zombie projects that only the company supports no one to develop.

G: If someone also wants to take the purely personal open source route, do you have anything to say to them?

Xiaoyu: Making a useful product is more interesting than whether it is open source or not, and whether it is personal. If possible, please only produce something that makes the world better.

G: Finally, let’s talk about open source. What do you think open source means to most ordinary programmers? How should programmers make full use of GitHub?

Xiaoyu: Open source is a spirit of sharing. There may be many meanings. Benefiting others, getting feedback on improvements, and letting more people know you from code, and so on. Open source has not directly changed my life, but I like writing code and can help people. It is already a great pleasure for me, and having fun is my meaning.

For GitHub, it is just a work/collaboration platform, and there are more options for such a platform. But I have always used it because other products are too ugly, whether it is details or experience, and I prefer to choose a useful tool, even if it is paid.

Vue.js

G: Please briefly introduce yourself.

You Yuxi: My name is You Yuxi. I am currently working in a startup company, Meteor, and I do the development of a full-stack JavaScript framework. Previously, I was at Creative Lab in Google New York, mainly responsible for HTML5 interface prototype development.

G: There are many frameworks for MVVM now. Is there anything unique about Vue?

You Yuxi: Compared with other MVVM frameworks, Vue has two main features: 1. Native JS objects are models; 2. Component-oriented development model. Others are lightweight, less invasive, and easy to get started.

G: How did you think of doing a project like Veu? What interesting or impressive things during the process? Share it with us

You Yuxi: It was initially because during the process of prototype development, a lightweight and simple framework was needed to improve development efficiency, but there was no framework that met my needs at that time. I studied Knockout, Angular and Ractive, but they each had their own differences: Knockout cannot be used as model with native JS objects. Angular is too large and there are many things I don’t need. Ractive’s API is most in line with my aesthetics, but it did not have a component system at that time. Another thing is that when I was looking at the source code of these projects, I thought the implementation of data binding was very interesting, and I wanted to write one by myself to deepen my understanding. The whole process was actually quite random. At the beginning, I didn’t have any plans, just tried to write it bit by bit, and the internal design was revised countless times, and it was completely rewritten to 0.11.

G: How did Vue get so many Stars? Have you done any related promotions?

You Yuxi: When Vue was first released, it was mainly through some foreign software development news aggregation sites, such as HackerNews, Reddit, and some front-end development blogs/newsletters. In fact, it was just posting a link to see luck. After that, it was not done deliberately except maintaining an official Twitter account. I think whether the personal open source project can gain long-term attention is very important. Whether the wave released at the beginning can generate a good momentum, and the subsequent growth is basically natural. At that time, Vue was posting to HackerNews and was pushed to the homepage. This may be the most critical opportunity, because the traffic and attention brought by HN were really great, and the audience was all developers. On the other hand, I have also put a lot of effort into Vue's document sites. Good documents show the sincerity of the developer, and the first impression is also very important.

G: It takes a lot of time and energy to build a framework. How do you arrange your time to achieve it?

You Yuxi: It really took a lot of energy. For a while, I spent almost all my spare time on it. Of course, because Vue is also used in some projects at work, there is also a reason to allocate some during work. I actually have a bit of cyclical work in Vue. I may have a few months of special investment to achieve some major improvements, and then I will have several months of focusing on other things, and just change bugs to Vue.

G: Do you think it is difficult to develop and maintain an open source project as an individual developer? Are there any times when you want to give up?

You Yuxi: It depends on the scale of the project. Generally speaking, projects suitable for personal maintenance are best to focus on solving a library of smaller specialized problems, otherwise it may take up too much energy. After the project is large enough, it is best to maintain it by the community or team. To be honest, Vue's current issue growth rate is already quite tiring. Fortunately, many community developers are actively helping to answer questions, which saves me a lot of energy.

G: What is the essential difference between purely personal development open source projects and open source projects with company background? How should a developer choose?

You Yuxi: Open source with a company background is definitely driven by commercial interests, so as long as the company's business interests are positively related to the development status of the project, the project will have relatively stable financial and human support. However, such projects are usually more affected by company decisions and are not as sensitive to the community as those developed by individuals. I personally think whether it is an individual or a company development is not the key when choosing a project. The key is to see whether the company/individual behind it is reliable.

G: If someone also wants to take the purely personal open source route, do you have anything to say to them?

You Yuxi: I think that because of my limited energy in personal open source, I need to focus, and I also need to have a clear understanding of the positioning of the projects I have done to ensure that what I have done does indeed solve a pain point, so that the energy spent is meaningful.

G: Finally, let’s talk about open source. What do you think open source means to most ordinary programmers? How should programmers make full use of GitHub?

You Yuxi: I think the meaning of open source is naturally the most important thing for ordinary developers to read other people's source code. Using advanced search on GitHub to search for projects and developers whose language is at the forefront. In addition, you can also find a lot of good things when looking at new trending projects every week. On the other hand, it is also beneficial to open source your own code as much as possible, because this can force you to maintain a high level of requirements for your own code instead of just being able to pass it.

Participants

(Ranked by last name)

Team Members:

Liang Jie, Luan Junqing, Xia Tianhan

consultant:

Hu Shaoyang, Li Jing, Li Songfeng, Li Tao, Lin Feng, Lu Junxiang, Ruan Yifeng, Tang Qiao, Xiangma, Zhou Yubo, justjavac (Midu), sofish

Interview guests:

Li Chengyin, Lin Feng, Lin Shun, You Yuxi, sofish

This article comes from: http://githuber.info/#/report