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


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

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