【2014】GitHub China Developer Annual Report

[[127178]]

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 those led by individuals or communities?

Lin Shun: The advantages of open source projects supported by companies or capital over those supported by individuals or without capital are: more resources are invested, which is crucial to the later development of open source projects, allowing more full-time R&D personnel, and the iteration cycle and quality of products can be well controlled, providing more continuous 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 you serve the industry, promote industry upgrades, and do open source projects with an open mind, there will be no disadvantages. There is no shortage of 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 developing very well. There were several companies willing to invest in us, but in the end, I still felt that Chen Haozhi was very open-minded and could insist on not turning an open source project into a closed source commercial project. In the end, I worked with him and found that our original choice was the right one.

G: If other companies also want to go the open source route, what would you say to them?

Lin Shun: We welcome you to join the open source route. Open source projects can provide valuable knowledge for both individuals and companies. The wisdom gathered in the community is extremely valuable. If senior foreign programmers teach you a few tricks, you will find that the code can be written in this way and the framework can be designed so elegantly. In addition, interacting well with the community and effectively collecting user needs and feedback are the key to driving open source projects in the right direction, and are 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 fast way for programmers to learn and grow. Not only that, if you are a technology enthusiast, participating in open source projects may help you find your own interests and expertise. Of course, if you can find a point of integration with business and then do what you like, it would be even better, which is very rare.

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

GitHub is very popular around the world. It provides a very efficient project development collaboration mechanism and is a good entry point to understand the operation mechanism of open source projects. On GitHub, developers can share code with people all over the world at any time, and also allow people from different parts of the world to contribute various ideas and code snippets. It is also the basis for community communication. More and more open source projects are migrating to GitHub. Finally, welcome everyone to join the Cocos2d-x open source project community, become a part of our community, and realize your own game dream.

Pen

G: Please briefly introduce yourself.

Xiaoyu: Everyone calls me Xiaoyu. On most websites that require an ID, I usually call myself sofish. After graduating from law school, I have been writing code.

G: You have worked on many open source projects, so let’s talk about Pen. There are many Markdown-related projects, but this is the first time I have seen a project like Pen. Please 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 posting experience of Baixing.com users should be better. GitHub happened to have a very popular ZenPen project at that time, so I planned to use it. However, the code coupling of this product is too high, CSS/JS are inseparable, and the functions cannot be customized. I felt it was very useless, so I had no choice but to write it myself. The goal is to make the editing and publishing results the same, a true WYSIWYG, support custom functions, and separate CSS/JS. And some of the syntax of Markdown happened to be relatively concise, so I supported it directly. When it was on Trending, GitHub employees submitted a very powerful PR to support the display of Markdown.

But later I thought it was too troublesome, so I didn’t integrate it into the product and never updated it. Until Teambition started using it, Yan Qing contributed a lot of code and solved many hidden bugs.

G: How did you first come up with the idea of ​​creating a Pen project? What interesting or impressive things happened during the process? Share them with us.

Xiaoyu: As mentioned above, the direct reason is work needs. Most of my open source projects, except Typo.css, are directly caused by the desire to abstract some functions in the work into modules, and then open source them. For example, the earliest AliceUI was open sourced after it was widely used in Alipay. If I have to say what is impressive, I think open source projects must be used in a certain product, especially commercial projects, to become truly useful, because both open source and closed source need to ensure quality, and work is one of the motivations. Any open source project that is not really used in commercial products should be used with caution, and it cannot be called good.

G: How did Pen get so many stars? Have you done any related promotion?

Xiaoyu: No, I just posted on Weibo and V2EX, and then a lot of people paid attention to it.

G: As one of the top ten developers in China, you must be very busy with your work. How did you complete the Pen project under such circumstances?

Xiaoyu: I am busy with work, but I am not completely without time. The busiest period of my life seems to be the 6 months before I wrote this sentence, because I have to lead people while working on products, and it is normal for me to get home after 10 o'clock. Therefore, I have not produced much recently. Except that m.ele.me has been launched, there are no open source projects. Compared with the conception of what Pen should be like and what level of experience should be achieved, it does not take much time to write Pen. 300 lines of code is not difficult for me. By the way, ZenPen should have been at the level of several thousand lines at that time, but its functions were not as good as Pen.

G: Do you think it is difficult to develop and maintain an open source project as an individual developer? Have you ever wanted to give up?

Xiaoyu: The difficulty depends on the project. However, I believe that more people may not necessarily solve the problem, because technical problems generally have a ceiling. For core ideas and technologies, they should be produced by fewer people in most cases. Once the ideas and core technologies are set, adding functions may not be as difficult as imagined. As for whether to give up, I usually think like this: the worst possible outcome is giving up. Many good things will happen if you persist, such as writing a blog. If there are many urgent things and not much time, sometimes you can only give up and do only what you think is urgent.

