There’s a big disconnect between developers and their employers, and the employers are going to lose as a result. According to a new DigitalOcean survey of more than 4,300 developers, 55% of those developers surveyed contribute to open source projects, but only 34% of companies afford them work time to do so. At least, if we define it as “open source related to their employment.”

SEE: IT Hiring Kit: Programmer (Tech Pro Research)

Too bad for those developers, right? Wrong. According to this same survey, roughly 75% of developers say their companies expect them to use open source as an integral part of their job, and rightly so: Open source increasingly offers a rich well of innovation from which developers can draw. Unfortunately, open source really isn’t a free lunch: The companies that contribute most derive the most value, and it’s not necessarily always clear what “relates to one’s employment” and what is a side project.

Breaking the (open source) piggy bank

It’s not surprising that so many developers want to participate in open source projects. Work can be a slog, but open source gives developers a great way to work on code that matters to them, helps them hone their coding skills, find community, and learn new things. Given the importance of software to the modern enterprise, every organization on the planet should be desperately giving their developers time to work on interesting open source projects. Unfortunately, they’re not.

SEE: How to build a successful developer career (free PDF) (TechRepublic)

According to this same DigitalOcean survey, 66% of developers have to work on open source in their spare time; or, rather, they’re only allowed to contribute to “work-related” projects during their work hours. But this is a weird premise, because it tries to draw hard lines where none may exist. Talking with one of the most active open source contributors at my company, for example, he told me that he works on all sorts of things that don’t directly relate to our business…yet. In the past he has started projects that have eventually become standard in our operations stack. A project that is a labor of love today can become an indispensable corporate tool tomorrow.

And even if it doesn’t, those people who contribute most, learn most. And things that a developer learns supporting parts of Debian, for example, just might be directly applicable to her work supporting the company’s dependence on Linux.

It’s great that companies increasingly recognize the value of open source to their businesses. It’s less great that they can’t seem to make the connection on the need for developers to be able to work on open source code as much or more than they write internal, proprietary code. As developer Matt Quirion put it to me, “I honestly have no idea how I’d even do my job without open source. That’s been true for at least 10 years.”

What’s also been true for some time is that the companies that give most to open source, get most from open source.

You get what you give

One way of looking at open source is as a piggy bank from which an enterprise can continuously take code, give nothing back, and come out ahead. It turns out this doesn’t work nearly as well as the alternative: Contributing back to the projects that matter most for a particular organization.

SEE: One million Linux and open-source software classes taken (ZDNet)

Indeed, as Harvard Business School professor Frank Nagle found in a research study, “paying employees to contribute to [open source] software boosts the company’s productivity from using the software by as much as 100%, when compared with free-riding competitors.” How so? Not only do developers gain insight into a project’s direction, as well as the ability to influence that direction in ways that are advantageous to their employers, but they also gain superior knowledge and skills from the process. He further finds that “learning by contributing is…a powerful source of competitive advantage.”

Free riding yields none of these benefits.

Enterprises are right to overwhelmingly want their developers working on open source; they are wrong to overwhelmingly want them to figure it out in their spare time. Any organization serious about software needs to get equally serious about contributing to open source projects.