I have a client who is requiring that the meteor app we built for them be open source and available to the public.
Are there any special steps or setup that people recommend before making all the code public? All of my settings files are already excluded from the repo.
For example what about the .meteor/.id file?
Thanks!
@pikachu I saw your post about oorja.io (great job!), any lessons learned that you would be willing to share?
That sounds like a pretty cool client! 
Just make sure to not publish any api keys, I think that’s about it.
According to .meteor/.id itself, it looks like it’s meant to be public:
This file contains a token that is unique to your project.
Check it into your repository along with the rest of this directory.
It can be used for purposes such as:
- ensuring you don’t accidentally deploy one app on top of another
- providing package authors with aggregated statistics
Hi @sagannotcarl, oorja is a minimal working product as of now with a long way to go. There are way bigger open source projects like RocketChat that you can draw inspiration from. I’d say focus on these areas:
Licensing:
There are many open source licenses available with varied conditions/restrictions, pick something appropriate and discuss with your client. https://choosealicense.com/ is a good place to explore licenses.
Documentation is king:
Documentation, tooling and communities are the lifelines of an open source project imo.
Write an excellent readme. What is it about? How to run it ? How to deploy it? How can one contribute ? etc.
Try to give maximum value with minimum friction.
Share your product in appropriate channels and gather feedback. All the best !
@herteby They are a very cool client! It’s actually even cooler than that, it’s a non profit that received a grant from a foundation and that foundation made open-sourcing the project a requirement of the grant!
@pikachu Thanks this is very helpful.
I think that the MIT license is probably going to work for them.