Open source is not just about making the code available; it’s about how to use your code to address real-world needs, continuously iterate and update, and build a community for open source projects. Based on my experiences with open source over the past couple of years, I want to share my views on open source from a developer’s perspective and some thoughts on open source behavior.
For individual developers, participation in open source typically starts with toy code. You might feel that you have created something slightly useful, so you put it on GitHub. If someone happens to see it and finds it useful, they might try using it in their own projects. If developers can persist in iterating and updating the project, they will accumulate some real users who use it in actual projects. This is the normal development process for individual open source projects. Unlike projects within large companies, which have already undergone extensive internal iterations before being open-sourced at a particular point in time, and have the backing of major firms to promote them, individual developers can only rely on mingling in relevant tech communities and word of mouth, limiting the speed and breadth of dissemination.
In my view, if open source is seen from a utilitarian perspective, it certainly won’t be done well (KPI projects). The basic actions of open source do not yield significant practical benefits; truly engaging in open source requires vast amounts of energy, with many projects supported mostly by passion.
Moreover, as more people start using a project, there will be increasing demands for its features, applicability, and stability. Even slight changes in the code can impact a variety of users in different situations, making updates less spontaneous. Before submitting, one should try to undergo some testing processes as much as possible, which can be energy-consuming. The time spent on testing may even exceed the time spent on development. However, I believe at this stage, open source projects truly escape the state of merely storing code on GitHub and begin to add real value to other users.
For open source projects, version iteration and documentation management are also very important. Once the project has basic functionality, supplementing clear documentation can save onboarding time. Documentation also needs to be continuously updated along with project developments. After some time of iteration, there may be significant changes in internal implementation and usage processes; using an old version manual to operate a new project will certainly lead to numerous issues. However, continuously updated and iterated documentation is often lacking in many open source projects. This is also a pragmatic issue, as synchronously updating projects and documentation is quite troublesome and energy-consuming. Personally, I think it comes down to developing good record-keeping habits.
In fact, having clear documentation does not necessarily ensure it will be effective. I don’t know why, but it seems that most people do not like reading documentation. Some projects have clear descriptions of basic concepts and operations, yet there are always people who contact the authors directly with questions. A person’s energy is limited, and it’s impossible to spend a majority of that energy serving as customer support for basic operations of a project. Therefore, one needs to consider ways to establish a communication channel for people with similar needs. Because in different types of projects using an open source project, there are always common demands. If a group of people with similar needs can be gathered, they can harness each other’s strengths to help solve similar issues.
How to build a user community for an open source project? First, the project should be able to accommodate simple modifications to meet different needs, as requirements in different businesses cannot be completely identical and there is no universal remedy at the business level. Therefore, open source projects should only consider general requirements, which is likely why most open source projects still need to undergo trimming and adaptation when applied in engineering. This also creates a situation where converting a general solution to meet different specific needs always leads to questions about understanding specific implementations or modifying the open source project, etc. Consequently, many people ask things like, “Can this feature be implemented?” or “Can xxx be changed to yyy?” For developers with strong hands-on abilities, since it’s open source, they can understand most of it by skimming through the code. However, some people might feel pressured by business timelines and want to find ready-made solutions, hence requiring advice from a group of developers with similar needs. This is the significance of the technical community in open source projects.
This also allows authors to save more time because open source authors also need to work in their main jobs; updates to project features and documentation are generally done during their break times. If they must also work as “technical customer service,” it will take even more time than implementing features. Thus, the best outcome is to gather people with similar needs together to engage in discussions about the project and related technologies within the community, fostering a healthy and sustainable environment.
In fact, open source projects, in most cases, do not yield genuine material rewards. However, I believe that being able to create something that addresses other people’s needs and generates real value is an extremely exciting thing. Viewing the open source endeavor entirely without utilitarianism truly returns it to the essence of technology sharing.
I think the satisfaction that open source brings comes from two aspects: one is the ability to meet others’ needs, and the other is the recognition received. Thus, one can feel that their work has value to others. These two points are the main motivations driving open source efforts. Moreover, in my opinion, technology must be shared, as sharing promotes overall progress. Reflecting on the history of CS development, those great hackers selflessly devoted their intelligence and creativity, which has shaped the current computing era. I am also willing to do my utmost within my ability to contribute to technology sharing.
Life is finite, but knowledge is infinite. How can one, with limited knowledge, not perish by following the infinite? We need a spirit of sharing!
