Date   

Quick Reminder: Please Sign Up for the OpenChain Newsletter

Shane Coughlan <coughlan@...>
 

Dear all

This is a reminder that the OpenChain Newsletter is getting a revamp. It will be managed by LF Marketing on a quarterly schedule moving forward. They would love to have as many people as possible register ahead of the first issue - covering Q1 - and have provided a quick link to accomplish this:
https://www.openchainproject.org/news/newsletter

The new schedule and distribution will align us with other Linux Foundation Projects and make it easier to include OpenChain news in cross-LF outreach.

Regards

Shane

--
Shane Coughlan
General Manager, OpenChain
e: coughlan@...
p: +81 (0) 80 4035 8083
w: www.openchainproject.org

Schedule a call:
https://calendly.com/shanecoughlan


OpenChain Specification 2.0 now live - PR tomorrow - Pre-PR request

Shane Coughlan <coughlan@...>
 

Dear all

OpenChain Spécification 2.0 is now live in English on our site:
https://www.openchainproject.org/spec

And is the new default on the Self-Certification web app:
https://certification.openchainproject.org/

I plan to begin large scale PR tomorrow. Prior to this I wanted to ensure our community had a chance to check everything looks good on your end (computer, tablet, language used, etc). Do let me know :)

Regards

Shane

--
Shane Coughlan
General Manager, OpenChain
e: coughlan@...
p: +81 (0) 80 4035 8083
w: www.openchainproject.org

Schedule a call:
https://calendly.com/shanecoughlan


Re: OpenChain Specification 2.0 - Request for Translation - Chinese

SZ Lin (林上智)
 

Hi Shane,

<snip>

Can we include a fix tomorrow so we can match OpenChain Spec 2.0 release in
English?
By all means, the PR was already resent after fixing up.

Thank you for your reminder.

SZ


Regards

Shane

On Apr 22, 2019, at 21:02, SZ Lin (林上智) <SZ.Lin@...> wrote:

Hi Shane,

I've sent PR for Traditional Chinese translation in Github.

Thanks to Lucien's review!

SZ

-----Original Message-----
From: Shane Coughlan <coughlan@...>
Sent: Wednesday, April 3, 2019 5:40 PM
To: SZ Lin (林上智) <SZ.Lin@...>
Cc: Lucien C.H. C.H. Lin <lucien.cc@...>;
openchain@...
Subject: Re: [OpenChain] OpenChain Specification 2.0 - Request for
Translation
- Chinese

Hi SZ

It is fantastic that you and Lucien can work on the Traditional
Chinese version of OpenChain Specification 2.0!

Please let me (and the rest of the community) know if you need any help.

Regards

Shane

On Apr 3, 2019, at 14:31, SZ Lin (林上智) <SZ.Lin@...> wrote:

Hi Shane,

Lucien and I will take this translation task in Traditional Chinese.

SZ

-----Original Message-----
From: openchain-bounces@...
<openchain-bounces@...> On Behalf Of Shane
Coughlan
Sent: Monday, April 1, 2019 11:19 AM
To: openchain@...
Cc: Openchain-korea-wg@...
Subject: [OpenChain] OpenChain Specification 2.0 - Request for
Translation -
Chinese

Dear OpenChain Community

The OpenChain Specification 2.0 is now in its final draft form. We
have
begun to receive requests for translation. While it is not yet
requested, it would be fantastic to have a reference translation in
Chinese to share with Baidu, Huawei, JD, Tencent and other companies.

Formally speaking, the Specification will be released in mid-April.
However,
little is expected to change between now and then…and a translation
would help dozens of companies review the document before it is
completely locked down. The current draft can be found here:
https://wiki.linuxfoundation.org/_media/openchain/openchainspec-2.0.d
raft.p
df

Can anyone assist? If so, I will ask Mark Gisi to provide a Doc format.

Regards

Shane

--
Shane Coughlan
General Manager, OpenChain
e: coughlan@...
p: +81 (0) 80 4035 8083
w: www.openchainproject.org

Schedule a call:
https://calendly.com/shanecoughlan

_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain
--
Shane Coughlan
General Manager, OpenChain
e: coughlan@...
p: +81 (0) 80 4035 8083
w: www.openchainproject.org

Schedule a call:
https://calendly.com/shanecoughlan
_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain
--
Shane Coughlan
General Manager, OpenChain
e: coughlan@...
p: +81 (0) 80 4035 8083
w: www.openchainproject.org

