The announcement of SAP as a Black Duck customer and (omagosh!) a user of open source brought some surprised reactions from the press, including my dear editor Julie Bort. In her article Even SAP is using more open source, Julie finds it odd that a company that "loves software patents" 
Patent issue aside, it's rarely obvious to people why a traditional software company would "do open source." As per articles from Kathleen Lau and Joab Jackson, like many companies, SAP has come around to this position. SAP's open source program director, Claus von Riegen says they used to ask, "Why open source?" Now, they ask "Why not?"
SAP is certainly not alone in this. Numerous other ISVs as well as embedded systems companies and enterprise application development groups have gone there. The "Why" is pretty clear: With open source they can leverage other people's resources to get your work done!
1. Consuming: Using other people's code
Typically companies are lead by their developers to conclude that one can't ignore the treasure trove of code freely available on the Internet. There are hundreds of thousands of projects and billions of lines of code eager to be used. Always under pressure to develop faster, cheaper, better, developers try leverage these pre-built, often well-tested components to speed their development. By using other people's code for non-differentiating purposes, developers can focus their efforts on the things that make their products and applications special. Ultimately management catches up with their engineering teams and (after they get over the initial shock) put policies, processes and tools in place to monitor and control.
2. Contributing: Using other people's support
Managed well, the above development strategy works like a champ, but raises the question of support. In many cases a vibrant community around a project will provide plenty of support, however sometimes a company's own developers will find and fix an issue thus creating a situation whereby their version of the component has effectively been forked from the mainstream version. The best strategy is to contribute the fix back to the community. This is not a charitable act; it's justified by business needs. If the fix stays proprietary, then every time a new version of the component is released, someone has to reapply the fix. Contributing it back does benefit others, but more importantly relieves the company of that burden.
3. Creating: Using other people's developers
The behavior for a proprietary company that surprises people the most is contributing substantial software to open source projects or perhaps even initiating open source projects. The motivation is pretty simple: If the technology is not differentiating, then it is rational for companies to share the development burden with others. Whether it is a commoditized capability (as in the open core business model such as that followed by Collabnet or IBM with Websphere) or an internal tool, if it's not the thing that makes people go "Wow" about your product or business then it may be worth even giving up some IP for the sake of getting other people's developers to help you out.
When it comes to open source, don't be surprised to hear companies in the know are asking, "Why not?"