This article is not a pure technical article, but more a review and summary of my programming technology, domestic technical community, and my own technical road. I will share my technical values and open source experience with you one by one. If you’ve ever wondered about your future as a programmer, this article will help.

Next, I will share my thoughts with you as follows:

  • My thoughts on domestic open source projects
  • The adverse wind of domestic open source projects/communities is how to accelerate the recruitment of “roll-in”?
  • What can open source projects bring us?
  • From zero to one, how to build a high execution, fast iterative open source project?
  • Share a few valuable open source directions

My thoughts on domestic open source projects

First of all, before stating any point of view, we should look at and digest it from a critical perspective, because anyone’s thinking and point of view can be limited.

Open source projects are a very noble and interesting thing.This is the view that I have always held. Foreign open source big man TJ and other people, domestic uncle Tom and so on, has been my technical idol.

I found some comfort in the fact that the only thing they had in common with me was an f.

So reading all these great open source projects has made me grow a lot and learn how to do really valuable open source projects.

However, in the last two years, WHEN I read the trends of Github, I felt a little embarrassed and felt a little powerless. When I saw a large number of open source projects in China, I couldn’t help writing on the scratch paper:

So, without teasing, here are some of the things I learned about good open source projects.

From the perspective of project authentically generated structure

  • The project directory structure is clear
  • File/folder naming standard, readable
  • Clear and complete readme introduction
    • Concise project description
    • Project version information, logo with high recognition
    • Application scenarios and Demo cases
    • API usage documentation
    • Clear todo and undo lists
    • Contribution guidelines and related ecology
  • Formal and detailed package.json file (or project description file)

From the perspective of project practicality

  • Addressing a pain point in the current development environment (e.g., modular solutions AMD, CMD, etc.)
  • Can quickly improve development efficiency (enhancement tools, tools/libraries, etc.)
  • Vue/React with jquery
  • A great way to reduce the difficulty of developing projects using a particular framework (e.g. plugins for vue/ React/JQ, etc.)
  • Good solution to common business requirements (e.g., ANTD-Pro, Egg, H5-dooring)
  • Open source that allows programmers to quickly understand open source projects (such as translating documents, stable technical thinking, and quickly smoothing cognitive differences)

Of course, there are still some directions that I can think about, such as the underlying technical solution (operating system, basic language, etc.), which is too far away from me, so I shelve it temporarily.

The adverse wind of domestic open source projects/communities is how to accelerate the recruitment of “roll-in”?

Introversion: The original intention is a phenomenon that a cultural pattern can neither stabilize nor change into a new form after it has reached a certain final form, but can only become more and more complicated internally.

In the last two years, have you noticed that the tech community is flooded with articles about job interviews? If you want to take a serious look at the technical article, you have to spend time to go down a few more times, because the top recommendation is basically the interview text, into the big factory hegemony occupied.

Although hunting for a job requires preparation, I personally don’t think it is necessary to prepare too much, otherwise it will inevitably encounter the most familiar scene:“Curly King Interviewer” and “Cabbage Job seeker” love each other.

Here I will give you an analysis of why excessive release of the surface caused by more and more coils.

The interviewer thought: what interview questions, the community on so many face, presumably we must be prepared, that point just (difficult).

Job seekers think: recently see all kinds of face classics, no matter big factory small factory, interview questions are so difficult, I want to brush a few more questions.

Ok, that’s not all, here’s the github 1000+ pen/interview question, go ahead, you didn’t enter the big factory, not the problem, it’s your reason.

Boy, how far can programmers, nurtured in such an environment, imagine the future of technology? This reminds me of a famous quote from another of my heroes:

Imagination is more important than knowledge

And to an old foreigner whose imagination touched Mars:

So I want to make three points in this video:

  • How much long-term interest in technology will drained job seekers have in the future? Is it the decline of morality or the distortion of humanity?
  • The domestic open source environment is full of similar interview questions, how much imagination will domestic individual open source projects have in the future? Is the open source of domestic value really a big company to play?
  • Without sustained interest and imagination, there will never be a good, worthwhile open source project.

Of course, this is not to discourage the over-emphasis on copying questions, in fact, occasionally do valuable open source projects, will also be a plus. After all, IN nearly three years of job interviews, I had never done anything to prepare for an interview.

What can open source projects bring us?

In the points in the above sections, you can extract valuable points. Let’s move on to the topic of the day.

What can I get out of working on open source projects? This is probably a question for most people who want to do open source projects. Most people will also go into a certain error, although this problem is very simple, but the simple problem is often more complex.

First of all, some people think that open source projects can give them project experience, resume points, strengthen their knowledge, gain popularity and so on. That’s what I thought. But this kind of open source thinking only applies to the beginning of open source, and the common result is that while open source projects give you technical proficiency and something to write on your resume, they will eventually be forgotten over time.

So now I, before thinking about this question, will ask myself a few questions:

  • What problem am I trying to solve with open source?
  • What are the existing solutions?
  • What can I do to make it better than what I already have?
  • How can I make my project sustainable instead of just passing by?

