What are the things you should pay extra attention to when you're about to release a library, framework or the code of your entire company as open-source? So far I've come up with documentation, licensing, double checking every secret is removed from the code. From the #GreaterThanCode podcast I've learnt that hospitality and welcoming others are quite important. What do you think I shouldn't forget?
@remcoboerma If you go on github to the "insights" tab of the project and then to something like "community", you should see a nice checklist of things to add, like license and code of conduct.
This kind of falls under "welcoming", but if you want it to be open source in the sense of accepting contributions, then clear instructions on how to contribute will be helpful. For example: where should feature requests and bugs be reported and what information needs to be included in reports? What are the steps and requirements involved in submitting a pull request? (e.g. Does it need to be proposed and discussed in an issue first? Who should be asked to review, and what sorts of reviews/approvals are required? Who merges the PR when it's done? If using Git or similar, do you allow rewriting history with rebases?)
Also a couple random things:
The development hub (Github page or similar) should be prominently linked from the documentation. It shocks me how often this is not the case.
Make sure the documentation clearly explains what the project does and why a person would want to use it. Preferably front and center at the beginning of the README file.
@diazona
Absolutely important things to consider. Thanks for sharing! I'll work through all of it. It surely is so easy to forget some of this stuff in your own projects.
@remcoboerma Oh yeah, definitely. I am working through this right now as well with a project that a collaborator and I recently started, so I'm learning from this thread as well.
For Python projects specifically, there are benefits to using a skeleton project like https://github.com/jaraco/skeleton (which is not the only one, but probably the most popular). I have some philosophical disagreements with how that particular skeleton does things and I'm not sure the work required to change them is worth it, so I'm not sure I'd literally use it again myself, but if nothing else it's certainly a good source of inspiration for things to think about in your own projects.
I'll go through all of it. We already have repositories that are several years old so it's not that were starting something new.
Because of that, I'll probably have to create a shallow copy of just one branch - just to make sure no secrets were spilled in old commits that a bot would find in a second.
Unless there is a scanner to scan my own repo, might try that first to keep history. 🤔
@remcoboerma Ah, well... I'm pretty sure there are such scanners 😀 I mean, if you know what secrets you want to remove from the repo, you can use git-filter-repo (https://github.com/newren/git-filter-repo) to strip them out of the history. Or if you're looking for something that will automatically detect secrets, that I'm less familiar with but I know there are tools that detect various patterns indicative of secrets in other contexts, so I bet something exists for Git. All this is to say, I think the scanner angle is worth a look.
Add comment