Thoughtworks Technology Radar 第26号（39ページのPDF）
(thoughtworks.com)テクニック/ツール/プラットフォーム/開発言語およびフレームワーク分野の最新トレンドを、Hold/Assess/Trial/Adopt の4段階で可視化し解説しているのが特徴
奇妙な市場：オープンソースの変化する Economics
- 私たちはエリック・レイモンドの「伽藍とバザール」のファンだが、商用化の試みとともに複雑に変化している
- ElasticSearch vs. OpenSearch や Docker Desktop のような事例
- 一方で Facebook は Presto にオープンソース製品として資金提供していたため、メンテナーたちは IP を維持でき、会社を離れて Trino としてリブランドしたので、実質的には Facebook の投資の恩恵を受けた
- 企業が資金提供しない中核インフラが増えるにつれ、状況はさらに混乱している
- Log4j のような事例が示すように、重大なセキュリティバグが発生したときにこそ、どれほど（オープンソース開発者の）無償労働に依存しているかがわかる
- 場合によっては GitHub Sponsors や Patreon を通じて趣味で保守するメンテナーに資金提供すると、十分な違いを生む報酬になる
- 別の人にとっては、自分の日常業務に責任がさらに追加されたように感じられ、バーンアウトを引き起こす
- ソフトウェアを強く支持しているが、Economics はますます奇妙になっており、正しいバランスを見つける簡単な解決策はないとわかっている
ソフトウェアサプライチェーンの革新
- Equifax のデータ流出、SolarWinds 攻撃、Log4J 脆弱性のような出来事は、サプライチェーンの貧弱なガバナンスによって発生した
- チームは今や、プロジェクトの依存関係を検証し管理することがエンジニアリングプラクティスに含まれるべきだと気づいている
- Supply chain Levels for Software Artifacts (SLSA)
- CycloneDX : Software / SaaS / Operations のための Bill of Materials
- Syft : Software Bill of Materials を生成する CLI ツールのオープンソース
- ハッカーはセキュリティ分野で攻撃と防御の非対称的な特性をますます多く利用している
- 攻撃者は1つの脆弱性を見つければよいが、防御側は攻撃対象領域全体を保護しなければならない
- システムを安全に守るために、サプライチェーンセキュリティを向上させる取り組みが重要だ
なぜ開発者は React で State Management を作り続けるのか？
- フレームワークが一般化すると、欠点を改善するための一連のツールが登場し、その後は人気のあるもの同士を統合するのが一般的だ
- ところが React State Management は、こうした一般的な傾向に従っていないようだ
- Redux のリリース以降、少し異なる方法で状態を管理するツールやフレームワークが継続的に登場している
- 理由はよくわからないが、推測してみると…
- JavaScript エコシステムが好む自然な逸脱なのか？
- React の根本的な欠陥なのか？
- 開発者にとって実験しやすい、面白く扱いやすい問題なのか？
- 文書を読む形式（Web ブラウザ）と、その文書上でアプリケーションのインタラクションを実装することによる永続的なインピーダンスミスマッチのせいなのか？
- なぜ出続けるのかはわからないが、この永続的な問題を解決する次の試みに期待している
マスターデータカタログをめぐる終わりなき冒険
- 企業内データを収集・分類しようとする努力は続いてきたが、複雑さ・重複・曖昧さのため難しい
- Collibra、Datahub のような賢いツールが登場
- データリネージュとメタデータ全般にわたる一貫したアプローチを提供し、ガバナンス/管理/パブリッシングなどへ拡張可能
- このような中央集権型とは逆に、データメッシュアーキテクチャに基づく連合型ガバナンスと検索へ移行する動きもある
[ Techniques ]
Adopt
- Four key metrics
- Single team remote wall
Trial
- Data mesh
- Definition of production readiness
- Documentation quadrants
- Rethinking remote standups
- Server-driven UI
- Software Bill of Materials
- Tactical forking
- Team cognitive load
- Transitional architecture
Assess
- CUPID
- Inclusive design
- Operator pattern for nonclustered resources
- Service mesh without sidecar
- SLSA
- The streaming data warehouse
- TinyML
Hold
- Azure Data Factory for orchestration
- Miscellaneous platform teams
- Production data in test environments
- SPA by default
[ Platforms ]
Trial
- Azure DevOps
- Azure Pipeline templates
- CircleCI
- Couchbase
- eBPF
- GitHub Actions
- GitLab CI/CD
- Google BigQuery ML
- Google Cloud Dataflow
- Reusable workflows in Github Actions
- Sealed Secrets
- VerneMQ
Assess
- actions-runner-controller
- Apache Iceberg
- Blueboat
- Cloudflare Pages
- Colima
- Collibra
- CycloneDX
- Embeddinghub
- Temporal
[ Tools ]
Adopt
- tfsec
Trial
- AKHQ
- cert-manager
- Cloud Carbon Footprint
- Conftest
- kube-score
- Lighthouse
- Metaflow
- Micrometer
- NUKE
- Pactflow
- Podman
- Sourcegraph
- Syft
- Volta
- Web Test Runner
Assess
- CDKTF
- Chrome Recorder panel
- Excalidraw
- GitHub Codespaces
- GoReleaser
- Grype
- Infracost
- jc
- skopeo
- SQLFluff
- Terraform Validator
- Typesense
[ Languages & Frameworks ]
Adopt
- SwiftUI
- Testcontainers
Trial
- Bob
- Flutter-Unity widget
- Kotest
- Swift Package Manager
- Vowpal Wabbit
Assess
- Android Gradle plugin - Kotlin DSL
- Azure Bicep
- Capacitor
- Java 17
- Jetpack Glance
- Jetpack Media3
- MistQL
- npm workspaces
- Remix
- ShedLock
- SpiceDB
- sqlc
- The Composable Architecture
- WebAssembly
- Zig
1件のコメント
『伽藍とバザール』が何なのか気になって調べてみたら、翻訳版の電子書籍も無料で公開されているんですね。少し前の
faker.jsとcolor.jsの件もそうですが、オープンソースがどうやって収益を上げられるのか（そしてどうすれば持続可能なのか）は、オープンソースのエコシステムにかなり依存するようになった昨今、ますます重要な問題になってきていますね。