[Pattern Draft] Outsourced development ecosystem

patterns/1-initial/outsourced-development-ecosystem.md

@@ -0,0 +1,74 @@
+## Title
+
+Outsourced Development Ecosystem
+
+## Patlet
+
+The burdens of existing contracts in an outsourced environment constrains the success of the
+InnerSource initiative. Outsourced companies may see this as a risky situation as they have to
+way to share knowledge, resources, and expertise with competitors within the mother company.
+The legal contracts typically forces to develop software in a very specific and silo-ed way.
+Redefining these rules and allowing outsourced companies would bring a more InnerSource-friendly
+way of working.
+
+## Problem
+
+Current outsourced environments in large corporations prevent those suppliers to work in an
+InnerSource way. This includes a transparent, collaborative, and community-oriented way.
+Beyond the implications of the cultural change, and process focus, most of the limitations are
+given by the existing legal framework that forces the outsourced development to charge a fee
+per hour and within a very specific project. There are not specific agreements to allow
+a collaborative way of working across the organization and across outsourced companies or contractors.
+
+## Context
+
+Large corporation with a big variety of outsourced companies and contractors that produce part
+of the code base of this company. Each company or contractor has its own legal contract in place
+that states the goals, the pricing schema, and the expected outcome and output for the organization.
+
+No collaboration happens at the outsourced company or contractor level and each of them are working
+in a silo-based mode with no interactions with others, but the mother company.
+
+## Forces
+
+* Legal teams and outsourced companies trying to avoid risk exposure and responsibilities.
+* Legal implications and responsibilities when something goes wrong.
+* SLAs in place forcing behaviors.
+* Managers losing control of the situation by having more collaboration across companies borders
+
+## Solutions
+
+* Governance model:
+  * Better definition of who owns the code and the data produced and if possible owned by the
+    mother company.
+  * Definition of checks and balances of who is responsible for what action (RACI) and SLAs against PRs.
+  * Definition of tools and processes so suppliers do not bring extra complexity to other suppliers.
+* Flexibility in the legal contracts to allow them to contribute with other companies,
+  even when they are competitors.
+  *  Declaration of the supplier with other suppliers.
+  *  Onboarding new suppliers.
+  *  Relationship across developers.
+  *  Budget management.
+* Good practices should be enforced in the contracts with those companies or contractors.
+  As an example:
+  *  Good documentation practices.
+  *  Code should be hosted in a collaborative platform every company and contractor is able to reach
+     out to it
+  *  State pull request / change request as the by-default way of working and communication.
+  *  Avoid private developments and releases of tons of lines of code, keep a transparent way of
+     across companies or contractors.
+* Train the mother company POs to work with several suppliers within the same project.
+* Define clear and fair guidelines across internal outsourced companies to avoid internal friction.
+* Skill up your suppliers on InnerSource practices
+* Resources discussions may be part of the conversation at some point, be sure to define the limitations
+  of their interactions within other existing projects.
+
+## Resulting Context
+
+Outsourced companies and contractors are safe to collaborate with other competitors as collaboration
+rules are clear, common processes and tools are in place, and the legal framework of each participant
+allows to move into this direction.
+
+## Author(s) (optional)
+
+## Acknowledgments (optional)