After answering these four questions, we have a better sense of purpose, framework, and what we can expect from open source projects:

  • Unique solution
  • More in-depth research and understanding of the field
  • More talk about future career development
  • Gained more technical solutions and open source partners
  • Demonstrate personal value and influence in a field through project value
  • Harvest money, traffic, enterprise offer

So weDon’t focus too much on results, we will make ourselves more valuable by doing valuable open source projects.From what I doH5-DooringBefore this project, I have fully answered the above four questions, so the final result of the project is there for all to see. After I finishH5-DooringAfter the first edition, in order to solve the fourth problem, I selected several like-minded friends and iterated with me to make the project continue to advance according to the plan in advance.

From zero to one, how to build a high execution, fast iterative open source project?

With my own experience as evidence, to talk about the open source project polishing process.

Don’t ask me why this process is like a “heart”, I just want to express that 7 out of 10 open source authors are generating “love” (so silently for these wonderful people 👏).

1. Goal planning period

Once we’ve figured out why we’re doing this project, we need to have a clear and complete roadmap for our open source project. For example, what features need to be done in version 1.0, which features are high priority and must be done, and which are not urgent and can be done later. So we need to take full advantage of the four-quadrant rule.

The second is clear function separation, demand pool management, learn to filter demand, rather than a blanket acceptance, because sometimes users do not know the demand, so need to review.

With the above goal planning and management principles, we can have a clear and efficient goal planning.

2. Project construction period

The construction period of a project is mainly the embryonic form of the project, which must be set up by the project leader. It is necessary to have a complete idea and implementation plan for the overall technology selection, architecture and solution design of the project. This will set the stage for future team development, iteration, and project optimization, otherwise it will end in chaos. H5-dooring followed the same path at the beginning of the project. I first designed the complete process of the project and opened it on Github. Only later could I find a group of intuitive and interested friends to maintain and optimize it.

3. Team building period

Team building is also very critical. First, a founder needs to have the following characteristics:

  • Have certain technical strength (able to make solutions independently and control the whole project)
  • Have a certain depth of research on the project and have a clear goal planning
  • Absolute execution, play a leading role
  • Scale up, accept friends who are stronger or weaker than you, and play to their strengths
  • Have a strong belief in the project
  • Modesty + pursuit of perfection
  • Learn from each other and grow together with a team attitude

Only by having above three points can we build an efficient and cohesive team.

At the same time, only when we select collaborators who share the same values, are interested in the project and have certain execution ability, can the open source project develop steadily. Therefore, a large team size does not necessarily mean fast, and a small team size does not mean slow. So a lot of my friends wanted indooringI would invite myself to talk to them and do some basic assessments and screening. We are currentlyDooringXAlthough there are not many people in our team, we are good at it. We believe that we will do a very good job in the future.

4. Teamwork/break-in period

Teamwork/running-in is the way we communicate with each other when we divide tasks.

We need to make sure that each of our co-founders is clear about our shared goals and their respective roles. This stage is often the best time to assess the team. We can find out what different members of the team are good at, what tasks they can be competent for, and what tasks they can improve and grow through the project.

So regular communication is essential. During dooring, I did find some unsuitable friends. Some of them were in a tight time frame, and some had problems with values. The sponsors of the project need not excessively consider personal feelings, creating a relatively comfortable environment for each other is the most important. After all, each of us has something to go to the other side.

Another point is to make good use of talent and listen to good advice with an open mind. Everyone is a contributor to the team, and we need to keep moving forward along the main line of our goals, so we need to assign the right people the right tasks, and let the good people lead us to grow together. Founders are the drivers of success, so you need to take good advice and direction and look at your limitations. After all, everyone has their sparkle.

5. Version iteration and review period

Every stage of our project needs a review, reflection. Therefore, completion is the first step, and how to make the project better is the key to the long-term development of the project. Everyone on the team can make suggestions, put forward their own ideas and direction, and constantly brainstorm to make the project the best. Of course, there is a need to control, trade-offs. It’s like the PDCA cycle.

Share several valuable open source directions and projects

In fact, I have elaborated on the practicality of open source projects above, but the premise still needs to choose according to their own preferences and strengths. The author lists several open source directions that can be done here:

  • Page visualization platform
  • Buried spot visualization building platform
  • Browser-based document engine
  • Collaborative system
  • Intelligent customer service plug-in
  • Hongmeng system tools plug-in
  • Wireless js application building platform
  • Visual graphics engine
  • Js ai related
  • Build platforms across ends

There are several existing open source projects you can also participate in, after all, the founders are very nice:

  • H5-DooringVisual H5 editor
  • helloworld-Co/html2md| powerful HTML md tools
  • ant-simple-proSupport multi – frame out of the box back-end management template
  • mengshukeji/LuckysheetOnline Spreadsheet Project (Online Excel)
  • MrXujiang/pc-DooringVisual PC editor
  • dooring-electron-lowcodeElectron based Lowcode desktop editor

The above is purely personal point of view, you have a choice of absorption, welcome more friends with ideas, together into the real open source technology.