G: What do you think are the essential differences between open source projects developed by individuals and those with company backgrounds? How should a developer choose?

Xiaoyu: They are all open source in essence. I haven't done any statistics on whether things that are open sourced by individuals or by companies are more successful. However, most of the code for ElasticSearch is written by one person and is very successful; Docker is maintained by a company and is very successful; Bootstrap is developed by two people and maintained by a company and is very successful. In essence, I think that if an open source product is truly useful, people will use it; if a company gives time and money to support it, that's great; and the best thing is to have a community and everyone maintains it together. For example, you can find almost all the answers about jQuery on Google, and that's the power of the community. So if you have a good project, then try to cultivate a community, which is better than a zombie project written by one person or supported by a company but not developed by anyone.

G: If someone wants to go the purely personal open source route, what would you say to them?

Xiaoyu: Making a useful product is more interesting than whether it is open source or personal. If possible, please only produce things that make the world a better place.

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. It can have many meanings. It can benefit others, get feedback for improvement, let more people know you through your code, and so on. It is different for everyone. Open source has not directly changed my life, but I like to write code and help others. It is a great pleasure for me, and a fun life is the meaning of my life.

As for GitHub, it is just a work/collaboration platform, and there are many other platforms like it. However, I have been using it because other products are too ugly, both in details and experience, and I prefer to choose a good tool, even if it is paid.

Vue.js

G: Please briefly introduce yourself.

Yuxi You: My name is Yuxi You. I am currently working at a startup company Meteor, developing a full-stack JavaScript framework. Before that, I was at Google's Creative Lab in New York, mainly responsible for HTML5 interface prototype development.

G: There are many MVVM frameworks now. What is unique about Vue?

Yuxi You: Compared with other MVVM frameworks, Vue has two main features: 1. Native JS objects are models; 2. Component-oriented development mode. Other features are that it is lightweight, less invasive, and easy to use.

G: How did you first come up with the idea of ​​doing a project like veu? Is there anything interesting or impressive during the process? Share it with us.

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

G: How did Vue get so many stars? Have you done any related promotion?

Yuxi You: When Vue was first released, it was mainly promoted through some foreign software development news aggregation sites, such as HackerNews, Reddit, and some front-end development blogs/newsletters. In fact, I just sent a link to see if I had any luck. After that, I didn't do any deliberate promotion except maintaining an official Twitter account. I think whether a personal open source project can gain long-term attention depends on whether the initial release can generate a good momentum. The rest is basically natural growth. When Vue was posted to HackerNews, it was pushed to the front page. This may be the most critical opportunity, because the traffic and attention brought by HN are really amazing, and the audience are all developers. On the other hand, I also put a lot of effort on Vue's documentation site. Good documentation shows the sincerity of developers, and the first impression is also very important.

G: Creating a framework must take a lot of time and effort. How do you arrange your time to implement it?

Yuxi You: It did take a lot of effort. For a while, I spent almost all my spare time on it. Of course, since Vue is also used in some projects at work, there is also reason to allocate some time during work. My work on Vue is actually somewhat cyclical. There may be a few months of special investment, making some relatively large improvements, and then there will be a few months to focus on other things, and only fix bugs in Vue.

G: Do you think it is difficult to develop and maintain an open source project as an individual developer? Have you ever wanted to give up?

Yuxi You: It depends on the scale of the project. Generally speaking, for projects suitable for personal maintenance, it is best to focus on solving a smaller, specialized library, otherwise it may take up too much energy. When the scale of the project reaches a certain level, it is best for the community or team to jointly maintain it. To be honest, the current growth rate of Vue's issues is already quite tiring. Fortunately, there are many community developers who will actively help answer questions, which saves me a lot of energy.

G: What do you think are the essential differences between open source projects developed by individuals and those with company backgrounds? How should a developer choose?

Yuxi You: Open source with a company background is definitely driven by commercial interests, so as long as the company's commercial interests are positively correlated with the development 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 community opinions as projects developed by individuals. Personally, I think when choosing a project, whether it is developed by an individual or a company is not the key, the key is to see whether the company/individual behind it is reliable.

G: If someone wants to go the purely personal open source route, what would you say to them?

You Yuxi: I think that because of limited energy, personal open source requires focus. More importantly, you need to have a clear understanding of the positioning of the project you are doing and make sure that what you do really solves a pain point. Only then will the energy you spend be 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?

Yuxi You: I think the significance of open source for ordinary developers is that they can learn from other people's source code. You can learn a lot by using advanced search on GitHub to search for projects and developers with your language at the top. In addition, you can also find a lot of good things by looking at trending new projects every week. On the other hand, it is also good to open source as much of your own code as possible, because it can force you to maintain a high standard for your own code, rather than just muddling through.

Participants

(Ranked by the number of strokes of surnames)

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:

Lee Sing-yin, Raymond Lam, Lam Shun, Yu-Chi Yu, sofish

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