At Cloudera (company) we regularly work on open source code right along side our competitors. I tend to joke that the engineers at our competitors are effectively our coworkers. Since the question specifically asks about how one deals with code (rather than the working relationship) I’ll focus on that. Honestly though, that’s probably the less interesting part.
In (almost) all ways, our engineers shed their “Cloudera hat” in favor of their “community hat” when working on what we refer to as the upstream code bases. I say “almost” because there are also things they retain:
The interesting bit is the switching of hats. When an employee is working with their “community hat,” their job is to represent and work on behalf of the open source community. With the exception of the bullets above, their concern is for the best interest of the project and community. I’m positive the same is true of our competitors. We all contribute code as individuals, not agents of a company (again, modulo the bits we must retain).
So, in this sense, no code is written by competitors. We have no competitors when working on open source code. When we pull changes from the upstream projects back into Cloudera products, it’s uniformly treated as “upstream changes.” We don’t differentiate between whom it was written (except maybe when it breaks something, in which case there’s the obligatory witch hunt ;)). This works because upstream code is always contributed under a license that permits us (and our competitors) to do this. In Cloudera’s case, that’s almost exclusively the Apache Software License. Copyright is granted to the Apache Software Foundation on Apache projects, making life pretty simple.
Interacting with employees that work for competitors is a different discussion. Generally, it’s a nonissue; I’d count many of them as friends, in fact. You’ll see us co-present technical talks with competitors, thank each other in technical publications, review material for one another, hang out together at conferences, and grab coffee together. As with any coworkers, you get along better with some than others, but that’s no surprise. As with most human interaction, it’s important to evaluate principles before personalities; close your eyes, evaluate what is being said on its merits, and cast any prejudices about the other individual aside. Sometimes people we don’t like have great ideas, and that’s perfectly ok.
I don’t speak for all Cloudera employees here, although I hope they would agree. This is my opinion. I do, however, do my best in my role as an engineering manager to encourage others to think and act this way, as do many others at Cloudera.