Re: How do we encourage collaborative development INTERNALLY? (so far)

Mark Gisi

Hi Masao,

Sorry for the delayed follow up. We have had success employing Open Development principles to solve a similar problem. I would not categorize it so much as Inner Source, but more as Open Innovation. Although I believe the basic premise behind Inner Source is good, one needs to be careful on how far they should promote it (e.g., as a product development method). Using "Cathedral and the Bazaar" terminology - the reason is the "Bizarre" approach often conflicts with a Cathedral culture (and way of doing things). We chose the Agile/Scrum method for product development because our products are developed on a highly predictable schedule that depend on a predictable set of resources (e.g., staffing). We use Open Development to drive grassroots innovation where schedules are not a consideration. The objective is not so much about establishing an internal open source-like culture, but more of an innovation culture that empowers anyone at any level to be an innovator. It leverages the best of open development without the culture challenges.

(1) Does my idea make sense? what do you think about that?
Yes, I believe your observations hold true for many companies - in that, there will be duplicated efforts in developing similar technologies by different individuals or groups (silos). It is human nature to want to - as they say in the open source world - "scratch an itch" - i.e., come up with solutions (code) for problems that make their job easier (or pursue a curiosity) . Typically different employees encounter similar problems and simultaneously come up with common solutions. Unfortunately, often no common platform, policy process (formal program) exists to facilitate collaboration. Having access to a shared software forge (e.g., github, Atlassian's stash) is necessary but far from sufficient.

(2) Is there someone who already adopt similar approach
internally? ( I really appreciate if we share that)
As I explained above we encountered a similar situation and decided to turn it into an opportunity by implementing a "grassroots" innovation program, built on Open Source collaboration principles. Although we have a formal R&D department, the program allows everyone to participate in the R&D process (if they choose). We intentionally framed the problem as an Open "innovation" program to i) to more easily win senior management support which is necessary for the success of any internal program; and ii) convey to employees they can more directly make an impact. Although the program is run by our Open Source Program Office, and largely fosters software innovation; it supports more than software (e.g., business processes, hardware, technical report creation, "for fun" marker projects, ...).

Anyone in the company can post a solution which we track through three stages: (1) IDEA - an idea is posted for everyone to view, discuss, and potentially contribute; (2) PoC - a proof of concept (pilot) is created (potentially in collaboration with others); and (3) VALUE - the point where the innovation makes an impact on the company - e.g., new tool used by "multiple" groups; new product features; exciting tradeshow and customer demos; new contributions to open source projects (e.g., Linux kernel, yocto, openstack,...); a presentation delivered at a conference and so forth.

In additional to being an open program, three pillars critical to its success are the "Three Es": Enablement, Education, and Evangelism. "Enablement" - we maintain a system that openly tracks each innovation, provide each initiative with a webpage, git repository, mailing list, dashboard (to track progress through the three stages), and so forth. "Education" - a five minute video on how to get started plus a simple web form to make it easy to submit new ideas (or propose challenges for others). "Evangelism" - We spend A LOT of time fostering companywide visibility for the different projects, providing different levels of recognition awards for initiatives that produce different levels of value (VALUE stage), posting success stories on the program's web portal, ...

The results have been fantastic - a surprising large percentage of initiatives have reached the VALUE stage. Employee participation has been growing exponentially over the past three years largely due word of mouth and seeing others (openly) succeed at it. The participants are enthusiastic to: have their progress tracked, obtain visibility and have their impact formally recognized. Although about 80% plus of the projects are source code based, some have introduced new processes and hardware solutions. For instance, a proposal to leverage OpenChain conformance to help communicate trust as part of our product's value proposition, was a marketing initiative that was tracked through the three stages.

<Idea 1>: Record developers names?
Peer recognition is a critical open development motivator. I think this is a good start but much more can (and should) be done. For example, provide formal ways to recognize different milestone accomplishments - e.g. we award developers with different levels of Innovator achievement (accommodated by a plaque or trophy). We announce new initiatives and recent success stories in quarterly newsletter letters. We are about to award our annual ('Nobel Style') Innovator award to be presented by the CEO. Many will take notice which typically results in increased participation.

<Idea 2>: License internally?
It is not clear to me why this is needed. Internally we allow anyone to access/download the different solutions being tracked. There is no need to grant permission (the main purpose of a license). If an initiative is chosen to become an Open Source contribution, we work with a business sponsor to select the appropriate open source license for external consumption - otherwise a license is a non-issue.

Step 3: Publish the code and improve it by global collaboration (i.e. OSS)
This generally represents an important level of recognition - however to make any new project successful requires a lot of people resources and time to build a health community (global collaboration). It is not trivial - just publically posting code is typically not sufficient. Contributing code to an existing OSS project often provides " a greater bang for the buck". Regardless it is important to support both.

I believe you have the right idea, but a lot of work awaits you. Your greatest challenges will be organizational (as opposed to technical). First and foremost, try to win over top management from day one. You might find management more responsive to an emphasis on a program focused on increasing innovation and collaboration. Lots of metrics can be generated along the way to highlight the program's success. All in all, this is a topic I see a lot of exciting potential (i.e., When the Open Source Office is Responsible for Innovation). I would be happy to share more experiences, practices and supporting software - feel free to email me directly.


-----Original Message-----
From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Masao Taniguchi
Sent: Monday, April 15, 2019 5:59 PM
To: OpenChain
Subject: [OpenChain] How do we encourage collaborative development INTERNALLY? (so far)

Dear Shane, and OpenChain experts members,

Hello, I'm Taniguchi from NEC corp.
I don't know this posting is appropriate, but I'm so glad to hear your
opinion about;

How do we encourage collaborative development INTERNALLY
and what's do you think about strategic approach to do that?

[Current Problems observed in my projects]

- We are system integrator in Japan (which has so many employees)
- In some cases systems/architectures/source codes exist
for similar purpose and they are sometimes redundant and fragmented .
- And in worse cases, even non-competitive ones are developed
internally and they are also redundant/fragmented.
- And additionally, copyright declaration and contributors names
aren't written in many case in materials.

[What I feel]

1) Redundancy and fragmentation are evil, they should be consolidated
and share and maintain it collaboratively
2) Non-strategic ones should be published and shared for everyone
(of course under appropriate license)

[My idea ]

To encourage more collaborative development, I try to put 3 steps as
Step 1: Develop code and improve it through PoC etc by project team.
Step 2: Share the code and improve it by internal collaboration
Step 3: Publish the code and improve it by global collaboration (i.e. OSS)

Here, my focus point is the "Step 2".

<Idea 1>: Record developers names?
Write down copyright description Contributors name on project materials.
--> by doing this, developers become visible internally, and such
credits may become incentives and may encourage their creativity.

<Idea 2>: License internally?
To avoid fragmentation, internal licensing approach may work.
(Of course this is not legal issue but just internal rule, though).

Some cases, even copyleft-like approach may work, I feel.
Many internal projects can re-use resources, and besides that
such resource can be improved efficiently, effectively.

And by doing above, Shift to Step 3 (Publishing as Open Source) may
become much easier.


(1) Does my idea make sense? what do you think about that?
(2) Is there someone who already adopt similar approach
internally? ( I really appreciate if we share that)


Masao Taniguchi <m-taniguchi@...>, Mr.
NEC Corp.

OpenChain mailing list

Join to automatically receive all group messages.