Schedule a call:
https://calendly.com/shanecoughlan


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

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,


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

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


Re: OpenChain Specification 2.0 - Request for Translation - Chinese

Shane Coughlan <coughlan@...>
 

This is fantastic!

Quick check…there were two bug-fixed before release that might need to be incorporated in the Traditional Chinese translation … depending on language structure:

1: 5.1 Contributions
If an organization permits contributions to Open Source projects then
to
5.1 Contributions
If an organization considers contributions to Open Source projects then

2: Making sure “program” was always capitalized to “Program” throughout this part:

1.4 Program Scope
Different Programs may be governed by different levels of scope. For example, a Program could govern a single product line, an entire department or an entire organization. The scope designation needs to be declared for each Program.

Verification Material(s):
 1.4.1 A written statement that clearly defines the scope and limits of the Program.

Rationale:
To provide the flexibility to construct a Program that best fits the scope of an organization’s needs. Some organizations could choose to maintain a Program for a specific product line while others could implement a Program to govern the Supplied Software of the entire organization.

Can we include a fix tomorrow so we can match OpenChain Spec 2.0 release in English?

Regards

Shane

On Apr 22, 2019, at 21:02, SZ Lin (林上智) <SZ.Lin@...> wrote:

Hi Shane,

I've sent PR for Traditional Chinese translation in Github.

Thanks to Lucien's review!

SZ

-----Original Message-----
From: Shane Coughlan <coughlan@...>
Sent: Wednesday, April 3, 2019 5:40 PM
To: SZ Lin (林上智) <SZ.Lin@...>
Cc: Lucien C.H. C.H. Lin <lucien.cc@...>;
openchain@...
Subject: Re: [OpenChain] OpenChain Specification 2.0 - Request for Translation
- Chinese

Hi SZ

It is fantastic that you and Lucien can work on the Traditional Chinese version
of OpenChain Specification 2.0!

Please let me (and the rest of the community) know if you need any help.

Regards

Shane

On Apr 3, 2019, at 14:31, SZ Lin (林上智) <SZ.Lin@...> wrote:

Hi Shane,

Lucien and I will take this translation task in Traditional Chinese.

SZ

-----Original Message-----
From: openchain-bounces@...
<openchain-bounces@...> On Behalf Of Shane Coughlan
Sent: Monday, April 1, 2019 11:19 AM
To: openchain@...
Cc: Openchain-korea-wg@...
Subject: [OpenChain] OpenChain Specification 2.0 - Request for Translation -
Chinese

Dear OpenChain Community

The OpenChain Specification 2.0 is now in its final draft form. We have
begun to receive requests for translation. While it is not yet requested, it would
be fantastic to have a reference translation in Chinese to share with Baidu,
Huawei, JD, Tencent and other companies.

Formally speaking, the Specification will be released in mid-April. However,
little is expected to change between now and then…and a translation would
help dozens of companies review the document before it is completely locked
down. The current draft can be found here:
https://wiki.linuxfoundation.org/_media/openchain/openchainspec-2.0.draft.p
df

Can anyone assist? If so, I will ask Mark Gisi to provide a Doc format.

Regards

Shane

--
Shane Coughlan
General Manager, OpenChain
e: coughlan@...
p: +81 (0) 80 4035 8083
w: www.openchainproject.org

Schedule a call:
https://calendly.com/shanecoughlan

_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain
--
Shane Coughlan
General Manager, OpenChain
e: coughlan@...
p: +81 (0) 80 4035 8083
w: www.openchainproject.org

Schedule a call:
https://calendly.com/shanecoughlan
_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain
--
Shane Coughlan
General Manager, OpenChain
e: coughlan@...
p: +81 (0) 80 4035 8083
w: www.openchainproject.org

Schedule a call:
https://calendly.com/shanecoughlan


Re: OpenChain Third Monday Work Team Call - This Monday at 5pm Pacific

Shane Coughlan <coughlan@...>
 

Update: our agenda slides, video minutes and written minutes plus guest speaker slides can be found here:
https://wiki.linuxfoundation.org/openchain/minutes

Regards

Shane

On Apr 16, 2019, at 10:11, Shane Coughlan <coughlan@...> wrote:

Hello all!

