Successful open-source projects focus on consumption and contribution. Mature open-source frameworks provide a structure for community contribution with equal say over project direction, features and goals as well as simple consumption so that non-programmers can leverage the project quickly and easily.

In Enterprise software development, projects are typically written and maintained by the same team.

In open-source, projects are started by one-team but can be maintained by anyone. If done correctly, projects can be developed in a way that makes them easy to consume and easy to contribute to.

Ever developed a tool or application in an Enterprise only to find another team building almost exactly the same thing? Ever written a utility library and finding nobody is using it?

Well, then there's probably a lot you can learn from projects like Open-Stack, Apache, Python Software Foundation on how to build a community of users and building a community of contributors.

Typically, when people reach an open-source project, they ask 3 questions

1. What does it do?
2. What state is it in?
3. Can I use it?

Before you start working on the code, you need to consider how you answer those questions. The fewer clicks and text they have to read, the more users' are likely to use your project and contribute back!

Check out come cool examples:

• Apache Libcloud
• Mantl.io
• Terraform

Sharing the source code doesn't make your project open-source, in-fact that's the easiest part of the process. Open source software is made available for anybody to use or modify, as its source code is made available. Consider those modifications, do you want each one to be in isolation or would you rather your project benefits from all the changes made downstream?

Open-Source projects need a structure to allow contributions from anyone in the community to be successful. Accepting changes comes with plenty of additional questions that need answering:

• How do you regulate the project direction?
• How do you ensure consistency in the API, code and style of the project?
• How do you keep the documentation up to date?
• How do you make sure your project is stable if you're not contributing all the changes?

• Section 1 - [Structuring your project](doc/project structure.md).

• Licensing - [Choosing an open-source license](doc/choosing a license.md)
• README - [Writing a good README file](doc/writing a readme.md)

• Section 2 - [Maintaining consistency](doc/maintaining consistency.md).

• Securing branches - [Configuring GitHub to follow PR practice](doc/maintaining consistency.md#protecting-branches)
• Linting - [Linting](doc/maintaining consistency.md#choosing-a-linter)

• Section 3 - [Managing contributions](doc/managing contributions.md)

Contributions to this project are welcome, raise a pull-request if you want to make a contribution or raise an issue if you wish to highlight a mistake or error.

This project is distributed under the Creative Commons Zero 1.0 Universal license.

N/A