Ask HN: Best practices for open sourcing your project?
3 comments
In line with the "release early, release often" mantra, you can just go ahead and do it.
Secrets are usually split into separate "configuration" repositories that remain private, and that's the only gotcha.
Any other time you invest in beautifying your code, writing documentation, stripping ads and making them configurable, might be in vein: most open source projects do not attract any contributors, yet having these "easy pickings" is also stimulating for someone to contribute.
Your users are better served having an ability to tinker with the code than waiting for the code to become nicer. At least, the free software persona in me says so :)
Secrets are usually split into separate "configuration" repositories that remain private, and that's the only gotcha.
Any other time you invest in beautifying your code, writing documentation, stripping ads and making them configurable, might be in vein: most open source projects do not attract any contributors, yet having these "easy pickings" is also stimulating for someone to contribute.
Your users are better served having an ability to tinker with the code than waiting for the code to become nicer. At least, the free software persona in me says so :)
* focus on documentation. Good documentation is the thing that differentiates good open source from bad open source.
* separate out all things external. This includes services, dependencies, and especially ads. Manage them like managing a foreign business partner.
* provide a demo tool if applicable.
* focus on code organization. My applications are well organized large files. This scares the shit out of people who don’t really read code but is preferred by people who do read code, so know your audience. I would rather a drastically smaller audience of higher quality interested people but that makes your application appear less popular.
* automate everything. If automation is not a primary consideration your code is just a toy.
* everything is broken. Encourage challenging critical feedback
* separate out all things external. This includes services, dependencies, and especially ads. Manage them like managing a foreign business partner.
* provide a demo tool if applicable.
* focus on code organization. My applications are well organized large files. This scares the shit out of people who don’t really read code but is preferred by people who do read code, so know your audience. I would rather a drastically smaller audience of higher quality interested people but that makes your application appear less popular.
* automate everything. If automation is not a primary consideration your code is just a toy.
* everything is broken. Encourage challenging critical feedback
I should say, I'm also open to any resources like articles/podcasts/talks on this topic.
I've been working on https://algodaily.com for the better part of a year now, and would like to open source both the curriculum and platform.
Aside from taking the current spaghetti code and beautifying it, are there any suggested practices for opening up a formerly private repository? I'm wondering about things like secrets management, ads (I have ads on the hosted site, should I remove them from the public repo?), how much documentation to write before shipping, etc.
Appreciate any advice!