If you simply want to allow people to view your code, you can just upload it to GitHub or something similar.

By default, your work is copyright and you hold all rights, excluding those you give up to GitHub.

Open-Sourcing your project is all about choosing the license that you want your users to use.

Please, for the love of God, choose an existing license. Don't go out and try to make one yourself or mix and match. Not only do you open yourself up to liability but it just makes it harder for you to keep track of it.

Choosing a license is all about your personal preference and what your goals are. The two ends of the spectrum:

• MIT License: do whatever you want, so long as you attribute me. Most libraries use this license.
• GPL/AGPL: if you use my code, you must also release using GPL/AGPL or similarly appropriate license. Linux Kernel famously uses version 2. Linus Torvalds has issues with some of the terms in V3.

There is a lot of middle ground between these two philosophies. Most of the major licenses have seen some level of court cases. I personally use AGPL, which is often seen as one of the strongest, most restrictive, licenses.

I do not recommend releasing code to public domain. This often is a point of contention between OSS purists and OSS "spirit". I personally believe we're entering a new world of AI-driven content and I don't want more code feeding that beast.

The license is then copied and pasted to a LICENSE file at the root of your repo and, boom. You've open sourced your code.

Keep in mind: that commit (and all future commits) will be available under that license until your copyright expires, so long as that license exists in your repo. You cannot claw it back.

One word of advice: you aren't likely going to see a bunch of people downloading your stuff. So don't get your hopes up that you'll have people submitting bug reports or making PRs, etc. All of my projects are just for me to use with one or two people reviewing it for fun. All but one, anyway.

Just slap a LICENSE file at the root of your repo with your license of choice. Boom, its open source.

1. Create a source control repository containing all your code, and publish it to an online code forge. GitHub's docs might help with this: https://docs.github.com/en/get-started/start-your-journey
2. Choose an open-source license and add it to the repository as a LICENSE file. If you want to require any projects that build upon yours to be open-source too, the GNU GPL is a good choice. If you want to allow proprietary programs to include your library without releasing any source code other than that which is directly based on yours, the GNU LGPL is good for that. If you want to allow people to do whatever they want, even use all your code as the basis of a proprietary program without credit, the Unlicense is a good choice. There are a lot of licenses with different degrees of "copyleft" and attribution requirements in between. Technically publishing with a license file is all you need to do, but there are more things you should do.
3. Create a README text file describing what your program does, and instructing users on how to compile and run it. Consider including more detailed documentation on how to use it, as well.
4. Clean up your code and file layout so that it's as easy as is feasible for other programmers to understand.
5. Promote your project to whoever you think might find it useful!

A lot of people are recommending version control. While it's good practice, that isn't a requirement of sharing your code. If you want to make it really simple at first, add a License (as others have mentioned) and just post the code anywhere. Upload a tar archive to a website, use sourceforge or even lemmy.

Learning git would still be useful for you and potential contributors but it is not a requirement. Open source just means you share the source and explicitely provide a license for others to use and modify it

Open source software literally means that the source code is available to anyone. In GitHub, that just means that your repo is public rather than private. But your method technically doesn’t matter. You could publish to a forum if you wish. That’s still open source!

Free OSS just means that anyone is free to use and modify the source code for any purpose. The details are usually defined in a LICENSE file.

I feel like you’re really asking about the common practices and methods used in FOSS. Right? If so, that’s entirely up to you as the maintainer. As the project matures, you may attract other contributors which will in turn will motivate change to your tools and methods.

Start with what works for you. Model after similar projects if you wish. Adjust as change is needed.

If it's several python modules, then yes, choose a license and then contact pypi and see if you can distribute your modules through them.

One very important thing is that you have to make sure everything is ready for distribution: check your project will work (possibly starting with a blank VM), what its dependencies are, that the requirements.txt file is good and operational, that automated tests are available for people to run after installing, etc.

In other words, the ideal project is not just a question of license but also all the scaffoldings you supply with it.

Thanks for opening your code!

Adding to what other people said, I want to suggest using the Blue Oak Model License. It is comparable to the MIT license (so no copyleft) but much more readable and easier to understand.