2018年春のサミット

今日、InnerSourceは、組織的および地理的境界を aka silos に変換するコミュニティを活用することで、ソフトウェアを効率的に開発する素晴らしい方法です。 また、InnerSourceは、ソフトウェアのDNAを欠く企業のための真のオープンソース開発に優れたセグウェイであることを今知っています。 ボッシュがInnerSourceを始めたとき、ボッシュ内での技術、法的、コラボレーション、社会的、そして商業的な経験がすぐにオープンソースを開始できなかった。 このような設定でInnerSourceの取り組みは困難です。 ステファンは、ボッシュでInnerSourceの起源に戻り、彼が管理した驚くべき物語を共有して、InnerSourceにかなりの不便な手段を使用して従事させる。 これは3つの主要な要素を含んでいます:

1. InnerSourceを最初に起動し、オープンソースをすぐに使用しないでください。
2. ボッシュ製品ではなく、ツーリング(車載用)を始め、
3. 「国旗を捕獲する」を始め、スライドではなく、Sefanは、物事プロジェクトのEclipseインターネットに積極的に貢献していることを誇りに思います。

今、Stefanは、Boschは物事プロジェクトのEclipseインターネットに積極的に貢献していることを誇りに思っています。

長年に渡り、ソフトウェア開発方法がすべて見つかりました。 私たちの多くは、結果として新しいアプローチの約束の概念を成長させました。 InnerSourceの3つの長い間の実務家であるDanese、JimおよびGeorgは、InnerSourceがいかに立ち、真に企業ソフトウェア開発の世界を変革する潜在能力を最初に経験しました。 このトークでは、InnerSource がなぜ重要であるかについて、3つの説得力のある引数を共有します。

「インネルソースは素晴らしいアイデアです! 社内のソースで、専用のチャンピオンです。 今何をしますか? 堅牢で説得力のある内部の調達がエンジニアリングが行われる方法の通常の部分である点に、数十や数百のチームの動きを現実的に影響する方法は?

本講演では、Nikeでの経験を垣間見ることができる、原則、実践的な逸話、および再ラタブルな例を共有しています。 すべての回答を主張していない間、領域での作業の1年以上の洞察力のある要約です。

世界中にある組織の境界線を横断して連携を深めるために、InnerSourceの取り組みを開始することを決定しました。 私たちは、組織内のオープンソース開発パラダイムの採用が非常に人気になり、会社のビジネスに不可欠であることを理解しています。 知っている限り、多くの企業がこのモデルで実験してきましたが、これまでのところ、どこから始めるかは必ずしも明確ではありません。 そのため、Edge Platform InnerSource のケースから、ユースケース、DevOps、ツール、製品開発、開発インフラなど、様々なインサイトをキャプチャしたいと考えています。 しかし、企業が採用しているInnerSourceのさまざまなモデルを理解するためにさらなる議論が必要である。

2006年にSAPにインナーソースを導入しました。 教授になられた後、社内のソースを紹介する会社が増えました。 3世代のプロジェクトで培った経験や、社内のガバナンスのための実践的なハンドブックに変える方法をお伝えします。

Wayfairは、シジブル(1200人以上)のエンジニアリング組織を持っています。 多くの小さなスプリントチームで構成されており、効率的かつ効果的に作業することができます。 しかし、この構造は、新しいフレームワークの導入や共有インフラストラクチャのアップグレードなど、部門の大きなチャンクに及ぶ作業をコーディネートするのは困難です。 私たちは、InnerSourceの原則に基づいて、ワーキンググループと呼ばれる概念を導入しました。これにより、私たちは他のチームから期待する効率で、これらの種類のプロジェクトを実行することができます。 このポスターセッションでは、ワーキンググループ、その長所と短所、そしてこのパターンを反復する計画について、私たちが取り組むプロジェクトの概要を説明します。

インナーソースは、プロトタイピングと偏向に非常に肯定的な影響を持っています。 異なるドメインの多くの製品を持つ会社は、APIやライブラリの社内公開によってクロスドメインソリューションをトリガーできます。 企業内での共有は、さまざまなアプリケーション間で驚くべきシナジーにつながるさまざまなビジネスユニットで再利用できるようになりました。

API に関する多くのトークやブログ投稿や、API の開発者 eXperience の重要性はありますが、一般に公開されている API 製品について最も多くあります。 API 製品のベストプラクティスの多くは、プライベート API にも適用可能ですが、状況やトレードオフの大きな違いがあります。 最も重要な違いは、おそらく彼らの予算で:潜在的な利益センターとして、API製品は、ドキュメントとUX駆動の開発者ポータルの改善に多くのお金を投資することができます。 内部 API は、その贅沢を持っていることはめったにありません。 このトークでは、パブリックとプライベートのAPIの違いについて説明し、上流の開発者体験を紹介し、下流DXを改善する方法について説明します。 エクスペリエンスデザイン(ゲーム化)を導入し、社内の開発者ポータルで利用する方法を記述します。 最後に、SDKの重要性と組織のさまざまな戦略についてお話しします。これらの戦略は、組織のデジタル変革の取り組みの中心でAPIのDXを改善するのに役立ちます。