Thank you to everyone who participated for an engaging call. We covered project news, a case study of automated tooling for compliance processes, and a discussion (+ bug fix) for the final version of the new OpenChain Specification 2.0. Formal minutes will be distributed shortly.

If you missed the meeting you can check out the full video minutes right here:
https://youtu.be/jOdCxCjXrJI

Regards

Shane

On Apr 15, 2019, at 16:04, Shane Coughlan <coughlan@...> wrote:

Dear all

This is a reminder that our OpenChain Third Monday Work Team Call takes place this week at 5pm Pacific. Agenda slides attached. We will be having a short guest presentation on the ScanCode open source project for open source compliance and we will be taking a final look at the final draft OpenChain Specification 2.0. Our formal release date for the new Specification is 24th of April.

Agenda and Minutes: https://wiki.linuxfoundation.org/openchain/minutes

Join the call: https://uberconference.com/openchainproject

Optional US dial in number: 855-889-3011
No PIN needed

If you need to use an international phone number please check:
https://www.uberconference.com/international for country numbers.

1. Dial the country number based on your location.
2. Enter 855 889 3011 and then # to enter the room.

Regards

Shane



<OpenChain Agenda 04-15-2019.pdf>
--
Shane Coughlan
General Manager, OpenChain
e: coughlan@...
p: +81 (0) 80 4035 8083
w: www.openchainproject.org

Schedule a call:
https://calendly.com/shanecoughlan
--
Shane Coughlan
General Manager, OpenChain
e: coughlan@...
p: +81 (0) 80 4035 8083
w: www.openchainproject.org

Schedule a call:
https://calendly.com/shanecoughlan
--
Shane Coughlan
General Manager, OpenChain
e: coughlan@...
p: +81 (0) 80 4035 8083
w: www.openchainproject.org

Schedule a call:
https://calendly.com/shanecoughlan


OpenChain Supplier Education - Massive Step Forward in Japanese and soon in English

Shane Coughlan <coughlan@...>
 

OpenChain has a very active Work Group in Japan. One of the sub-groups, focused on creating a supplier education leaflet, has released the finished document in Japanese:
https://github.com/OpenChain-Project/curriculum/raw/master/supplier-leaflet/supplier-leaflet-1.0-jp.pdf
The English version is coming in May. It will be distributed online and through events like Open Source Summit Japan.

The really exciting thing is the list of companies distributing the physical and digital version of the Japanese leaflet:
Sony
Panasonic
Fujitsu
Mickware
Ricoh
Pioneer
Toyota
Hitachi Solutions
Mitsubishi Electric
NEC / NEC Sol. I.
Hitachi Ltd.
Murata Manufacturing
DeNA
Socionext
VeriServe
Toshiba
Sky
Canon
Olympus
Daikin Industries
SOFTIC
Daihatsu
NTT COMWARE
Renesas
Fujifilm

For completeness, here is everyone in Japanese:
ソニー
パナソニック
富士通
ミックウエア
リコー
パイオニア
トヨタ
日立ソリューションズ 
三菱電機    
NEC/NEC Sol. I.  
日立製作所  
村田製作所 
DeNA    
ソシオネクスト 
ベリサーブ  
東芝     
Sky      
キヤノン    
オリンパス  
ダイキン工業  
SOFTIC  
ダイハツ     
NTTコムウエア  
ルネサス  
富士フイルム 

As always, OpenChain is going deeper and deeper into the supply chain. Great thanks to Ueda San from Sony for leading this initiative.

Regards

Shane

--
Shane Coughlan
General Manager, OpenChain
e: coughlan@...
p: +81 (0) 80 4035 8083
w: www.openchainproject.org

Schedule a call:
https://calendly.com/shanecoughlan


Reminder: OpenChain Project started a Korean Work Group

Shane Coughlan <coughlan@...>
 

Reminder: OpenChain Project started a Korean Work Group during the first quarter of this year. Big thanks to Haksung Jang at LG for getting the ball rolling. We look forward to having a meeting once a quarter. More news to follow! Learn more:
https://wiki.linuxfoundation.org/openchain/openchain-korean-working-group

Want to invite some of your Korean friends or suppliers? Just reach out to me direct.

Regards

Shane

--
Shane Coughlan
General Manager, OpenChain
e: coughlan@...
p: +81 (0) 80 4035 8083
w: www.openchainproject.org

Schedule a call:
https://calendly.com/shanecoughlan


Re: OpenChain Specification 2.0 - Request for Translation - Chinese

