Ask Slashdot: Corporate Open Source Policy? 57
Phiro69 (3782875) writes Does anyone have any best practices/experience they would like to share on how their corporate entity put Open Source Software out on the Internet? Historically at my engineering firm, we've followed a model where we internally build a 1.0 release of something we want to open source, the product owner and legal perform a deep review of the release, and we push it out to a platform like Github where it typically sits and rusts.
Our engineering interns have started down a new path: Using Github from the beginning (I set the repo private), and, after a bare minimum is completed, flipping the repo public and continuing development in the open using Github. How do PO and Legal reviews fit in? How can we ensure we're not exposing ourselves or diluting our IP if we're doing semi-constant development, publicly, sans a heavily gated review process? What does everyone else do? Or does corporate America avoid this entire opportunity/entanglement/briar patch?
Our engineering interns have started down a new path: Using Github from the beginning (I set the repo private), and, after a bare minimum is completed, flipping the repo public and continuing development in the open using Github. How do PO and Legal reviews fit in? How can we ensure we're not exposing ourselves or diluting our IP if we're doing semi-constant development, publicly, sans a heavily gated review process? What does everyone else do? Or does corporate America avoid this entire opportunity/entanglement/briar patch?
CLA (Score:4, Insightful)
Having a solid Contributor License Agreement process in place would probably be a good idea. That way, it's clear who owns the code that comes in and encourages people to contribute while defining a (necessary evil) process for doing so. You'll lose random passers-by, but just one passer-by who gets litigious could be more of a headache than it's worth.
Waaaay too general. (Score:4, Insightful)
Your question is far too generalized. You don't mention what your product is, what your firm does, or what the risks you're trying to protect from. Nobody can give you any meaninful advice unless you provide real details. What is it you're afraid of exposing? What's the IP you're afraid of diluting? Is your company a 100 person shop, or a 10,000 person shop? It matters.
Those risks may be illusory, depending on what this code is. I've had a few project I'd like to release as OSS, but there's zero IP dilution and zero risk of exposing anything. Despite what people tend to think, code isn't a commodity. The specifics matter quite a bit. The only answers you're going to get with the information you provided are very generalized useless ones.
Re:Rust (Score:4, Insightful)
One issue is that generally such projects are actually pretty niche and get developed with only that niche in mind. There simply isn't a pool of eager developers to tackle only your specific issue.
If you can think about modularity and develop some key components that are more generally useful as distinct projects, you may have better luck.
But overall, open source building a large development community for any given single project is generally the exception rather than the rule, even if you do your best. Even very ubiquitous projects that play a role in nearly every linux system often has maybe one or two developers that are really familiar with it.
Before planting a seed, prepare the field (Score:3, Insightful)