FusionX は最初のボッシュの内部オープンソースコミュニティであり、過去9年間活動してきました。 ボッシュのエンジニアが試作、工具、新製品を従来よりも早く繋げるというミッションです。 長年にわたり、そのすべてが起こることと多くを見てきました。 コミュニティがどのように機能したのか、私たちが開発したのか、成功要因や課題について、例や洞察を共有します。

ステップ1:プラットフォーム、リポジトリ、初期ユーザのグループを持っています。 今、私たちはステップ2を探しています, 関与する大きなインフラプロジェクトの開発者を取得. InnerSourceに参加する時間がないと心配しています。 私たちは、チーム – 彼らは良いソフトを持っているし、それを共有することを喜んでいるが、彼らは他の人が貢献するコードの品質について懸念しています。 そして、グループ外の他の人をメンターする能力。 次のハードルです。 このポスタートークは、逆のアドバイスブースです。ぜひ、ぜひご覧ください。

        Another topic: we have a one hour meeting with the company president about InnerSource; what should we emphasize and try to get from him (in terms of support for the InnerSource Program).            

このプレゼンテーションでは、採掘中のソースベストプラクティスに関する継続的な研究プロジェクトからの研究アプローチと予備的な結果を紹介します。 内部のソースは、オープンソースソフトウェア開発のベストプラクティスと組織内のオープンソースのような文化の確立を使用しているため、オープンソースの世界で使用されているベストプラクティスを理解し、それらから学ぶ必要があります。 これまでのところ、450,000以上のオープンソースプロジェクトから開発活動情報を収集し、パフォーマンスを定量化し、成功を予測します。 最高のプロジェクトから、使用されるプロセスと慣行を採掘する予定です。 ケーススタディ研究を使用して、内部のソースでこれらのオープンソースの慣行を適用し、開口部から内部のソースにジャンプできるか検証します。

メトリックは重要ではありませんが、会社の戦略的目標に直接リンクされているもの。 目標を達成すると、成功は基本的に測定されます。
データを採掘する場所を知っている場合、測定は「簡単」であるが、戦略は、コンテキストの専門知識、測定プロセスを正式化するための詳細な方法、意識、プロセス改善、透明性、および他の重要な領域間のモチベーションアクションに関する戦略が必要です。

メトリックはパンセアではなく、現在の構造と方法論をソフトウェア開発チームで理解するのに役立ちます。 そして、他の類似組織からどのくらいの割合でこれがあるか。

トピック:

• メトリックを使用してゴール
• 分析領域
• Goal-Question-Metricのような正式なアプローチ
• メトリックを使用した場合の戦略
• いくつかの例

サイロを破壊し、複数のビジネスユニット間でのコラボレーションを促進することは、InnerSourceの任意の主要な目標の一つです。 しかし、実際に起きているかどうかは、どうやって分かりますか? このトークでは、このタイプのイニシアチブと新しいコミュニティのメンバーが残っているトレースで必要なインフラを構築するときに利用できる通常のデータソースにも焦点を合わせます。 これらの痕跡は、組織のための貴重なメトリックを生成するために、解析、保存およびキュレーションされたものです。 GitHub、Jira、Slackなどの通常のデータソースから、組織全体のコラボレーションを理解し、測定する方法をいくつか紹介します。

内部ソース(IS)は、開発者がプラン駆動やアジャイル開発などの伝統的なSDメソッドをより多くコラボレーションできるようにします。 ISをよりよく理解するために、研究者や実務者はISのコラボレーションを測定する必要があります。 しかし、まだ確立された方法はありません。 今回のトークでは、組織内のパッチフローを計測することで、ISのコラボレーションを測定する方法を紹介します。 パッチフローは、プロジェクト、組織単位、または利益センターの境界など、組織の境界を越えてコードの貢献の流れです。 ソフトウェア開発会社に採用することでパッチフロー測定法の能力を発揮します。 当社は、ISプロジェクトへのすべてのコードコントリビューションの約47.9%)が、組織単位間のパッチフローを構成することを発見しました。これは、異なる製品を扱う組織単位間でほぼすべての(42.2%)です。 このような重要なパッチフローは、パッチフロー現象の高い関連を示します。 当社のパッチフロー測定法は、その種の最初のもので、ISコラボレーションを測定し定量化します。 ISコラボレーションのさらなる定量分析のためのベースとして機能することができます。