SZ Lin (林上智)
 

Hi Shane,

I've sent PR for Traditional Chinese translation in Github.

Thanks to Lucien's review!

SZ

-----Original Message-----
From: Shane Coughlan <coughlan@...>
Sent: Wednesday, April 3, 2019 5:40 PM
To: SZ Lin (林上智) <SZ.Lin@...>
Cc: Lucien C.H. C.H. Lin <lucien.cc@...>;
openchain@...
Subject: Re: [OpenChain] OpenChain Specification 2.0 - Request for Translation
- Chinese

Hi SZ

It is fantastic that you and Lucien can work on the Traditional Chinese version
of OpenChain Specification 2.0!

Please let me (and the rest of the community) know if you need any help.

Regards

Shane

On Apr 3, 2019, at 14:31, SZ Lin (林上智) <SZ.Lin@...> wrote:

Hi Shane,

Lucien and I will take this translation task in Traditional Chinese.

SZ

-----Original Message-----
From: openchain-bounces@...
<openchain-bounces@...> On Behalf Of Shane Coughlan
Sent: Monday, April 1, 2019 11:19 AM
To: openchain@...
Cc: Openchain-korea-wg@...
Subject: [OpenChain] OpenChain Specification 2.0 - Request for Translation -
Chinese

Dear OpenChain Community

The OpenChain Specification 2.0 is now in its final draft form. We have
begun to receive requests for translation. While it is not yet requested, it would
be fantastic to have a reference translation in Chinese to share with Baidu,
Huawei, JD, Tencent and other companies.

Formally speaking, the Specification will be released in mid-April. However,
little is expected to change between now and then…and a translation would
help dozens of companies review the document before it is completely locked
down. The current draft can be found here:
https://wiki.linuxfoundation.org/_media/openchain/openchainspec-2.0.draft.p
df

Can anyone assist? If so, I will ask Mark Gisi to provide a Doc format.

Regards

Shane

--
Shane Coughlan
General Manager, OpenChain
e: coughlan@...
p: +81 (0) 80 4035 8083
w: www.openchainproject.org

Schedule a call:
https://calendly.com/shanecoughlan

_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain
--
Shane Coughlan
General Manager, OpenChain
e: coughlan@...
p: +81 (0) 80 4035 8083
w: www.openchainproject.org

Schedule a call:
https://calendly.com/shanecoughlan


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.

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


Re: OpenChain Reference Training Slides - Request for Comment!

Nathan Kumagai
 

Hi Shane –

 

Do both decks share the same first 8 chapters?

 

I like the idea of having both short, polished material as well having a wide range of available resources. In this case though I wonder if the overlap is too great – maybe we are just creating a more work to keep the slides synced?

 

Nathan

 

From: <openchain-bounces@...> on behalf of Shane Coughlan <coughlan@...>
Date: Thursday, April 18, 2019 at 1:03 AM
To: "openchain-japan-wg@..." <openchain-japan-wg@...>, "Openchain-korea-wg@..." <Openchain-korea-wg@...>, "openchain@..." <openchain@...>
Subject: [OpenChain] OpenChain Reference Training Slides - Request for Comment!

 

Dear all

Quick question:
We have two versions of the OpenChain Reference Training Slides. One has eight chapters and covers most aspects of open source compliance up to developer guidelines. The other has 10 chapters and it includes a tooling overview+tooling use case explanation.

As we head into Specification 2.0 release….big question:
(1) should we keep distributing two sets of slides, one small, one slightly bigger
(2) or should we standardize on having only the 10 chapter full set?

Regards

Shane


Re: OpenChain Reference Training Slides - Request for Comment!

Dave Marr
 

+1, I also find both decks useful for the same reasons.  And to Indira’s point the short deck can indeed be fairly short so as to keep the maintenance burden light.

HTH,
Dave

On Apr 19, 2019, at 1:47 PM, Alan Tse <Alan.Tse@...> wrote:

CAUTION: This email originated from outside of the organization.

I like the two types of decks.  However, it seems to me that this should be something that can be automated so we don’t have to make a choice to eliminate one or the other.

 

Alan

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Indira Bhatt
Sent: Friday, April 19, 2019 12:00 PM
To: Matija Šuklje <matija@...>
Cc: openchain@...
Subject: Re: [OpenChain] OpenChain Reference Training Slides - Request for Comment!

 

