As banks move from a consumption-oriented open source posture to one that embraces
the value of active contribution, their open source policies will likely need to change, too.

Compared to inbound open source policies, outbound policies often start out short and
insurmountable, perhaps simply requiring C-level
approval for any external contribution.

There’s no such thing as an ideal open source policy—each policy must be tailored to a firm’s structure, processes and culture—but effective policies share some common features:

• Communicating continuously and effectively between the departments with oversight over some aspect of contributions. A rigid pipeline approval process—e.g. first technical leadership, then business leadership, then legal—is a recipe for delay and developer frustration. Create a formal or informal cross-department team that meets regularly to discuss upcoming and in-progress contributions.
  
  
• Categorizing contributions by risk level. Fixing a bug to a text-processing library is a fundamentally different type of open source contribution—in both scope and risk profile—than open-sourcing a major, previously internal software project. A policy that subjects them both to the same review process is wasteful. A good policy will identify common categories of contributions—taking into account the significance of the contribution, the characteristics of the external project (Does it relate to a core business function? Is it controlled by a competitor?), and the importance of the business need—and tailor the scrutiny and approval level accordingly.
  
  
• Delegating as much approval authority as possible. The further up the chain of command approval is required, the busier the arbiter and the more removed from the technology. Once contributions have been effectively categorized by risk level, approval of low-risk contributions can be left close to the teams that produced them. If this is done right, legal often won’t even have to get involved in the review process.
  
  
• Flexibility to adapt to unforeseen requests. Attempting to exhaustively account for every case in advance will yield a too-rigid policy (that may never make it through the drafting process). A flexible policy will first incorporate only common, obvious categories, but will set out a clear and expeditious process for considering unaccounted-for cases, with the responsibilities of participants well-defined.

As the financial services industry engages more actively with open source communities, the benefits it derives from open source will multiply. The Symphony Software Foundation is committed to fostering this productive collaboration—look for open source readiness initiatives from us soon!