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


Masao Taniguchi
 

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
follows;
----------------------------------------------------------------------
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.

[Question]

(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)

Regards,

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


Agustin Benito Bethencourt <agustin.benito@...>
 

Masao-san,

thanks for sharing your case and thoughts.

On Tuesday, 16 April 2019 02:58:49 CEST Masao Taniguchi wrote:
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 ]
The bad news is that the solution will take time. The good one is that some
others have walked part of your journey and are sharing part of their results.

I think that your idea matches well with what is commonly known as
InnerSource[1], that is kind of... Open Source behind your firewall.

In my view, InnerSource should be combined with doing Open Source in order to
really achieve all the benefits that communities, consensus, transparency and
freedom brings to software development organizations.

In any case, you might start reading this article from GitHub that is popular:
https://resources.github.com/whitepapers/introduction-to-innersource/

This free eBook from O'Reilly might help too: https://www.oreilly.com/
programming/free/getting-started-with-innersource.csp?intcmp=il-prog-free-
product-na_new_site_getting_started_with_innersource_text_cta

Practicioners are getting together. This is an example: http://
innersourcecommons.org/ There are others.

At OSCON there was an InnerSource day last edition: https://
conferences.oreilly.com/oscon/oscon-or-2018/public/schedule/full/innersource-
day I have good references from that event. I assume they will repeat it next
year. There are similar actions in Europe, at least.

Please let me know if this is of any help. Did you know about InnerSource?

<snip>

[1] https://en.wikipedia.org/wiki/Inner_source

Best Regards
--
Agustín Benito Bethencourt
Principal Consultant
Codethink Ltd
We respect your privacy. See https://www.codethink.co.uk/privacy.html


Dirk Riehle
 

Dear Masao Taniguchi:

You are talking about what is commonly called inner source these days.

You may enjoy our summary of ten years of inner source case studies here:


Best, Dirk


On Tue, Apr 16, 2019 at 3:06 AM Masao Taniguchi <m-taniguchi@...> wrote:
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
follows;
----------------------------------------------------------------------
 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.

[Question]

(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)

Regards,

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

_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain


Dirk Riehle
 


On Tue, Apr 16, 2019 at 1:19 PM Dirk Riehle <dirk@...> wrote:
Dear Masao Taniguchi:

You are talking about what is commonly called inner source these days.

You may enjoy our summary of ten years of inner source case studies here:


Best, Dirk

On Tue, Apr 16, 2019 at 3:06 AM Masao Taniguchi <m-taniguchi@...> wrote:
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
follows;
----------------------------------------------------------------------
 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.

[Question]

(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)

Regards,

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

_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain


 

Hi Taniguchi San!

Your suggestions seem to match pretty well with what Agustin and Dirk mentioned. I think the resources they listed are useful to get started.

If there is anything I can do to assist please let me know. I’m happy to visit your offices if useful.

Regards

Shane 

On 16 Apr 2019, at 20:21, Dirk Riehle <dirk@...> wrote:


On Tue, Apr 16, 2019 at 1:19 PM Dirk Riehle <dirk@...> wrote:
Dear Masao Taniguchi:

You are talking about what is commonly called inner source these days.

You may enjoy our summary of ten years of inner source case studies here:


Best, Dirk

On Tue, Apr 16, 2019 at 3:06 AM Masao Taniguchi <m-taniguchi@...> wrote:
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
follows;
----------------------------------------------------------------------
 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.

[Question]

(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)

Regards,

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

_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain
_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain


Masao Taniguchi
 

Hi Agustin, Dirk, Shane, and all.

I really appreciate your sharing resources very enlightening indeed.
The information you shared was what I needed and absolutely
eye-opening.

(Sorry for delayed reply, it took time a little bit to watch/read up ,
and understand the contents. )