議論や誤解は、最も高性能な組織であっても一般的です。 幸いにも、潜在的なソリューションは、曖昧さと混乱から続く道を提供します。意図的な関係の設計。 治療上の専門職から取られたIRDは、早期に当社の仕事関係において明確性を確立できるようにしますので、後で競合を避けることができます。 このトークでは、特にInnerSourceを目指しているチームとして、期待、境界を設定し、コミュニケーションの好みを明らかにする方法を紹介します。

InnerSourceをチームに応用することで、開発、学習の高速化、サイロやスケーリングの組織の破壊など、最も強力な方法を見つけました。 InnerSourceは、オープンソースソフトウェア開発のベストプラクティスとオープンソースのような文化をあらゆる内部開発に確立することができます。 独自のソフトウェアを開発することができますが、内部でその開発を開くことができます。 このセッションでは、InnerSourceを使用して組織をスケールアップする方法、以前の組織のIntuitでメトリック、およびMicrosoftで内部のオープンソースの文化と慣行について説明します。

テクノロジークラウドネイティブプラットフォームを開発し、基盤のプラットフォームチームとして、社内に機能しない機能を発揮する。 オープンソースのマインドセットを採用する際に、敏捷性を高め、独自の組織で文化的な変化を始める方法を検討し、プラットフォームを採用する事業単位の文化的変化を推進しています。 組織を変更し、オープンソースの組織(構造、エンジニアリング慣行、コラボレーション)のように考え、すぐにInnerSourceの組織を会社にし、InnerSourceを超える文化的変化をもたらす。 私たちが作ったトランジションを記述し、当社でInnerSourceとして最初のステップを取った方法

InnerSourceジャーニーを失敗のためにセットアップすることを確認するためにいくつかの確実な火災方法について説明します。 これらのヒントの後、InnerSourceが成功しないと保証することができます

InnerSourceプログラムの確立は、同様の問題が発生します。 パターンの開発は、これらの問題に対する実証済みのソリューションをキャプチャする方法です。 一緒に働き、より大きなコミュニティのためのソリューションを提供します! このワークショップでは、InnerSourceパターンの簡単な紹介とパターンの標準的なコンポーネントを提供します。 それから私達はグループに忍耐強い問題のためのパターンを起草するために破壊します。 出席者:ワークショップでカバーしたいという問題があったら、事前にお知らせください! Eメール: erin.bank@ca.com

パターン言語は、トピック領域の周りの問題のクラスを解決するためにパターンがどのように合うかを示しています。 2016年以降、ISCのInnerSourceパターンを制作してきました。この作品は、必然的に、ややらばらしさで作られています。 InnerSourceの異なる風味とInnerSourceのプログラムが記述されている複数の次元があることが判明しました。 このプレゼンテーションでは、InnerSourceパターン言語の周りのいくつかの洞察を共有し、それらがどのように使用されるか、そしてそれらがどのように作成されるか。

スペインの企業は、過去1ヶ月の間に、Cレベルの一般的なフレームワークとInnerSourceでの作業の他の領域を与えるために成熟モデルに取り組んでいます。
このトークでは、コラボレーションや透明性などの主要なInnerSourceの原則に基づいて、成熟モデルと潜在的な実装のトピックに関する内部の議論を紹介します。 これに加えて、通常、良い慣行のセットとして開始されるこのタイプのモデルのトピックに関するいくつかの議論を開くことが期待されますが、最後に、彼らは組織内の純粋なbureaocracyとして見られます。

シーメンスInnerSourceプラットフォームは、製品範囲全体で標準的なスタックを維持するために1つの部門のための方法として始まりました。 これらの始まりから、急速に大きく成長しました。最先端の開発環境、社内のプラットフォームを構築するためのツール。 また、シーメンス内での作業の共同、アジャイルな方法のための非常に目に見える例になりました。 この基調講演では、これまでの成功のプラットフォームの歴史と重要な理由を見直し、過去と現在に挑戦します。

InnerSource – ボッシュ内部のオープンソース(BIOS)を内部で呼び出すことは – 企業セットアップでさまざまなユースケースに最適なツールです。 InnerSourceは、内部ツーリングであるものの1つは、かなり自然なフィットだと思います。 昨年9年間、BIOSを進化させ続けることで、Bosch社がInnerSourceの採用を開始するために、企業ITを確信できるようになりました。 BIOS プロジェクトになる最初の内部ツールは、Bosch のアソシエイト向けの Linux ベースの OS のいわゆるオープンソースデスクトップ(OSD)です。 我々が取った最初のステップについて詳細を提供するだけでなく、我々はまた成功したInnerSourceプロジェクトのために重要な前提条件にいくつかの洞察を与え、OSDがボッシュ内で使用されている領域について簡単な概要を与えます。

