Open Source is a term indicating the source code of a program is made publicly available. This allows users to modify and redistribute that software. Making your Git repo open source requires several steps, including deleting all of the source code from it and creating another repository with it. Here’s how to make that happen.
Now that you’ve created your repository and added a README, it’s time to add an open source license. Without a license, your code is automatically protected by copyright and no one may copy, distribute, or modify your work without being at risk of take-downs, shake-downs, or litigation. Once you have software in the public domain through an open source license, anyone can copy, distribute, or modify your work for any purpose and without restrictions.
Find Your Motivation
It is almost impossible to game the GitHub Trending section:
GitHub’s definition (of trending) takes into account a longer term definition of trending and uses more complex measurement than sheer number of stars which helps to keep people from farming the system.
Founders often create startups based on problems they have personally encountered. With open-sourced code, you will likely be trying to solve problems that developer commonly have.
And since gaming the GitHub Trending section is almost impossible, you need a strong motivation – a big, common developer problem – to work on. So how do you stumble onto a developer problem?
Well, for starters you can participate in hackathons, build projects, and experiment with other projects. And you will soon find something which could be made into a library, something you could make a utility out of, and so on.
Your motivation for building your project could come from anywhere. In my case, I explore new Machine Learning papers daily on arXiv (an open-access archive for papers) and read the ones I find interesting. One such paper I read motivated me to build my Python package.
Another time, I was in a hackathon training a Machine Learning model and wanted to participate in other festivities. Our team then decided to build another open-source project called TF-Watcher.
So you see, you’ll likely find all sorts of issues you can work on when you’re building a project.
And just to note – when I say you should have a strong motivation, I do not mean the project should be really huge or really complex. It could certainly be a simple project that could make developers’ lives easier.
Think about it this way: if there was a project like the one you want to develop, would you use it? If the answer is yes, you have enough motivation to build the project, regardless of the size or complexity.
A man in Oakland, California, disrupted web development around the world last week by deleting 11 lines of code. —Keith Collins in How one programmer broke the internet by deleting a tiny piece of code
You might know about
left-pad , a very small open-source npm package with just 11 lines of straightforward code. But it was used by tons of developers around the world, which just reinforces what I was talking about above.
Writing your contributing guidelines
A CONTRIBUTING file tells your audience how to participate in your project. For example, you might include information on:
- How to file a bug report (try using issue and pull request templates)
- How to suggest a new feature
- How to set up your environment and run tests
In addition to technical details, a CONTRIBUTING file is an opportunity to communicate your expectations for contributions, such as:
- The types of contributions you’re looking for
- Your roadmap or vision for the project
- How contributors should (or should not) get in touch with you
Using a warm, friendly tone and offering specific suggestions for contributions (such as writing documentation, or making a website) can go a long way in making newcomers feel welcomed and excited to participate.
First off, thank you for considering contributing to Active Admin. It’s people like you that make Active Admin such a great tool.
In the earliest stages of your project, your CONTRIBUTING file can be simple. You should always explain how to report bugs or file issues, and any technical requirements (like tests) to make a contribution.
Over time, you might add other frequently asked questions to your CONTRIBUTING file. Writing down this information means fewer people will ask you the same questions over and over again.
Link to your CONTRIBUTING file from your README, so more people see it. If you place the CONTRIBUTING file in your project’s repository, GitHub will automatically link to your file when a contributor creates an issue or opens a pull request.
Does a similar project or tool already exist?
If it has not been done yet, and there’s a need for it, go ahead and start building it.
If something similar exists, is well developed, and is heavily used too, you might want to move on.
There are a huge number of open-source projects out there already, and it is quite common to find a repository doing similar stuff (more common than you would think). But you can still work on your project and make it better.
Mobile Verification Toolkit
Developed by Amnesty International Security Lab, Mobile Verification Toolkit or MVT is a collection of utilities to automate gathering of forensic traces used in identifying potential threats on Android or iOS devices. It was released recently in the context of the Pegasus project.
For iOS devices, MVT helps extract artifacts from iTunes backup and full filesystem dump. It also compares stored JSON results to provide indicators. For Android devices, MVT downloads all or non-safelisted installed APKs and checks the Android backup.
Using the MVT tool requires technical skills including understanding the basics of forensic analysis and using command line tools.
In order to install MVT, first install the dependencies using the following code:
For Linux: sudo apt install python3 python3-pip libusb-1.0-0
For MacOS: brew install python3 libusb
Post this, one can either directly install MVT from pypi with: pip3 install mvt
Or directly from sources:
git clone https://github.com/mvt-project/mvt.git
If something similar does exist, can your project make it better?
If something similar exists, your goals could be to make it more modular or more efficient. You could try implementing it in some other language or improve it in any other number of ways.
A great way to do so is to take a look at the issues for the existing repository. Try doing your research with existing solutions (if there are any) and find out what aspect of the project could possibly be improved. Your work could even be a derivative of the other project.
In my case, as I mentioned, I took inspiration from an interesting research paper I read (Fastformer: Additive Attention Can Be All You Need). I also discovered an official code implementation and a community implementation of the paper, both in PyTorch.
Tinode Instant Messaging Server
The Tinode Instant Messaging Server, on the surface, looks similar to WhatsApp or Telegram. Backed in pure Go, it is meant as a replacement for XMPP and Jabber. Its goal is to create a modern open platform for federated instant messaging, focusing on mobile communication. Additionally, in line with the recent controversies around privacy concerns, Tinode Instant Messaging Server aims to create a decentralised instant messaging platform that would be challenging for the government to track and block.
How to Develop Your Project’s Repo
You might have heard the popular quote:
Any fool can write code that a computer can understand. Good programmers write code that humans can understand. —Martin Fowler
If people can not understand your code, they will not use it.
I’ve noticed in my own repositories that, when I spend more time trying to make things simple and easy to use, those projects end up getting more traction. So try to spend the extra time making your project more usable and intuitive.
As a general rule of thumb while developing your repo:
- You should include a license when you launch an open-source project. This allows people to use, copy, modify, and contribute back to your project while you retain the copyright. You can easily find a license suitable for your project at https://choosealicense.com/.
- Create a good README: there’s a whole section about this next because it is super important.
- Use consistent code conventions and clear function/method/variable names. You can often use some static code analysis tool like black, ktlint, and so on.
- Make sure your code is clearly commented, document your thoughts, and include edge cases.
- Make sure there are no sensitive materials in the revision history, issues, or pull requests (for example, API keys, passwords, or other non-public information).
- If you are developing an app/library, I would recommend that you use GitHub releases. Try maintaining clear release notes and changelogs each time you make a new release so the community can track what is new. Record what bugs were fixed, and so on. Here is a great repo showing this.
- Finally, you should also include contributing guidelines in the repository that tells your audience how to participate in your project. You can include information on the types of contributions you are expecting or how to suggest a feature request or bug report and so on.
The exercise has been created to detail how to open source a repo in GitHub, by sharing the folder, which contains the Python scripts, used to web scrape and analyze Stack Overflow survey data.