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


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>

Join main@lists.openchainproject.org to automatically receive all group messages.