Dear Agustin,
Thanks for sharing the white paper. This may be very basic
but very important notion. and so that this is really well organized,
this may be good to be translated and published (if it's welcome).

And yes, I know the word "Inner sourcing" itself, but I didn't know
What really means.

I agree with the WP, "However, innersource also requires a cultural shift. "
This is so true. it's a big challenge and it's important to
start with small projects.

Dear All,
I understand "OSS way" well, I think.
So I've just thought the "Inner sourcing" is to bring OSS way into
behind firewall. But this understanding is not enough, I found
because;

1. Actually "OSS way" is very limited notion internally, and sometimes
allergic word for somebody (as implied in P27 of the Dirk's
slides) , so in not a few cases, starting with "OSS way" doesn't work, I
think.

2. Essentially this is about redundancy and efficiency that lead to
productivity, quality or safety. This must to be starting point
to be discussed internally, I think.

Besides these above, I found this "Inner sourcing" is very
critical role of so called Open Source Program Office. Not only
inbound/outbound supply chain, we really need to care "inside"
organization. (I desire that Openchain focus on much more)

Dear Dirk,
Your video/slides also gave me practical insights through live case
studies and your experience.

The diagram in P26 was excellent.

In case of system integrator, platform tends to vary according to
customer and it's difficult to fix/consolidate commonly. The layer
on top of PF is what to be discussed here.

(and P27 is really true ;)

Dear Shane,
Finally, asking the Openchain community was the very right path for me,
this is fantastic.

Inner sourcing is a good way as a first step because the term "open
source " can be sometimes allergic as mentioned above.

Thank you again to all in Openchain initiative.

Regards,




On Thu, 18 Apr 2019 07:10:09 +0900
Shane Coughlan <scoughlan@...> wrote:

Hi Taniguchi San!

Your suggestions seem to match pretty well with what Agustin and Dirk mentioned. I think the resources they listed are useful to get started.

If there is anything I can do to assist please let me know. I’m happy to visit your offices if useful.

Regards

Shane

On 16 Apr 2019, at 20:21, Dirk Riehle <dirk@...> wrote:

And here are the slides:

https://dirkriehle.com/2018/05/16/slides-for-keynote-at-inner-source-commons-summit-at-bosch/

Cheers, Dirk


On Tue, Apr 16, 2019 at 1:19 PM Dirk Riehle <dirk@...> wrote:
Dear Masao Taniguchi:

You are talking about what is commonly called inner source these days.

You may enjoy our summary of ten years of inner source case studies here:

https://dirkriehle.com/2018/07/05/ten-years-of-inner-source-case-studies-video/

Best, Dirk

On Tue, Apr 16, 2019 at 3:06 AM Masao Taniguchi <m-taniguchi@...> wrote:
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
follows;
----------------------------------------------------------------------
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.

[Question]

(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)

Regards,

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

_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain
_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain


Oliver Fendt
 

Hi Taniguchi San,

 

your ideas perfectly make sense. We have an internal code sharing platform running since 3 years now.

Some important point I want to share with you on that:

1. Keep internal shared code clean – meaning please do not mix open source code into an internal shared package. This is important for calculation reasons (in case you have to do calculations for tax reasons, please see point 2).

2. if you intend to provide the code sharing also to units located in other countries please care about:

                ECC (Export control and customs)

                Tax issues (like transfer pricing)

3. check with your lawyers whether there need to be something implemented to protect the employees. In some countries it is not allowed to collect personal data which can be used to measure the performance of employees

 

Ciao

Oliver

 

Von: openchain-bounces@... <openchain-bounces@...> Im Auftrag von Shane Coughlan
Gesendet: Donnerstag, 18. April 2019 00:10
An: Dirk Riehle <dirk@...>
Cc: OpenChain <openchain@...>
Betreff: Re: [OpenChain] How do we encourage collaborative development INTERNALLY? (so far)

 

Hi Taniguchi San!

 

Your suggestions seem to match pretty well with what Agustin and Dirk mentioned. I think the resources they listed are useful to get started.

 

If there is anything I can do to assist please let me know. I’m happy to visit your offices if useful.

 

Regards

 

Shane 


On 16 Apr 2019, at 20:21, Dirk Riehle <dirk@...> wrote:

 

On Tue, Apr 16, 2019 at 1:19 PM Dirk Riehle <dirk@...> wrote:

Dear Masao Taniguchi:

 

You are talking about what is commonly called inner source these days.

 

You may enjoy our summary of ten years of inner source case studies here:

 

 

Best, Dirk

 

On Tue, Apr 16, 2019 at 3:06 AM Masao Taniguchi <m-taniguchi@...> wrote:

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
follows;
----------------------------------------------------------------------
 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.

[Question]

(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)

Regards,

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

_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain

_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain


Masao Taniguchi
 

Hi, Fendt san

Thank you so much for additonal infomation.

1. Keep internal shared code clean ?
Yes. I think this may be basic notion as OSS compliance, but this is
NOT simple task.

It is necessary to put organization, processes, tools and talent (even
policy itself....

#Agustin's comment was right, this initiative will take time....

By the way, How did you start to build internal sharing platform 3 years ago?
(Top down approach or bottom up ? and so on...)
and what was the most important point to promote your inner sourcing?

2. if you intend to provide the code sharing also to units located in other countries please care about:
ECC (Export control and customs)
Tax issues (like transfer pricing)
3. check with your lawyers whether there need to be something implemented to protect the employees. In some countries it is not allowed to collect personal data which can be used to measure the performance of employees

Thanks, I'll keep in my mind.
These are also to be considered as following steps.
(Currently, my concern is about "the 1st step" ,
I surely have a goal, but I don't know how to reach the goal)

Regards,
M.Taniguchi


On Thu, 18 Apr 2019 08:06:09 +0000
"Fendt, Oliver" <oliver.fendt@...> wrote:

Hi Taniguchi San,

your ideas perfectly make sense. We have an internal code sharing platform running since 3 years now.
Some important point I want to share with you on that:
1. Keep internal shared code clean ? meaning please do not mix open source code into an internal shared package. This is important for calculation reasons (in case you have to do calculations for tax reasons, please see point 2).
2. if you intend to provide the code sharing also to units located in other countries please care about:
ECC (Export control and customs)
Tax issues (like transfer pricing)
3. check with your lawyers whether there need to be something implemented to protect the employees. In some countries it is not allowed to collect personal data which can be used to measure the performance of employees

Ciao
Oliver

Von: openchain-bounces@... <openchain-bounces@...> Im Auftrag von Shane Coughlan
Gesendet: Donnerstag, 18. April 2019 00:10
An: Dirk Riehle <dirk@...>
Cc: OpenChain <openchain@...>
Betreff: Re: [OpenChain] How do we encourage collaborative development INTERNALLY? (so far)

Hi Taniguchi San!

Your suggestions seem to match pretty well with what Agustin and Dirk mentioned. I think the resources they listed are useful to get started.

If there is anything I can do to assist please let me know. I’m happy to visit your offices if useful.

Regards

Shane

On 16 Apr 2019, at 20:21, Dirk Riehle <dirk@...<mailto:dirk@...>> wrote:
And here are the slides:

https://dirkriehle.com/2018/05/16/slides-for-keynote-at-inner-source-commons-summit-at-bosch/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdirkriehle.com%2F2018%2F05%2F16%2Fslides-for-keynote-at-inner-source-commons-summit-at-bosch%2F&data=02%7C01%7Coliver.fendt%40siemens.com%7C5e8b3ce252784c318c9708d6c3824252%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C636911361558425846&sdata=j1pyM0tJ%2BCSfqjExD%2FbxFnQDNc6fVwHSEaRjURX5OEk%3D&reserved=0>

Cheers, Dirk


On Tue, Apr 16, 2019 at 1:19 PM Dirk Riehle <dirk@...<mailto:dirk@...>> wrote:
Dear Masao Taniguchi:

You are talking about what is commonly called inner source these days.

You may enjoy our summary of ten years of inner source case studies here:

https://dirkriehle.com/2018/07/05/ten-years-of-inner-source-case-studies-video/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdirkriehle.com%2F2018%2F07%2F05%2Ften-years-of-inner-source-case-studies-video%2F&data=02%7C01%7Coliver.fendt%40siemens.com%7C5e8b3ce252784c318c9708d6c3824252%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C636911361558435851&sdata=csfIMMKra2lPoB2A2h7rtk0oMMPk7z1U6UmWlKeBSMI%3D&reserved=0>

Best, Dirk

On Tue, Apr 16, 2019 at 3:06 AM Masao Taniguchi <m-taniguchi@...<mailto:m-taniguchi@...>> wrote:
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
follows;
----------------------------------------------------------------------
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.

[Question]

(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)

Regards,

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

_______________________________________________
OpenChain mailing list
OpenChain@...<mailto:OpenChain@...>
https://lists.linuxfoundation.org/mailman/listinfo/openchain<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Fopenchain&data=02%7C01%7Coliver.fendt%40siemens.com%7C5e8b3ce252784c318c9708d6c3824252%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C636911361558435851&sdata=qKt1l%2Bd%2BONZBCAzVuphwFBpq1e0V%2BcdcAXAa%2FyBb25U%3D&reserved=0>
_______________________________________________
OpenChain mailing list
OpenChain@...<mailto:OpenChain@...>
https://lists.linuxfoundation.org/mailman/listinfo/openchain<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Fopenchain&data=02%7C01%7Coliver.fendt%40siemens.com%7C5e8b3ce252784c318c9708d6c3824252%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C636911361558445860&sdata=5iy2nEpnFuQ2r95%2FoIdH8Ao3B6g5TxbXTc7RLkNjZDM%3D&reserved=0>


JerryTan
 

Hi, Taniguchi,
As Dirk and Agustin suggest , You can refer to https://innersourcecommons.org/
There are more than 100 companies which have adopting InnerSource in their companies and they have shared many best practice for that.

As the fist step to begin InnerSource, I suggest that you can start from a pilot project,
Here is some requirements for this pilot project
1. the project is used by many or has the potential to be popular inside the company
2. the owner for the project is a community guy, like to share,help and cooperate
3. the project is Modularity, so It will be easy for other to contribute.

Work with the owner of project, opensource its source code inside the company, and call for contribution from its users.

And of course, it needs a tool like github or gitlab to support issue/pull request/wiki etc.
Hope it can works.

BTW: OSCON 2019 has one day event called InnerSource Day, hosted by InnerSourceCommons.org, you can attend it if needed.


在 2019/4/19 上午8:16,“openchain-bounces@... 代表 Masao Taniguchi”<openchain-bounces@... 代表 m-taniguchi@...> 写入:

Hi, Fendt san

Thank you so much for additonal infomation.

> 1. Keep internal shared code clean ?

Yes. I think this may be basic notion as OSS compliance, but this is
NOT simple task.

It is necessary to put organization, processes, tools and talent (even
policy itself....

#Agustin's comment was right, this initiative will take time....

By the way, How did you start to build internal sharing platform 3 years ago?
(Top down approach or bottom up ? and so on...)
and what was the most important point to promote your inner sourcing?

> 2. if you intend to provide the code sharing also to units located in other countries please care about:
> ECC (Export control and customs)
> Tax issues (like transfer pricing)
> 3. check with your lawyers whether there need to be something implemented to protect the employees. In some countries it is not allowed to collect personal data which can be used to measure the performance of employees


Thanks, I'll keep in my mind.
These are also to be considered as following steps.
(Currently, my concern is about "the 1st step" ,
I surely have a goal, but I don't know how to reach the goal)

Regards,
M.Taniguchi


On Thu, 18 Apr 2019 08:06:09 +0000
"Fendt, Oliver" <oliver.fendt@...> wrote:

> Hi Taniguchi San,
>
> your ideas perfectly make sense. We have an internal code sharing platform running since 3 years now.
> Some important point I want to share with you on that:
> 1. Keep internal shared code clean ? meaning please do not mix open source code into an internal shared package. This is important for calculation reasons (in case you have to do calculations for tax reasons, please see point 2).
> 2. if you intend to provide the code sharing also to units located in other countries please care about:
> ECC (Export control and customs)
> Tax issues (like transfer pricing)
> 3. check with your lawyers whether there need to be something implemented to protect the employees. In some countries it is not allowed to collect personal data which can be used to measure the performance of employees
>
> Ciao
> Oliver
>
> Von: openchain-bounces@... <openchain-bounces@...> Im Auftrag von Shane Coughlan
> Gesendet: Donnerstag, 18. April 2019 00:10
> An: Dirk Riehle <dirk@...>
> Cc: OpenChain <openchain@...>
> Betreff: Re: [OpenChain] How do we encourage collaborative development INTERNALLY? (so far)
>
> Hi Taniguchi San!
>
> Your suggestions seem to match pretty well with what Agustin and Dirk mentioned. I think the resources they listed are useful to get started.
>
> If there is anything I can do to assist please let me know. I’m happy to visit your offices if useful.
>
> Regards
>
> Shane
>
> On 16 Apr 2019, at 20:21, Dirk Riehle <dirk@...<mailto:dirk@...>> wrote:
> And here are the slides:
>
> https://dirkriehle.com/2018/05/16/slides-for-keynote-at-inner-source-commons-summit-at-bosch/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdirkriehle.com%2F2018%2F05%2F16%2Fslides-for-keynote-at-inner-source-commons-summit-at-bosch%2F&data=02%7C01%7Coliver.fendt%40siemens.com%7C5e8b3ce252784c318c9708d6c3824252%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C636911361558425846&sdata=j1pyM0tJ%2BCSfqjExD%2FbxFnQDNc6fVwHSEaRjURX5OEk%3D&reserved=0>
>
> Cheers, Dirk
>
>
> On Tue, Apr 16, 2019 at 1:19 PM Dirk Riehle <dirk@...<mailto:dirk@...>> wrote:
> Dear Masao Taniguchi:
>
> You are talking about what is commonly called inner source these days.
>
> You may enjoy our summary of ten years of inner source case studies here:
>
> https://dirkriehle.com/2018/07/05/ten-years-of-inner-source-case-studies-video/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdirkriehle.com%2F2018%2F07%2F05%2Ften-years-of-inner-source-case-studies-video%2F&data=02%7C01%7Coliver.fendt%40siemens.com%7C5e8b3ce252784c318c9708d6c3824252%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C636911361558435851&sdata=csfIMMKra2lPoB2A2h7rtk0oMMPk7z1U6UmWlKeBSMI%3D&reserved=0>
>
> Best, Dirk
>
> On Tue, Apr 16, 2019 at 3:06 AM Masao Taniguchi <m-taniguchi@...<mailto:m-taniguchi@...>> wrote:
> 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
> follows;
> ----------------------------------------------------------------------
> 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.
>
> [Question]
>
> (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)
>
> Regards,
>
> --
> Masao Taniguchi <m-taniguchi@...<mailto:m-taniguchi@...>>, Mr.
> NEC Corp.
>
> _______________________________________________
> OpenChain mailing list
> OpenChain@...<mailto:OpenChain@...>
> https://lists.linuxfoundation.org/mailman/listinfo/openchain<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Fopenchain&data=02%7C01%7Coliver.fendt%40siemens.com%7C5e8b3ce252784c318c9708d6c3824252%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C636911361558435851&sdata=qKt1l%2Bd%2BONZBCAzVuphwFBpq1e0V%2BcdcAXAa%2FyBb25U%3D&reserved=0>
> _______________________________________________
> OpenChain mailing list
> OpenChain@...<mailto:OpenChain@...>
> https://lists.linuxfoundation.org/mailman/listinfo/openchain<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Fopenchain&data=02%7C01%7Coliver.fendt%40siemens.com%7C5e8b3ce252784c318c9708d6c3824252%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C636911361558445860&sdata=5iy2nEpnFuQ2r95%2FoIdH8Ao3B6g5TxbXTc7RLkNjZDM%3D&reserved=0>

_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain


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.

Best,
Mark

-----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
follows;
----------------------------------------------------------------------
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.

[Question]

(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)

Regards,

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

_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain


Masao Taniguchi
 

Hi, Tan -san

Thanks for additional information and suggestion

As the fist step to begin InnerSource, I suggest that you can start from a pilot project,
Yes! this is what I can do as first step and more realistic approach.
My lead project is relatively small, but this is sometimes missing
pieces for many projects, they actually need the components to
accelerate their value proposition delivery which they really need to
focus.

1. the project is used by many or has the potential to be popular inside the company
Yes, I think so. it's not so competitive but many want to use commonly.

2. the owner for the project is a community guy, like to share,help and cooperate
It's me, maybe (Of course not only me, I am just a candidate).

3. the project is Modularity, so It will be easy for other to contribute.
Thanks, I missed this. I need to discuss with developer team.

Regards,


On Fri, 19 Apr 2019 02:03:16 +0000
tan zhongyi <zhongyi.tan@...> wrote:

Hi, Taniguchi,
As Dirk and Agustin suggest , You can refer to https://innersourcecommons.org/
There are more than 100 companies which have adopting InnerSource in their companies and they have shared many best practice for that.

As the fist step to begin InnerSource, I suggest that you can start from a pilot project,
Here is some requirements for this pilot project
1. the project is used by many or has the potential to be popular inside the company
2. the owner for the project is a community guy, like to share,help and cooperate
3. the project is Modularity, so It will be easy for other to contribute.

Work with the owner of project, opensource its source code inside the company, and call for contribution from its users.

And of course, it needs a tool like github or gitlab to support issue/pull request/wiki etc.
Hope it can works.

BTW: OSCON 2019 has one day event called InnerSource Day, hosted by InnerSourceCommons.org, you can attend it if needed.


?在 2019/4/19 上午8:16,“openchain-bounces@... 代表 Masao Taniguchi”<openchain-bounces@... 代表 m-taniguchi@...> 写入:

Hi, Fendt san

Thank you so much for additonal infomation.

> 1. Keep internal shared code clean ?

Yes. I think this may be basic notion as OSS compliance, but this is
NOT simple task.

It is necessary to put organization, processes, tools and talent (even
policy itself....

#Agustin's comment was right, this initiative will take time....

By the way, How did you start to build internal sharing platform 3 years ago?
(Top down approach or bottom up ? and so on...)
and what was the most important point to promote your inner sourcing?

> 2. if you intend to provide the code sharing also to units located in other countries please care about:
> ECC (Export control and customs)
> Tax issues (like transfer pricing)
> 3. check with your lawyers whether there need to be something implemented to protect the employees. In some countries it is not allowed to collect personal data which can be used to measure the performance of employees


Thanks, I'll keep in my mind.
These are also to be considered as following steps.
(Currently, my concern is about "the 1st step" ,
I surely have a goal, but I don't know how to reach the goal)

Regards,
M.Taniguchi


On Thu, 18 Apr 2019 08:06:09 +0000
"Fendt, Oliver" <oliver.fendt@...> wrote:

> Hi Taniguchi San,
>
> your ideas perfectly make sense. We have an internal code sharing platform running since 3 years now.
> Some important point I want to share with you on that:
> 1. Keep internal shared code clean ? meaning please do not mix open source code into an internal shared package. This is important for calculation reasons (in case you have to do calculations for tax reasons, please see point 2).
> 2. if you intend to provide the code sharing also to units located in other countries please care about:
> ECC (Export control and customs)
> Tax issues (like transfer pricing)
> 3. check with your lawyers whether there need to be something implemented to protect the employees. In some countries it is not allowed to collect personal data which can be used to measure the performance of employees
>
> Ciao
> Oliver
>
> Von: openchain-bounces@... <openchain-bounces@...> Im Auftrag von Shane Coughlan
> Gesendet: Donnerstag, 18. April 2019 00:10
> An: Dirk Riehle <dirk@...>
> Cc: OpenChain <openchain@...>
> Betreff: Re: [OpenChain] How do we encourage collaborative development INTERNALLY? (so far)
>
> Hi Taniguchi San!
>
> Your suggestions seem to match pretty well with what Agustin and Dirk mentioned. I think the resources they listed are useful to get started.
>
> If there is anything I can do to assist please let me know. I’m happy to visit your offices if useful.
>
> Regards
>
> Shane
>
> On 16 Apr 2019, at 20:21, Dirk Riehle <dirk@...<mailto:dirk@...>> wrote:
> And here are the slides:
>
> https://dirkriehle.com/2018/05/16/slides-for-keynote-at-inner-source-commons-summit-at-bosch/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdirkriehle.com%2F2018%2F05%2F16%2Fslides-for-keynote-at-inner-source-commons-summit-at-bosch%2F&data=02%7C01%7Coliver.fendt%40siemens.com%7C5e8b3ce252784c318c9708d6c3824252%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C636911361558425846&sdata=j1pyM0tJ%2BCSfqjExD%2FbxFnQDNc6fVwHSEaRjURX5OEk%3D&reserved=0>
>
> Cheers, Dirk
>
>
> On Tue, Apr 16, 2019 at 1:19 PM Dirk Riehle <dirk@...<mailto:dirk@...>> wrote:
> Dear Masao Taniguchi:
>
> You are talking about what is commonly called inner source these days.
>
> You may enjoy our summary of ten years of inner source case studies here:
>
> https://dirkriehle.com/2018/07/05/ten-years-of-inner-source-case-studies-video/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdirkriehle.com%2F2018%2F07%2F05%2Ften-years-of-inner-source-case-studies-video%2F&data=02%7C01%7Coliver.fendt%40siemens.com%7C5e8b3ce252784c318c9708d6c3824252%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C636911361558435851&sdata=csfIMMKra2lPoB2A2h7rtk0oMMPk7z1U6UmWlKeBSMI%3D&reserved=0>
>
> Best, Dirk
>
> On Tue, Apr 16, 2019 at 3:06 AM Masao Taniguchi <m-taniguchi@...<mailto:m-taniguchi@...>> wrote:
> 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
> follows;
> ----------------------------------------------------------------------
> 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.
>
> [Question]
>
> (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)
>
> Regards,
>
> --
> Masao Taniguchi <m-taniguchi@...<mailto:m-taniguchi@...>>, Mr.
> NEC Corp.
>
> _______________________________________________
> OpenChain mailing list
> OpenChain@...<mailto:OpenChain@...>
> https://lists.linuxfoundation.org/mailman/listinfo/openchain<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Fopenchain&data=02%7C01%7Coliver.fendt%40siemens.com%7C5e8b3ce252784c318c9708d6c3824252%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C636911361558435851&sdata=qKt1l%2Bd%2BONZBCAzVuphwFBpq1e0V%2BcdcAXAa%2FyBb25U%3D&reserved=0>
> _______________________________________________
> OpenChain mailing list
> OpenChain@...<mailto:OpenChain@...>
> https://lists.linuxfoundation.org/mailman/listinfo/openchain<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Fopenchain&data=02%7C01%7Coliver.fendt%40siemens.com%7C5e8b3ce252784c318c9708d6c3824252%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C636911361558445860&sdata=5iy2nEpnFuQ2r95%2FoIdH8Ao3B6g5TxbXTc7RLkNjZDM%3D&reserved=0>

_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain


Masao Taniguchi
 

Hi, Mark.

I appreciate your polite suggestion.

On Mon, 22 Apr 2019 04:56:04 +0000
"Gisi, Mark" <Mark.Gisi@...> wrote:

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).
I agree. Bazaar approach is sometimes bizarre to Cathedral culture.
When we talk in different languages, we should try to understand
each other carefully.

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.
Interesting and informative.
Some points are a little bit different , but basically my case is
similar to your case I think.

My project is categorized to so-called "DX (Digital transformation)"
which try to create/deliver practical values leveraging domain knowledge
through partnership.

Here, consumer (of value) 's needs become very changeable, erratic, so we
need to catch up the needs quickly and effectively.
IT system itself is also becoming less competitive. Here, Bazaar approach (I
call this OSS way ) comes on the stage.

But looking around, there are so many silo systems redundant and
fragmented. A few people notice the situation, but they don't know how
to solve or mitigate that.


(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.
Yes, that's the very case I'm seeing .


(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.
Thanks. this is also informative, and very well organized idea.
But honestly this seems as if this initiative have been already well
designed before it got started.

At the very beginning, the activity must have been very painful, sweaty,
troublesome, or simply hard one.

Following questions come up to my mind
(Just for reference. you don't need to answer)

- What type of people kicked off the initiative? How many?
- What was the trigger of that?
- How cross functional team was built?
- How did you convince the executives?
- What/how many resources (many, staff, tools) did you need, and how get
that resources?

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 "Three Es" is new to me. thanks.
But I don't understand well the difference in definition for each "E",
so far, I understand like this;

Enablement : Process and tools to embrace "Open Program"
Education : Educational materials to promote that
Evangelism : Promotion activities for potential internal users


The results have been fantastic - a surprising large percentage of
initiatives have reached the VALUE stage.
Yes, this is what I desire, really great practice.

and this also explains:

" Bazzar/Open source/inner sourcing approach encourage you to reach
the value you want to deliver to your customer(s) or society"



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.
This is also great. But you must have needed not a few cost
( money, man power, and mental power and so on) to build system, tools and
processes internally.
I believe that it would have been harsh activities to get approval
from executives.


<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.
Yes, what I implied here was "peer recognition".
Rewards like plaque or trophy can also be good motivation for developers,
but I would like to argue "the first step".

My idea is simply to start putting "Contributors list" file in gitlab
where we develop. By preparing this, everyone knows who knows the code, system
and project using the codes.

In the future quantitative evaluation may work but
currently we are not in a such stage.


<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.
Thanks. yes, this may seems to be weird for you...

A word "internal GPL" came up with me at first.
And I assumed that some enforcement of contribution might work to
improve code continuously.
Of course this is not legal issue, but just internal rules.

My concern is that internal free ride may deteriorate whole systems.
This is also bad thing next to redundancy or fragmentation. And if
contribution enforcement rule exists ;

1) Everyone can embrace software with quality maintained by many.
2) Many can learn OSS way, and they can work more collaboratively
externally more easily.

I don't know this is good approach. This may depend on how mature the
organization is.



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.
My finding in this thread was that it's not always right first step to
push "OSS" internally.

This is because many of people in the company (whether they are
executives, managers or whatever) don't understand benefit of OSS
because they haven't have chance to experience it.

So, beforehand to do so, it may be more important to show them the
benefit in/from their realm, perspectives, words and culture.

If you succeed, the organization may be ready to embrace OSS and
they can work with community globally (because they would have
experienced the benefit).

And yes, just posting code may not be enough to global communication,
but if inner sourcing is successful, they also ready to learn how to
collaborate with the community.

(I know this is so optimistic ... though)


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.

Best,

Feedback in this thread were all encouraging me.

My conclusion (so far) is clear, that's to make my project a pilot
project of inner sourcing, and explain its benefit, gather resources and
repeat the cycle continuously.

I appreciate all of feedback this community gave me.


Thanks again.
Regards,