Best practices on building open source initiatives?

In an effort to attract top technical talent, i'm currently looking into setting up an internal open source program for the startup i'm currently working at. I'm currently in the research stage, so any advice, success stories, horror stories, guides or various resources any one has would be super useful.

1) Know your return. It may be technical (build a capability), development (build leadership), it may be recruiting (that's a bit shakier), it may be to enable your solution/ improve customer ability to use/ adopt your product, it may grow the market (e.g., USB eliminated complexity for hardware peripherals), it may weaken a competitor's advantage (e.g., Linux vs. Windows servers, Android vs iOS)

2) Have a strong leader with a perspective. 70% of open source contributions comes from a small group building something great. The crowdsourced thing gets talked about a lot but rarely actually works without real leadership, direction, and evangelism. There are some good Linux examples floating out there.

3) Develop predictable time/ funding for operations so it has time to develop legs. Beginning will almost always be slow and crappy (sometimes led by a PR hype spike)

Open source is a funny beast. You are providing to everyone complete access to internal work. Some items to think about:

1. How core is the tech? Are you releasing your secret sauce that your competitors can leap frog you with. There is a certain Built to Last cultural point about enforcing continued tech innovation by deliberately doing this, but it should be an explicit decision.

2. How big and who is the audience? What other fields benefit? How much and where should marketing occur? A major selling point for staff is fame and professional exposure from the publication. Who are they getting famous with? Is this a major yearly conference or a quarterly tech talk. If no one knows your open source, it benefits you and your staff little. How much marketing is needed? Affordable?

3. Estimate commercial benefit and costs. Having a slew of beta testers and bug report writing users of your infrastructure software not on your budget equates to much reduced demployment costs. Keeping said beta testers happy incurs support costs even if it is just developer time.

4. Corporate open source is most valuable as an asset with the modular extensions that can accommodate most any package interfacing with it. Accept a FSF license with copyright transfer and have competitors reduce maintenance costs by publishing to you that rare package adapter you can't even evaluate before this adapter is written.

5. Wish I didn'the have to add this. Certain organized crime groups target open source projects faster than proprietary. Keep a heavy hand on the red button if systemic hacker activity starts appearing in your user base. However, this applies to a lesser extent to all software these days.

If your goal is to find and attract talent look for existing open source projects to engage in and potentially sponsor. Good open source projects tend to attract like minded passionate people. Be visible and make it known that working for uou lets them get paid to chase their passion.

What do you want to mean by "open source program"? Are you planning on creating a new open source project that your startup will use? Are you planning on allowing your people to contribute to an existing platform that your business uses? Any such open source program should ultimately have some benefit to your business. Simply using this as bait to lure developers without the fruits of their labors ultimately benefiting your business process or product isn't going to ultimately help you any.