I actually like the idea of having 2 decks and I've done this in the past with success (because you're right large decks can make folks run away). 

 

Deck 1: is short meant to serve as an overview or a quick start guide listing all the components. Limited to a couple slides. 

Deck 2: Can be as large as needed. Go here to find all the details. 

 

With 1 large deck if the audience is always going to be folks getting trained then it might be ok. 

But it's always good to have a shorter version so folks outside (ex sr. management) of people getting trained can have a good idea of what this entails without having to go through a large doc. 

 

Hope this helps!

 

Best, 

Indira

 

 

 

 

On Thu, Apr 18, 2019 at 11:38 PM Matija Šuklje <matija@...> wrote:

Die 18. 04. 19 et hora 10:01 Shane Coughlan scripsit:
> As we head into Specification 2.0 release….big question:
> (1) should we keep distributing two sets of slides, one small,
> one slightly bigger (2) or should we standardize on having only
> the 10 chapter full set?

Tooling is a very important topic and should help adoption and
compliance a lot, so I vote for 2.

What I do worry about though is that for smaller companies and
community-driven projects, when they see a 150 page slide deck,
they will simply run away.

I mean, let’s be honest, the main reason why we can get away with
giving such training to our developers is because they are
employed by the company and we can make it a requirement and force
them to attend.

Unfortunately, I don’t have a good solution to that, just a few
suboptimal options running around my head.


cheers,
Matija
--
gsm:    +386 41 849 552
www:    http://matija.suklje.name
xmpp:   matija.suklje@...
sip:    matija_suklje@...


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

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


Re: OpenChain Reference Training Slides - Request for Comment!

Alan Tse
 

I like the two types of decks.  However, it seems to me that this should be something that can be automated so we don’t have to make a choice to eliminate one or the other.

 

Alan

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Indira Bhatt
Sent: Friday, April 19, 2019 12:00 PM
To: Matija Šuklje <matija@...>
Cc: openchain@...
Subject: Re: [OpenChain] OpenChain Reference Training Slides - Request for Comment!

 

I actually like the idea of having 2 decks and I've done this in the past with success (because you're right large decks can make folks run away). 

 

Deck 1: is short meant to serve as an overview or a quick start guide listing all the components. Limited to a couple slides. 

Deck 2: Can be as large as needed. Go here to find all the details. 

 

With 1 large deck if the audience is always going to be folks getting trained then it might be ok. 

But it's always good to have a shorter version so folks outside (ex sr. management) of people getting trained can have a good idea of what this entails without having to go through a large doc. 

 

Hope this helps!

 

Best, 

Indira

 

 

 

 

On Thu, Apr 18, 2019 at 11:38 PM Matija Šuklje <matija@...> wrote:

Die 18. 04. 19 et hora 10:01 Shane Coughlan scripsit:
> As we head into Specification 2.0 release….big question:
> (1) should we keep distributing two sets of slides, one small,
> one slightly bigger (2) or should we standardize on having only
> the 10 chapter full set?

Tooling is a very important topic and should help adoption and
compliance a lot, so I vote for 2.

What I do worry about though is that for smaller companies and
community-driven projects, when they see a 150 page slide deck,
they will simply run away.

I mean, let’s be honest, the main reason why we can get away with
giving such training to our developers is because they are
employed by the company and we can make it a requirement and force
them to attend.

Unfortunately, I don’t have a good solution to that, just a few
suboptimal options running around my head.


cheers,
Matija
--
gsm:    +386 41 849 552
www:    http://matija.suklje.name
xmpp:   matija.suklje@...
sip:    matija_suklje@...


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


Re: OpenChain Reference Training Slides - Request for Comment!

Indira B
 

I actually like the idea of having 2 decks and I've done this in the past with success (because you're right large decks can make folks run away). 

Deck 1: is short meant to serve as an overview or a quick start guide listing all the components. Limited to a couple slides. 
Deck 2: Can be as large as needed. Go here to find all the details. 

With 1 large deck if the audience is always going to be folks getting trained then it might be ok. 
But it's always good to have a shorter version so folks outside (ex sr. management) of people getting trained can have a good idea of what this entails without having to go through a large doc. 

Hope this helps!

Best, 
Indira




On Thu, Apr 18, 2019 at 11:38 PM Matija Šuklje <matija@...> wrote:
Die 18. 04. 19 et hora 10:01 Shane Coughlan scripsit:
> As we head into Specification 2.0 release….big question:
> (1) should we keep distributing two sets of slides, one small,
> one slightly bigger (2) or should we standardize on having only
> the 10 chapter full set?

