GNU/Linux >> Znalost Linux >  >> Linux

Proč by váš open-source projekt rozhodně neměl být dalším Kubernetes

V open source projektech neexistuje žádná univerzální definice úspěchu.

V dnešní době se každý věnuje open source. Microsoft právě vydal svůj software 3D Movie Maker pod open source licencí. Spotify má spoustu projektů, které vydalo a na které přispívá, a právě oznámilo fond na podporu správců projektů. Dokonce existuje i kód herního enginu ze středověku (1998) s otevřeným zdrojovým kódem.

Otevřený zdroj:Pokrytí, které si musíte přečíst

Vzhledem k těmto projektům a milionům dalších, které jsou k dispozici, je na místě se ptát… proč? Nebo spíše, proč na velké většině těchto projektů záleží a komu? Většina projektů koneckonců nikdy nebude Kubernetes.

Po více než dvou desetiletích v open source si však začínám uvědomovat, že je to špatná otázka.

Příklad Firecracker

Vezměte si Firecracker, open-source, mikrovirtualizační projekt, který společnost AWS vydala v roce 2018. Firecracker byl téměř všeobecně oslavován jako skvělá technologie… a poté většinou zmizel z veřejného pohledu. Psal jsem o nějakém raném úspěchu komunity, ale i ten (Weave Ignite, mimo jiné pro zlepšení snadnosti použití Firecrackeru) přišel od blízkého partnera AWS. Abych dal Firecrackeru větší sílu pro komunitu, navrhl jsem, aby AWS následovala Google a otevřela řízení kolem Firecrackeru, nejen jeho kódu.

AWS neposlouchal, ale ne poprvé se zdálo, že na mém názoru nezáleželo. (To je zdvořilý způsob, jak říct, že jsem se možná mýlil.)

Rychle vpřed do roku 2022 a Firecracker se tiše začíná používat na spoustě cool míst. Říkám „tiše“, protože, no, proč by někdo křičel jejich infrastrukturu ze střech? Ale když jsem se zeptal, objevili se někteří zajímaví uživatelé, jako Stripe, Fly.io, System Initiative a další. Samozřejmě stále platí, že většinu přispěvatelů do Firecracker zaměstnává AWS.

Ale i kdyby Firecracker zůstal komunitou jednoho (AWS), pravděpodobně by to stálo za to. Ve skutečnosti je to v podstatě to, co jsem tvrdil, když jsem pracoval pro AWS, což naznačuje, že existují jasné důvody orientované na zákazníka pro open source Firecracker, bez ohledu na zapojení komunity. Open source zajistil, že Firecracker si bude dobře hrát s linuxovou komunitou a umožní zákazníkům těsnější „získání složených produktů“.

Miliony petard

Nyní si přehrajte tento příklad Firecracker krát více než sto milionů GitHub (a další open source) repozitáře. Nejde o to být dalším Kubernetesem. U každého projektu s otevřeným zdrojovým kódem jde o uspokojení potřeb jednotlivého vývojáře, společnosti nebo širší komunity.

Někdy mohou být tyto potřeby velké. V rozhovoru, který jsem měl s vedoucím inženýrství Lyft a zakladatelem Envoy Mattem Kleinem, zdůraznil, že „pro většinu lidí, kteří něco open source, je to ve skutečnosti čistý zápor“, protože „pokud do toho neinvestují, dělat všechny tyto věci [jako PR, marketing a najímání], prostě něco hodí přes zeď.“ Kleinovi pomohlo získání významného, ​​celoodvětvového zapojení do Envoy, aby projekt stál za investici, kterou vložil (a potažmo Lyft).

Ale pravděpodobně ne každý potřebuje dostat takový návrat. V případě Firecrackeru by stačilo otevřené získávání kódu a jen spolupráce se zákazníky, jak jsem uvažoval. Naproti tomu pro Google, který se pravděpodobně snažil prosadit multicloudovou realitu prostřednictvím Kubernetes, to muselo jít ve velkém. Každý projekt bude mít jiné potřeby a různá měřítka úspěšnosti.

Takže nejste další Kubernetes? To je v pořádku. Ani ty nejsi další Firecracker? Taky dobré. Pro vývojáře open source je klíčem zjistit, co znamená zdravý projekt pro vaše konkrétní potřeby, a nenechat se rozptylovat definicemi úspěchu ostatních.

Zveřejnění:Pracuji pro MongoDB, ale názory zde vyjádřené jsou mé .





Odkaz na zdroj


Linux
  1. 9 doplňků s otevřeným zdrojovým kódem, které vylepší váš zážitek z prohlížeče Mozilla Firefox

  2. Proč regulární výraz funguje v X, ale ne v Y?

  3. Proč není CD program?

  1. Proč `md5sum` nedává stejný hash jako internet?

  2. Proč překladový soubor Bash neobsahuje všechny chybové texty?

  3. Proč mi Grep -o -w neposkytuje očekávaný výkon na Mac OS X?

  1. Jak připojit váš linuxový server k projektu fondu NTP

  2. Proč pr_debug linuxového jádra nedává žádný výstup?

  3. Použití chown ke změně skupinového vlastníka adresáře není povoleno....Proč?