TranslateProject/sources/talk/20220726 Open Source Software- Is There an Easy Path to Success-.md

[#]: subject: "Open Source Software: Is There an Easy Path to Success?"
[#]: via: "https://www.opensourceforu.com/2022/07/open-source-software-is-there-an-easy-path-to-success/"
[#]: author: "Jules Graybill https://www.opensourceforu.com/author/jules-graybill/"
[#]: collector: "lkxed"
[#]: translator: " "
[#]: reviewer: " "
[#]: publisher: " "
[#]: url: " "

Open Source Software: Is There an Easy Path to Success?
======
There’s so much that goes on behind the scenes while developing open source software. So how does one make an open source project successful? Is there a shortcut? This article indicates there isn’t one.

![team work working together][1]

Open source has become all the rage now. Many entrepreneurs are drawn to it by the allure of quick success. But the truth is, there is no easy path to such success. There is no one thing that you can do to get all of open source right.

In fact, a lot of the challenges that companies face early on are not technology challenges, but are people and cultural challenges.

There are many layers of open source that need to be worked on to build a project that can become a hit in the market. And maintaining that success is an ongoing process. But at the crux of it all lies finding the right answer to a very basic question: what exactly is open source?

### Open source is the code

For many new users who may not be fully aware of the layers that make open source, the answer is fairly simple: open source is software! And that is not wrong, of course, since that is how most of us are using it. But there’s just so much more to open source than merely being touted as software.

The essence of any open source project still remains the code. It is what makes the project special and useful for the user. When you’re working in open source, the code is just as much a part of the product as the software.

Developing a project from the ground up, or even creating a fork of an existing project, requires thousands and thousands of lines of code to be written, even while handling such a large and complex codebase. Especially in the case of creating a fork, care must be taken to remove any prior licences, marketing material, or anything that might not be useful for the user anymore. After all, it is the features of a project that attract its user base and what retains it. When end users are deciding whether to use open source software, they will read the source code, and what they see there should be something that builds their confidence.

### Open source is the community

How you engage with the community is also a part of the task of building a product. Building a community and maintaining a healthy relationship with it is one of the most crucial aspects of open source, but is also often the hardest for most leaders as there is very little one can do to control it. One can try to lay the foundation and can be supportive but, ultimately, it’s the people who decide whether they want to join a community.

It is important to maintain a level of transparency with the community and keep it in the loop. The community can get involved at any step that it wants to. It’s really important that you show most of your work to the community while you are doing it, apart from things that need to be done confidentially, like setting up security, signing certificates, branding, and so on. This helps in winning its trust because, in the end, it is the community that you are liable to, and it can make or break your project. This may make the project work a lot more deliberate, slower and exposed, but it works well in the end.

Making your work-in-progress so open can seem daunting, especially when you are worried about the repercussions of a delay in updates or having a bug. Yet, making the community members privy to your moves will not only help you build a trustful relationship with them, but also make them feel appreciated.

However, making your workflow public will also invite scrutiny from the community members, who will often have their opinions and offer you their feedback. Taking note of this feedback is important, because that is how you can make your open source project truly for them. They are the end users and their feedback will reflect how they see your project panning out for them in the long run, and ultimately, how successful and mainstream your software becomes.

As an example, when we are thinking about a new feature, we publish a request for comments at RFC. We get a lot of feedback, and we have to think hard about how we can incorporate it.

Since open source is a largely collaborative work, there will be initiatives by the community to offer their support in making the project the best version possible. Not all of it will work out. But as long you are listening, the community will feel involved.

Engaging with the community has its pitfalls too. There may be differences of opinion within the community, and also between the maintainer and the community, especially when it comes to the matter of governance. Governance is something which is really important for an open source project to have. That is why it is important to have clear documented governance practices, which also include the community.

Community governance is a tough, but essential, nut to crack. Delegation in itself requires a lot of trust. For a project with millions of lines of code, it can be cumbersome to find someone in the community who can meaningfully lead it. But open source projects often consist of smaller sub-projects, which are better left handled by someone from the community. This helps the community to be more closely involved too.

| - |
| :- |
| Building a community always has its highs and lows. Let me list some of the tricks that helped maintain a healthy balance between the community’s and my team’s vision.
State your principle: Especially in the early stage of the open source project when the source code is still coming together and things are not exactly going perfectly, it is hard for somebody coming from outside to really understand why you are making the decisions that you are making. Communicating the principles on which you take actions helps you to be upfront about your thought process so that the community does not interpret things incorrectly.
This practice is really helpful. It is also important to follow through and show that when you make a decision, it is guided by one of these principles.
Decide how you are going to collaborate: This may be through channels like Discord, Slack, or simply emails. But if you try to use all of them, you will immediately diffuse the community. People will be communicating with each other all over the place. Choose one or two collaboration tools, and really invest in them for synchronised communication.
Treasure the feedback: Listen to feedback from the community and act on it. Show tat you care about what the community says, even if it requires you to make tough decisions.
Maintain a code of conduct: If you interact with a community, you need to define what is going to be acceptable conduct. Having that in place helps warn people in case they go out of line. You can avoid a lot of trouble if you can just define this early on.
Think about how you will distribute your project: There may be instances when you may not be willing to make your project available to the public because you do not have a certain component in place, or you have features you may not want to make accessible to everyone. Creating distribution terms that suit your preference without compromising on what the user wants is key, so that people who want certain features can access these while those who can do without them also have the option to start using the project without having to compromise.
Avoid polls as much as you can: This is because, often, certain members vote for an option that may not be what the majority goes with. This can create a sense of failure in these members and make them feel excluded from the project. Instead, try asking them what problems they would like to be solved, and then try to invent a solution that does not involve trade-offs. |

**State your principle:** Especially in the early stage of the open source project when the source code is still coming together and things are not exactly going perfectly, it is hard for somebody coming from outside to really understand why you are making the decisions that you are making. Communicating the principles on which you take actions helps you to be upfront about your thought process so that the community does not interpret things incorrectly.

This practice is really helpful. It is also important to follow through and show that when you make a decision, it is guided by one of these principles.

*Decide how you are going to collaborate:* This may be through channels like Discord, Slack, or simply emails. But if you try to use all of them, you will immediately diffuse the community. People will be communicating with each other all over the place. Choose one or two collaboration tools, and really invest in them for synchronised communication.

*Treasure the feedback:* Listen to feedback from the community and act on it. Show tat you care about what the community says, even if it requires you to make tough decisions.

**Maintain a code of conduct:** If you interact with a community, you need to define what is going to be acceptable conduct. Having that in place helps warn people in case they go out of line. You can avoid a lot of trouble if you can just define this early on.

*Think about how you will distribute your project:* There may be instances when you may not be willing to make your project available to the public because you do not have a certain component in place, or you have features you may not want to make accessible to everyone. Creating distribution terms that suit your preference without compromising on what the user wants is key, so that people who want certain features can access these while those who can do without them also have the option to start using the project without having to compromise.

*Avoid polls as much as you can:* This is because, often, certain members vote for an option that may not be what the majority goes with. This can create a sense of failure in these members and make them feel excluded from the project. Instead, try asking them what problems they would like to be solved, and then try to invent a solution that does not involve trade-offs.

### Open source is licensing

Open source is about giving your users autonomy over how they want to use your software, and licensing provides just that. What’s great about an open source licence is that regardless of what you as a maintainer do, all your end users and stakeholders can always maintain a certain set of forks, which are important forks.

Licensing gives people the option to take the project into a different direction if they deem it fit. They have the right to create a fork, which results in a lot of amazing software being developed. Maintainers have more responsibility to listen to their community members and to run the project in a way that works for them.

It’s advisable to make use of the many licences available instead of setting your own terms separately, simply because stakeholders and users are usually familiar with commonly used licences, so you do not have to waste time explaining them. This also helps you to focus your energy on the other parts of the project.

### Finally, open source is a movement

Open source involves many, many dimensions and people. Most importantly, it is about understanding what these people want and creating an environment that encourages collaboration and transparency. It is about building communities that help to build the open source project the way they want it to be. The more opportunity maintainers create to let them do that, the better the product is and the more successful it gets.

Open source is all of these things and the more expansive view you take, the better you can leverage it. Think about how you can excel in every dimension of open source because, at the end of the day, there is no easy path to open source success.

--------------------------------------------------------------------------------

via: https://www.opensourceforu.com/2022/07/open-source-software-is-there-an-easy-path-to-success/

作者：[Jules Graybill][a]
选题：[lkxed][b]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出

[a]: https://www.opensourceforu.com/author/jules-graybill/
[b]: https://github.com/lkxed
[1]: https://www.opensourceforu.com/wp-content/uploads/2022/07/team-work-working-together-1.jpg