Tooling is a very important topic and should help adoption and
compliance a lot, so I vote for 2.

What I do worry about though is that for smaller companies and
community-driven projects, when they see a 150 page slide deck,
they will simply run away.

I mean, let’s be honest, the main reason why we can get away with
giving such training to our developers is because they are
employed by the company and we can make it a requirement and force
them to attend.

Unfortunately, I don’t have a good solution to that, just a few
suboptimal options running around my head.


cheers,
Matija
--
gsm:    +386 41 849 552
www:    http://matija.suklje.name
xmpp:   matija.suklje@...
sip:    matija_suklje@...


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


Re: OpenChain Reference Training Slides - Request for Comment!

Matija Šuklje
 

Die 18. 04. 19 et hora 10:01 Shane Coughlan scripsit:
As we head into Specification 2.0 release….big question:
(1) should we keep distributing two sets of slides, one small,
one slightly bigger (2) or should we standardize on having only
the 10 chapter full set?
Tooling is a very important topic and should help adoption and
compliance a lot, so I vote for 2.

What I do worry about though is that for smaller companies and
community-driven projects, when they see a 150 page slide deck,
they will simply run away.

I mean, let’s be honest, the main reason why we can get away with
giving such training to our developers is because they are
employed by the company and we can make it a requirement and force
them to attend.

Unfortunately, I don’t have a good solution to that, just a few
suboptimal options running around my head.


cheers,
Matija
--
gsm: +386 41 849 552
www: http://matija.suklje.name
xmpp: matija.suklje@...
sip: matija_suklje@...


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

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


Re: OpenChain Reference Training Slides - Request for Comment!

JerryTan
 

Yep, I agree with Haksung,

 

Providing some recommend tools (both commercial and open source ) will help company a lot.

 

 

发件人: "openchain-bounces@..." <openchain-bounces@...> 代表 "Haksung Jang (장학성)" <haksung.jang@...>
日期: 2019419 星期五 上午6:58
收件人: Shane Coughlan <coughlan@...>, "openchain-japan-wg@..." <openchain-japan-wg@...>, "Openchain-korea-wg@..." <Openchain-korea-wg@...>, "openchain@..." <openchain@...>
主题: Re: [OpenChain] OpenChain Reference Training Slides - Request for Comment!

 

I have not seen the 10-chapter version yet, but understanding tooling is an important part of open source compliance training. So I think it's better to have one unified version of the training slide.

Best Regards,
Haksung

Haksung Jang / 장학성
Professional / 책임연구원 / +82 10 3630 5799
Open Source part, Software Center, CTO, LG Electronics.

2019. 4. 18. 오후 5:01 Shane Coughlan () :

Dear all
 
Quick question:
We have two versions of the OpenChain Reference Training Slides. One has eight chapters and covers most aspects of open source compliance up to developer guidelines. The other has 10 chapters and it includes a tooling overview+tooling use case explanation.
 
As we head into Specification 2.0 release….big question:
(1) should we keep distributing two sets of slides, one small, one slightly bigger
(2) or should we standardize on having only the 10 chapter full set?
 
Regards
 
Shane



--
Shane Coughlan
General Manager, OpenChain
e: coughlan@...            
p: +81 (0) 80 4035 8083                
w: www.openchainproject.org
 
Schedule a call:
https://calendly.com/shanecoughlan
 



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


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>


OpenChain @ Japan Work Group #9

Shane Coughlan <coughlan@...>
 

The OpenChain Japan Work Group held its ninth “all member” meeting at DensoTen on the 18th of April.

This meeting covered a wide range of topics related to open source compliance. One highlight were the reports from the seven sub-groups of the Japanese community, covering a diverse range of topics from education to Bill of Materials to automation. As always, conversation was informal and open, allowing all participants to add their view during and after each presentation, and to network freely during the coffee breaks.

Check out the excellence!
https://www.openchainproject.org/news/2019/04/18/openchain-japan-work-group-9

Regards

Shane

--
Shane Coughlan
General Manager, OpenChain
e: coughlan@...
p: +81 (0) 80 4035 8083
w: www.openchainproject.org

Schedule a call:
https://calendly.com/shanecoughlan

2781 - 2800 of 5043