How to start and run an Open-Source project.
Let's take a look 👇🧵
Let's take a look 👇🧵
If you have never Open-Sourced a project before, the whole thing might feel very intimidating.
You probably fear what people will say? Will they throw shade at your project? Will it even be noticed at all?
You’re not alone in feeling this way. Believe me!
You probably fear what people will say? Will they throw shade at your project? Will it even be noticed at all?
You’re not alone in feeling this way. Believe me!
🔸 Finding a problem to solve
Most popular projects have a clear goal of solving a problem.
There are exceptions, but generally, great Open-Source projects consist of ready-made solutions to a problem that you can easily consume or incorporate into your own software.
Most popular projects have a clear goal of solving a problem.
There are exceptions, but generally, great Open-Source projects consist of ready-made solutions to a problem that you can easily consume or incorporate into your own software.
Did you notice that there are certain recurrent issues that you solve in the same way every time?
Maybe you have found yourself digging into old projects to snatch that piece of the code that solved it the last time, and carry it on to your new project?
Maybe you have found yourself digging into old projects to snatch that piece of the code that solved it the last time, and carry it on to your new project?
These are obvious queues that you should consider Open-Sourcing your solution.
Instead of trying to invent a new problem - simply try to look into the existing projects, and identify the problems you have.
Instead of trying to invent a new problem - simply try to look into the existing projects, and identify the problems you have.
🔸 Creating a solution
Formulate a simple, novel solution to your problem, and make a simple, clear-cut API with good self-explanatory names.
You want to consider as many scenarios as possible - also scenarios that you may not encounter in exactly your own projects.
Formulate a simple, novel solution to your problem, and make a simple, clear-cut API with good self-explanatory names.
You want to consider as many scenarios as possible - also scenarios that you may not encounter in exactly your own projects.
A generally recommended practice is to formulate an outline of your solution first.
Create all the function signatures that you expect your API to have, and maybe start drafting the documentation first, so you get an overview of the structure.
Create all the function signatures that you expect your API to have, and maybe start drafting the documentation first, so you get an overview of the structure.
Make it easy to contribute to.
When creating the solution, keep in mind that the codebase is written for other contributors as well.
Spend time writing clean, readable, and concise code.
Make comments where you find that it makes sense.
When creating the solution, keep in mind that the codebase is written for other contributors as well.
Spend time writing clean, readable, and concise code.
Make comments where you find that it makes sense.
🔸 Creating an outstanding Readme
This part is central and really important.
As a bare minimum, the Readme should describe the motivation for creating the solution and explain how to use it.
This part is central and really important.
As a bare minimum, the Readme should describe the motivation for creating the solution and explain how to use it.
However, keep in mind that you’re also “selling” this solution.
It is in your best interest that people will use it, improve and contribute to it and star it on GitHub.
It is in your best interest that people will use it, improve and contribute to it and star it on GitHub.
To make the Readme appealing and intuitive, I suggest including:
🔹 Banner/graphic
🔹 Badges (from shields .io)
🔹 Table of content
🔹 Illustrations and code-snippets
🔹 List of technologies used
🔹 Banner/graphic
🔹 Badges (from shields .io)
🔹 Table of content
🔹 Illustrations and code-snippets
🔹 List of technologies used
🔸 Create a contribution guide
I recommend covering the following points:
🔹 Issues
The preferred format of reporting a bug or requesting a feature
🔹 Pull Requests
The preferred way to create a PR, including which base branch and branching/naming conventions to use.
I recommend covering the following points:
🔹 Issues
The preferred format of reporting a bug or requesting a feature
🔹 Pull Requests
The preferred way to create a PR, including which base branch and branching/naming conventions to use.
It’s also highly recommended to do a PR checklist:
An example could be:
- I ran all unit tests, and they are passing
- I wrote new unit tests if appropriate
- I install the client locally and tested it manually
- I updated the version in package.json
An example could be:
- I ran all unit tests, and they are passing
- I wrote new unit tests if appropriate
- I install the client locally and tested it manually
- I updated the version in package.json
🔸 Package and publish
If you’re writing a project in JavaScript, you would package and publish the project using npm.
Again, keep the ease-of-use in focus.
The consumer should be able to install and get started with a minimum of configuration and initial procedures.
If you’re writing a project in JavaScript, you would package and publish the project using npm.
Again, keep the ease-of-use in focus.
The consumer should be able to install and get started with a minimum of configuration and initial procedures.
When you release a new version of your project, you will have to label it with a version number.
The version format that is most widely known and accepted is ‘semver’, which stands for Semantic Versioning.
It follows the format: MAJOR.MINOR.PATCH
semver.org
The version format that is most widely known and accepted is ‘semver’, which stands for Semantic Versioning.
It follows the format: MAJOR.MINOR.PATCH
semver.org
🔸 Licensing
When you create a new Open-Source project, it is highly recommended to include a license.
This license guarantees that contributors can clone, use, and alter the source code without facing legal repercussions.
When you create a new Open-Source project, it is highly recommended to include a license.
This license guarantees that contributors can clone, use, and alter the source code without facing legal repercussions.
Choosing the right license for your project can feel like dreary legal work.
But don’t overcomplicate this - in most cases, you’re good picking either MIT or Apache 2.0.
Unless you’re working under special circumstances, I suggest picking MIT and getting on with the project.
But don’t overcomplicate this - in most cases, you’re good picking either MIT or Apache 2.0.
Unless you’re working under special circumstances, I suggest picking MIT and getting on with the project.
🔸 GitHub’s Community Standards
Make sure you can check off all items on GitHub’s Community Standards checklist.
You can find this by going to Insights -> Community.
Make sure you can check off all items on GitHub’s Community Standards checklist.
You can find this by going to Insights -> Community.
Of course, then there's promoting the project and creating awareness about it.
That's an entire topic on its own and is not very different from promoting any other projects or products.
I'll cover that in another thread 😊
That's an entire topic on its own and is not very different from promoting any other projects or products.
I'll cover that in another thread 😊
Open-Source is carrying so many benefits and opportunities, whether you're looking for a career boost or improving sales in your business.
Don't miss out!
Also - make sure to like and retweet the first tweet so we can get this one around 🤩 Thank you!
Don't miss out!
Also - make sure to like and retweet the first tweet so we can get this one around 🤩 Thank you!
• • •
Missing some Tweet in this thread? You can try to
force a refresh
