This article is not a purely technical article, but more of 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 be helpful.
Next, I will share my thoughts with you in the following catalog outline:
- My thoughts on domestic open source projects
- How does the negative trend of open source projects/communities in China accelerate the “rollback” of recruitment?
- What do open source projects bring us?
- How to build an open source project with high execution and rapid iteration from zero to one?
- Share several valuable open source directions
My thoughts on domestic open source projects
First of all, before expounding any point of view, we should look at and digest it from a critical point of view, because anyone’s thinking and opinions may be limited.
Open source projects are noble and interesting.That’s what I used to think. The foreign open source big man TJ and so on, the 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 the amount of failing grades they handed out.
So reading these great open source projects made me grow a lot, and I also learned how to do really valuable open source projects.
However, in the past two years, when I was watching the trends of GitHub, I could not help feeling a little embarrassed, and at the same time I felt a little powerless. When I see a large number of domestic cut leek type open source projects, can not help but write on the draft paper:
All right, without joking, here are some of the things I’ve learned about good open source projects.
From the point of view of project self-generating structure
- The project directory has a clear structure
- File/folder naming conventions, readability
-
A clear and complete introduction to README
- A concise project description
- Project version information, highly recognizable logo
- Project application scenario introduction, demo case
- API usage documentation
- Clear todo and undo listings
- Contribution to guidance and related ecology
- A canonical and detailed package.json file (or project description file)
From a practical point of view
- Addressing a pain point in the current development environment (e.g., modular solutions AMD, CMD, etc.)
- Quickly improve development efficiency (efficiency tools, tools/libraries, etc.)
- Can solve the bottleneck of a framework (e.g. Vue/React in jQuery)
- Makes it easier to develop with a framework (Vue/React/JQ etc)
- Can well solve common business requirements of enterprises (such as ANTD-Pro, Egg, H5-Dooring)
- Open source that enables programmers to quickly understand open source projects (such as translated documents, stable technical thinking, and quickly smooth out cognitive differences)
Of course, there are still some directions to think about, such as the underlying technical solutions (operating system, basic language, etc.), which are too far away from me and put on hold temporarily.
How does the negative trend of open source projects/communities in China accelerate the “rollback” of recruitment?
Within the volumeThe original meaning is that a kind of cultural mode can neither stabilize nor change into a new form after it reaches a certain final form, but can only become more complex internally.
In the last two years, you have not found that the major technology community is filled with a large number of job interview related articles, the level is not uniform, a thousand more or less a “green”. Want to take a serious look at technical articles, but also have to spend time down to turn over several times, because the top of the basic recommendation by the interview article, into the big factory Wenba accounted for.
Although applying for a job requires preparation, I personally think there is no need to prepare too much, otherwise we will inevitably encounter the most familiar scenes:The “Roll King Interviewer” and the “Cabbage Job-Seeker” fell in love.
Here I will analyze the reasons why excessive release of facial meridians causes more and more curling.
The interviewer thought: what interview questions? There are so many experiences in the community, and I think everyone must be prepared. Then come to some tough ones (difficult ones).
Job seekers think: recently see a variety of face classics, whether it is large or small factories, interview questions are so difficult, I want to brush a few more questions.
OK, it’s not over yet. Next is the 1000+ pen/interview question on GitHub. Please brush it.
Boy, how much can programmers who are trained in such an environment imagine about technology in the future? This reminds me of a famous quote from another of my heroes:
Imagination is more important than knowledge. – Albert Einstein
And think of a foreign brother whose imagination touched Mars:
So I want to make three points in this video:
- How much of a long-term interest will the frazzled job seeker have in technology in the future? Is it the bankruptcy of morality or the distortion of human nature?
- The domestic open source environment is full of similar interview questions. How much imagination space will domestic individual open source projects have in the future? Is it true that domestic valuable open source can only be played by big companies?
- Without sustained interest and imagination, you will never be able to create a good and valuable open source project.
Of course, this is not to discourage these, the intention is not to focus too much on the brush, in fact, occasionally do valuable open source projects, will also be good for the interview points. After all, in nearly three years of job interviews, I had never done any preparation for an interview.
What do open source projects bring us?
In the points in the above sections, you can refine the valuable points. Let’s move on to today’s business.
What can I get from working on open source projects? This is probably a question for most people who want to do open source projects. Most people also go into certain mistakes, although the question is simple, but simple questions are often more complex.
First of all, some people think that open source projects can help them accumulate project experience, add points to their resume, consolidate their knowledge system, accumulate popularity, and so on. That’s what I thought. But this kind of open source thinking is only appropriate for beginner open source, and the general result is that while open source projects give you technical proficiency and a resume to write about, they are eventually forgotten over time.
So now, before I think about this question, I must ask myself a few questions:
- What problem am I doing this open source to solve?
- 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 rather than just a passing fad?
After answering the above four questions, we will have a better sense of purpose and framework when we do open source projects, and we will have a better idea of what we can expect:
- Unique solution
- More in-depth research and understanding of the field
- I will be able to talk about my future career development
- Harvested more technical solutions and open source partners
- Demonstrate personal value and influence in a certain area through project value
- Harvest money, traffic, enterprise offer
So weDon’t obsess over results. By doing valuable open source projects, we will naturally make ourselves more valuable.From what I doH5-DooringBefore this project, I have fully answered the above four questions raised by myself, so the final result of the project is obvious to all. After I finishH5-DooringAfter the first release, in order to solve the fourth problem, I selected a few like-minded friends to iterate with me and keep the project going as planned.
How to build an open source project with high execution and rapid iteration from zero to one?
Take my own actual experience as evidence, to talk about the grinding process of open source projects.
Don’t ask me why this process is like a “heart”, I just want to say that 7 out of 10 open source authors generate electricity for “love” (so keep your eyes open for those excellent people 👏).
1. Goal planning period
First, after figuring out why we want to do this project, we need to have a clear and complete roadmap for our open source project. For example, what needs to be done in 1.0, what needs to be done in high priority, and what is not urgent, can be done later. So we have to make good use of the four quadrant rule.
The second is clear function splitting, requirements pool management, learn to filter requirements, rather than a total acceptance, because sometimes the user proposed requirements he does not know, 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 the project is mainly the rudiment of the project. This stage must be the construction of the project leader, and it is necessary to have a complete idea and implementation plan for the overall technical selection, structure and solution design of the project. This will set the stage for future team development, iteration, and project optimization that would otherwise end in chaos. H5-dooring also followed this idea in the early stage of the project. I designed the complete process of the project first and open source it on GitHub before I could find a group of intuitive and interested friends to maintain and optimize it.
3. Team formation period
Team building is also 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 executive power, play a leading role
- To enlarge the situation, accept friends who are better or weaker than you, and play to their strengths
- Strong belief in the project
- Modesty + pursuit of acme
- Attitude to learn from and grow together and work with teams
Only with the above three points can you build an efficient and cohesive team.
At the same time, open source projects can only grow steadily if we choose collaborators who share the same values, are interested in the project, and have the ability to execute it. So the number of teams does not have to be fast, the number of teams is small, it does not have to be slow. So we had a lot of friends who wanted to join usdooringI will ask myself to chat with them and do some basic assessment and screening. We are currentlyDooringXAlthough the team members are not many, they have expertise. I believe that the project will be done very well in the future.
4. Teamwork/run-in period
Teamwork/running-in is the communication, communication and so on that we do with each other when we divide tasks.
We need to make it clear to each of the co-founders what our common goals are, and what our responsibilities are. This stage is often the best time to assess the team. We can find out what different team members are good at, what work they can do, and what tasks they can improve and grow through the project.
So regular communication is essential. During dooring, I did find some inappropriate friends. Some of them may be short of time, and some of them are problems of values. All these need to be solved through communication, and if they cannot be solved, they should be dealt with decisively. Project sponsors do not have to think too much about personal feelings, creating a relatively comfortable environment for each other is the most important. After all, each has a need to go to the other shore.(a little love to break up the feeling of theory, stop at this 🐷)
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 has their own role to play. We need to keep moving along the main line of our goals, so we need to assign the right people the right tasks and let the good people drive us to grow together. Founders are the drivers of a project’s success, so you need to be open to good ideas and directions, and look at your limitations. After all, everyone has something to shine about.
5. Version iteration and review period
At every stage of the project we need a review and reflection. So finishing is the first step, how to make the project do 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 development direction, and brainstorm constantly to make the project the best it can be. Of course, there are trade-offs. It’s like a PDCA cycle.
Share several valuable open source directions and projects
In fact, I have explained the direction of open source in the practicality of open source projects above, but the premise still needs to be chosen according to their own preferences and strengths. Here, the author lists several open source directions that can be done:
- Page visualization platform
- Buried point visualization platform
- Browser-based document engine
- Collaborative system
- Intelligent customer service plug-in
- Hongmeng system tool plug-in
- Wireless JS application platform
- Visual graphics engine
- Js ai related
- Build platforms across ends
There are a few open source projects out there that you can get involved with because the founders are really nice:
- H5-DooringVisual H5 editor
- helloworld-Co/html2md| powerful HTML md tools
- ant-simple-proSupport multi – framework out of the box admin template
- mengshukeji/LuckysheetOnline spreadsheet project (online excel)
- MrXujiang/pc-DooringVisual PC side editor
- dooring-electron-lowcodeElectron based Lowcode desktop editor
The above is purely personal point of view, you have the choice to absorb, welcome more friends with ideas, join in the true open source technology.