Strategy for Trusting your Employer in Open Source: a Historical Approach

<p>In today's world everyone just gets open source ... at least you don't have to explain what it is any more. However, the way a corporation runs is based on transaction needs rather than deep philosophical beliefs, so Open Source and your place within a corporation (and often your value to it) depend on your ability to translate between these two positions. This talk aims to equip modern open source developers with the ability to navigate this translation effectively. And, although the transaction nature means trust is fleeting, constantly adjusting to the transactional needs can build fleeting trust into a longer term reliance.</p> <p>Although Linux isn't the first open source project, it is the first one to begin successfully co-opting corporations into its development model. In the beginning Linux was a wholly volunteer operation that leaked into corporate data centres via subversive means. When the leak became a flood those in charge of the data centres reluctantly blessed Linux deployment to avoid being swept away. This meant that all the ancillary producers (drivers for hardware, databases, industrial applications etc.) all had to come to Linux on its own terms (which we, the Linux community hadn't actually thought about at the time). It also meant that relationships that began completely antagonistically usually ended up being harmonious (yesterday's enemy almost always became today's friend). The result was a years long somewhat collaborative project to develop rules of engagement between open source projects and corporations.</p> <p>This talk will cover three things that came out of these rules of engagement:</p> <ol> <li> <p>agency: a corporation deals with open source through its developers at the code face. They are empowered to make decisions on its behalf way beyond any proprietary developer ever was and this empowerment changes the internal as well as external dynamics of employer to employee interaction.</p> </li> <li> <p>Mutual Development: As an open source contributor you become responsible for deciding what's best for the project (and persuading your employer to agree).</p> </li> <li> <p>Strategic misalignment: although corporations understand that they have to do open source, internally there's often an uneven penetration of how to do it. Thus a significant part of a good open source employees time is spent doing internal alignment to make sure internal lack of comprehension doesn't get it the way of sound execution.</p> </li> </ol> <p>We'll give examples of how to leverage these rules, an understanding of which will allow you to build a shifting transactional trust between you want your employer.</p>