- Forces you to decouple them from other internal systems.
- Encourages thinking in terms of reusable modules, which is better for internal reuse just as much as public reuse.
- Possibility of contributions to systems useful to your business by others.
- Easier reuse within your organisation (the public internet is a better search and sharing system than any internal systems).
- Reputation advantages, the best coders often like to work in open and forward-thinking companies, and having public shared code is a great sign of such an organisation.
- Preferably push your very first commit straight to github.
- Do it before it has a chance to be tightly coupled to internal systems, otherwise you'll have to unpick it and it will be less decoupled from day one, and inertia might mean that in spite of the best intentions you then never publish it.
- You'll have it in mind that every commit is public from day one, avoiding adding internal config etc and forcing you to factor it out into config which is all round a good thing.
- Don't wait for your code to be perfect, there are compromises in all code and sharing something imperfect is better than sharing nothing.
Worried about the brand?
- Commit under personal email addresses and push to personal github accounts. You can always setup a corporate github account later when you are feeling more confident.
Of course I'm not saying you should open source everything, for example your core product's codebase should probably not go on github if you are a product company!
--
Be brave, be open.
Props to Tom Loosemoore
No comments:
Post a Comment