Seven common mistakes in open source projects

【51CTO.com Quick Translation】 Starting a new open source project can be difficult. Maybe you have a great idea in your head, but it takes a lot of work to turn it into a productive, healthy, and attractive community. It is a pity that the same mistakes are always repeated at no cost, and low-level mistakes are taboos in the team. Please follow the author below to look at the common mistakes in open source projects and try to avoid them. I believe it will be helpful for your project development.

[[199380]]

1. Chat instead of sending

In thousands of open source projects, too many people get bogged down at the beginning because of slack channels, mailing list issues, or other aspects. Discussions spread around the house and grow in scope, incorporating many different ideas and considerations. An early open source principle "release early, release often" has served us well. Don't try to solve all challenges, write code, put it in a repo, and start accepting impact requests. When you focus on the code, your project will evolve, adapt, and improve faster.

2. Sending of ***

Reid Hoffman, founder of LinkedIn, once famously said, "If you're not embarrassed about the first version of your product, you've launched it too late." This is especially true for new open source projects. Try to make your first version, or even your first version, as great as possible. The reality is that most people won't notice your first version, so it doesn't need to be great. People notice, consume, and participate in open source projects during development. Start shipping, get feedback, make improvements, and those improvements and shipping are what teach you how to grow.

3. Complete infrastructure

A common pattern in open source projects is to enhance the site's infrastructure, collaboration platform, and continuous integration and deployment, making everything else as seamless as possible. This can result in some parts of the code being ready, while other parts are a concern for the project sponsor. This can lead to a lack of foundational projects.

A classic example is a website. Some projects will delay delivery until they are fully designed, while a well-designed website can continue to operate. This is obviously not a positive example.

Improve your infrastructure until you can build a collaborative software platform. Distribute your software and increase your influence, which will take your community building further. As your construction grows and improves, you will get more help to improve your infrastructure.

4. Non-enforcement of Code of Conduct

In recent years, issues with diversity and inclusion have surfaced. We want to make sure our communities are diverse and inclusive, and diverse communities lead to better outcomes. Many communities start building without considering what behavior they want to see. For many, a given community should be happy, fun, and colorful. Some projects formalize this by putting a code of conduct on their website. This is not enough, the way you enforce good behavior is to make sure the project's leaders have good behavior.

5. Loss of focus

Seriously, while one of the main joys of open source is the enormous creative potential, many projects struggle or shut down because they are too fragmented and too focused. Don't try to be all things to all people. As a project launches, you will get a million pull requests from enthusiastic users. Focus on your goals, encourage people to join your project, and expand its impact. Also, while "patches" are welcome, don't just look for patches, look for maintainers. The last thing you want to do is maintain technical debt for someone else's work.

6. About various comments

There are many communication platforms around us that have an attraction to ensure everyone is included. This is a mistake. As I discussed communication, there are different types of communication channels, which I broadly divide into structured and unstructured channels.

I recommend the following guides:

All bugs and technical discussions can be found on GitHub/gitlab

·Build a general "community club" on a discourse-driven forum

There is a live chat channel where people can have quick and informal discussions.

· Each channel has a different purpose, not all are essential. The question is the most important, followed by others.

Once again, stay focused and keep the discussion focused, this will build momentum.

7. Taking Yourself Too Seriously

Developing open source projects should be fun, build good relationships between teams, and make everyone happy. The structure of open source is built on community members who are engaged in innovation and have a talent for innovation, putting new ideas into action. Always maintain this flexible and innovative spirit. It will help your project grow.

By Jono Bacon
Original link:
https://opensource.com/article/17/8/mistakes-open-source-avoid
Translated by Liu Nina

[Translated by 51CTO. Please indicate the original translator and source as 51CTO.com when reprinting on partner sites]