InnerSourceプログラムの確立は、同様の問題が発生します。 パターンの開発は、これらの問題に対する実証済みのソリューションをキャプチャする方法です。 一緒に働き、より大きなコミュニティのためのソリューションを提供します! このワークショップでは、InnerSourceパターンの簡単な紹介とパターンの標準的なコンポーネントを提供します。 それから私達はグループに忍耐強い問題のためのパターンを起草するために破壊します。 出席者:ワークショップでカバーしたいという問題があったら、事前にお知らせください! Eメール: erin.bank@ca.com

ノキアの中核ネットワークと天で作られた試合みたいな人がいる。 上級管理のため、R&Dの効率プログラムです。 開発者にとって、それは自分自身を表現する機会です。 旅は、成功と失敗の共有を持っていたので、いくつかのコースの修正をする方法. 社内の調達・再利用の素晴らしさや、企業目標への配送の期待は、一緒に来る独自の方法でした。 ミツバチの月はもうすぐ続いており、このカクテルは、オープンソースのデーレと企業のフレアとの間の正しいミックスを組み合わせるという大きな仕事でした。 私たちはまだその楕円のミックスを探しています…この話は、働いたもの、人が気づいたもの、欲求、不満を探求します

オープンソースでは、プロジェクトは他のプロジェクトと大きく異なります。 その結果、内部のソースプロジェクトやプログラムも様々な形状を持つことができるという驚きはありません。 既存のイニシアチブの進化を管理する場合でも、新しいインナーソースプログラムを発見することにより、内部ソースを採用するときは、内部ソースプロジェクトやプログラムの異なる形状(クラス)を理解することが重要です。 このトークでは、社内のソースプロジェクトやプログラムの異なるクラスをレイアウトする分類フレームワークを紹介します。 ISを行う11社にフレームワークを適用し、社内のソースプログラムの違いについて議論します。 提示された分類フレームワークは、既存の内部ソースプログラムのスペースを分類し、構造するためにその種類の最初のものです。 このトークを聴いた後、自分の会社にフレームワークを適用することができます。

データサイエンティストは開発者ではありません。 そして、彼らは常にソースコードを書いています。 ライティングソフトウェアは複雑で、データサイエンスの領域でもあります。 ソフトウェアエンジニアリングは、ソフトウェア製品の提供に10年間失敗と成功の修正です。 おそらくオープンソースは、最もパラダイマティックなケースの1つです。革新的な慣行では、グローバルに分散したチーム、有料およびボランティアの開発者の混合物、コードの10個を再利用し、一貫して高品質のソフトウェアを提供してきました。 ソフトウェアエンジニアリングとオープンソースからのデータサイエンスを学ぶことができますか? 本講演では、データサイエンスチームがソフトウェアエンジニアリングとオープンソースから学ぶことができる方法を紹介し、InnerSourceのアプローチを取り入れて、コードと結果を再活用し、高品質の結果を配信しやすくなります。

誰でもソフトウェアのフォージをインストールすることができます。, “我々は今、内部のソースをやっている”と宣言し、定義によって成功を呼び出す. 多くは、その有効性に関するメトリックを測定するために、さらに一歩進みます。 メトリックはトリッキーですが、多くの場合、開発者を不満させるだけでなく、ゲームが簡単であり、ビジネスが理解しているものへの非常にまれなネクタイです – サイクティックな複雑さとKLOC誰? 本講演では、Docker、Twitter、Blabla Car、Hello Freshなどの企業を管理し、投資の成功を測定するベンチャーキャピタルファンドが使用するメトリックをいくつか提案します。 アリアンツ、コンチネンタル、ザランドなどの大型企業で、これらの指標の経済的影響を実例に示します。 これらのメトリクスの多くは、内部のソース(企業の境界でオープンソースを開く)のアプリケーションで行う必要があるので、我々はまた、それを採用するために、特に中間管理を妨げている内部のソースについてのおそらく最大の認識を誤解します – すべての開発者が今から彼または彼女が望むものは何でもします。

内部ソースは、内部開発ソフトウェアへのオープンソースの手法の適用です。 定義するのは簡単ですが、内部のソースは説明し、正常に実行するのは困難です。 本講演では、説明や実例とともに、効果的なインナーソーシングのための重要な用語、コンセプト、原則をご紹介します。 体験した方にはさっぱりと爽やかにしながら、新人へアクセスできる内容です。 このプレゼンテーションの同じ情報は、https://www.safaribooksonline.com/oriole/.で自由に利用できるO’Reilly Orioleとしてまた配信されます Oriole、それを使用する方法、および方法にある内部ソースに関連する他のOriolesを見直します。