Статті

• Nov 25, 2024

  Reflection on Evaluating Human Factors beyond likes of code.

  I’m very glad that more articles like this come out of academia. If you haven’t read it yet, please do, as my thoughts are based on this article.

  Personally as industry worker I suffered a lot from perceived misinterpretation of some usability and easy-of-use metrics for programming languages. Also blanket ignoring that some of my friends and coworkers have problem with understanding of some PL concepts. Also even if I totally agree with message, my perception is that message of article would pass by intended audience and things become “business as usual”. I writing this post, to probably fuel some discussion.

  After writing this I realize that this is more of dump of thoughts, then really reflection on the problems outlined and solutions outlined. I probably comes from educational, or congnitive easieness perspective on the problem. Anyway, let’s continue.

  On usability

  In addition to proposed distinction for target audience I think there one important factor should be added: the level of cognitive ability which user poses. There plenty of developers who even after working decade in the field still may not able to get some advanced concepts. People in academia is smart, and it is sometimes hard for these smart people understand struggle which other people have with some concepts. There people who only do Wordpress development for a living and you cannot say that all of them “just did not find a way out of trap”. Pay is not great even if you live in cheaper country to think that this is best career. So there quite possible natural obstacles why people stay there and not change ecosystem. My personal take, for which I don’t have numeric evidence, is that it’s difficult for developers in this field to acquire the skills needed to move on.

  With this in mind, I’d love to see language features categorized by the minimum level of cognitive ability required for users to understand them.

  Take Monads, for example. The history of popularizing Functional Programming shows us that many developers perceive Monads as something complex and unclear in terms of their usage. At the same time, another group of developers is perfectly comfortable using them daily. By “using them,” I mean not just employing built-in language concepts but also creating their own abstractions when needed. To me, this is an indirect hint at the minimal cognitive requirements necessary to understand the concept. While I don’t discount the possibility that this is partly an educational problem, I don’t think that’s the only factor.

  Okay, okay! It seems I’ve slid too far into rationalizing why I think cognitive requirements for features should be considered as an axis of research.

  Is language independent of ecosystem and community?

  How can we evaluate a programming language without considering its ecosystem? Should we? Or should we instead use the ecosystem as a proxy for determining which concepts are easy to implement in that language? This whole “ecosystem” aspect could be a subfield of Social Sciences. For instance, should we consider a language “easy to use” if it doesn’t have a large and friendly community? But what does “friendly” even mean? Friendly to whom?

  For example, if I want to learn Functional Programming, which community should I turn to? F#, OCaml, Haskell, Lean4? Should we evaluate the complexity of learning a language only in the context of solo learning? Does solo learning even make sense? I think not, as education is generally more effective with peers. But how can we separate a language’s features from the communities that support teaching them?

  I don’t see how we can determine what is “easy to use” without more field studies and user studies. I would really love to see more research focused on human factors. That’s the only way to educate academia on the importance of these factors in programming languages.

  When speaking with people adjacent to researchers, it’s not uncommon for my concerns to be dismissed as mere skill issues on the user’s side. And because I don’t have numbers or papers to back up my concerns, the discussion often isn’t productive—it becomes a matter of faith at that point.

  What if we see less emphasis on human factors in programming language research not because academia is ignorant of these problems, but because researchers don’t know how to effectively measure social impact and instead focus on what’s easier to quantify? In that case, perhaps more user studies are needed to find better ways of examining human aspects.

  Should we start openly discussing which social aspects we want to measure, regardless of the feasibility of conducting a study, and let others think about how to address them? The more ideas circulating about human factors, the better, in my opinion.

  Another area to consider is how we determine whether certain language features or patterns are just a matter of preference. It seems that many things are indeed preferences. One example might be the “for” loop versus “map.” I’d argue that, broadly speaking, the industry prefers “for.” Is this because we’re slow to catch up with academia, or because there aren’t enough practical reasons to convince us that “map” is a better approach? Or perhaps it’s simply a matter of social conformity—we want to write code the same way the great C hackers did? That’s an open question for me.

  After reflecting on my thoughts, I think I agree with all the proposals in the article, except that I’d like to see even more user studies. Otherwise, I’m on standby, ready to help promote these ideas if something needs to be done.

  Some other ideas

  While writing this article, I came up with a couple of questions that I think could inspire interesting experiments. I’d like to share them as potential points for discussion.

  Experiment 1 Analyze public package repositories to identify the concepts proposed as packages. By using NLP on package descriptions, we could determine what concepts are emphasized in the ecosystem. This would allow us to assess which programming language and industry concepts are most commonly supported by a given language.

  I’m thinking of things like parser generators, compilers, databases, etc., but perhaps more patterns could be uncovered. This could serve as a kind of proxy for assessing a language’s capabilities.

  Experiment 2 Create a collaborative platform for HCI-related user studies, designed so that the infrastructure can be run as open source. This setup would allow researchers to spend more time planning experiments, while industry experts could contribute insights into what is valuable but requires time to develop. Such a platform could serve as a hub for brainstorming and devising strategies to address the “Citadel of Numbers” challenge.

  As a model, I have in mind Terence Tao’s Equational Theories project.

  Experiment 3 Identify all commits on GitHub containing keywords like “fix” or “bug” and analyze the linguistic constructs associated with those fixes. The focus should probably be limited to linear fixes, as it’s unclear how to assess whether a specific linguistic feature triggers issues.

• Nov 23, 2024

  Сертіфікований перевіряльник типів

  У цьому прикладі, ми побудуємо сертифікований перевіряльник типів для простої мови виразів яка має лише 2 типа натуральні числа і логічні значення, і лише дві операції додавання і логічне І.

  Зауваження: цей приклад базується на прикладі із книги Certified Programming with Dependent Types Адама Чіліпала і прикладу із репозіторію Lean4.

  Створимо індуктивний тип який описує 4 типа виразів - літерал цілого числа, літерал логічного типа, операція додавання та операція логічного І.

  inductive Expr where
    | nat  : Nat → Expr
    | plus : Expr → Expr → Expr
    | bool : Bool → Expr
    | and  : Expr → Expr → Expr
  

  Ми визначаємо просту мову типів використовуючи індуктивний тип даних Ty. Тип цілого числа буде визначено як випадок nat, тип логічних значень буде визначений як bool. Правила типізації, будуть визначені використовуючи індуктивний предікат HasType. Цей тип визначає стверждення про наявність типа у вираза. У нас будуть 4 типа правил - правила типізації цілого числа, правила типізації логічних типів, правила типізації додавання і правила типізації логічного І. Таким чином ми маємо по одному правилу на кожен тип виразу із Expr.

  inductive Ty where
    | nat
    | bool
    deriving DecidableEq
  
  inductive HasType : Expr → Ty → Prop
    | nat  : HasType (.nat v) .nat
    | plus : HasType a .nat → HasType b .nat → HasType (.plus a b) .nat
    | bool : HasType (.bool v) .bool
    | and  : HasType a .bool → HasType b .bool → HasType (.and a b) .bool
  

  Ми легко можемо показати що якщо e має тип t₁ і тип t₂, тоді t₁ і t₂ повинні бути однакові використовуючи тактику cases. Ця тактика створює нову підціль для кожного конструктора, і автоматично відкидає недоступні випадки. Таким чином cases h₁ створить 4 підцілі, по одній на кожне правило типізації. Комбінатор тактик tac₁ <;> tac₂ застосовує tac₂ до кожної підцілі створеною tac₁. Післі cases h₁ <;> cases h₂ у нас залишаться лише 4 підцілі а не 16, тому що правила типізації для HasType e _ у h₁ і тип h₂ повинні співпадати, через те що e це той самий вираз і у обоїх випадках. Потім, тактика rfl використовується для закриття усіх створених цілей використовуючи рефлексівність.

  theorem HasType.det (h₁ : HasType e t₁) (h₂ : HasType e t₂) : t₁ = t₂ := by
    cases h₁ <;> cases h₂ <;> rfl
  

  Індуктивний тип Maybe p має два конструктора: found a h та unknown. Перший конструктор містить елемент a : α і доказ що a задовольняє предікат p. Конструктор unknown використовується для кодування “помилки”. У нашому прикладі, це буде помилка типізації.

  inductive Maybe (p : α → Prop) where
    | found : (a : α) → p a → Maybe p
    | unknown
  

  Ми визначаємо нотацію для Maybe яка схожа до вбудованої нотації для вбудованого типу Lean Subtype.

  notation " x " => Maybe (fun x => p)
  

  Створимо функцію Expr.typeCheck e яка повертає тип ty і доказ того що e має тип ty, або unknown. Зауважте що, def Expr.typeCheck ... у Lean це нотація до namespace Expr def typeCheck ... end Expr. Терм .found .nat .nat це сахар до Maybe.found Ty.nat HasType.nat. Lean може вивести використовуємий простір імен для очікуваних типів. Нотація e.typeCheck це також сахар для виклику Expr.typeCheck e.

  def Expr.typeCheck (e : Expr) :  :=
    match e with
    | nat ..   => .found .nat .nat
    | bool ..  => .found .bool .bool
    | plus a b =>
      match a.typeCheck, b.typeCheck with
      | .found .nat h₁, .found .nat h₂ => .found .nat (.plus h₁ h₂)
      | _, _ => .unknown
    | and a b =>
      match a.typeCheck, b.typeCheck with
      | .found .bool h₁, .found .bool h₂ => .found .bool (.and h₁ h₂)
      | _, _ => .unknown
  
  theorem Expr.typeCheck_correct (h₁ : HasType e ty) (h₂ : e.typeCheck ≠ .unknown)
          : e.typeCheck = .found ty h := by
    revert h₂
    cases typeCheck e with
    | found ty' h' =>
      intro;
      have := HasType.det h₁ h';
      subst this;
      rfl
    | unknown =>
      intro;
      contradiction
  

  Тепер ми докажемо що якщо Expr.typeCheck e повертає Maybe.unknown, тоді для усіх ty, HasType e ty не виконується. Lean може це вивести тому що ми явно сказали що e має тип Expr. Доказ буде по індукції по e і аналізу випадків. Ми кажемо що змінна недоступна якщо вона введена тактикою (наприклад, cases) або була затінена іншою змінною variable введеною користувачем. Зверніть увагу що тактика simp [typeCheck] застосовується для усіх цілей згенерованих тактикою induction, і закриває випадки відповідні до конструкторів Expr.nat та Expr.bool. Тактика split розбиває вираз match у цілі на нові підцілі, і ми доводимо їх ітеруя одну за одною за допомогою ‘next`.

  theorem Expr.typeCheck_complete {e : Expr} : e.typeCheck = .unknown → ¬ HasType e ty := by
    induction e with simp [typeCheck]
    | plus a b iha ihb =>
      split
      next => intro; contradiction
      next ra rb hnp =>
        -- Зверніть увагу що `hnp` це гіпотеза згенерована тактикою `split`
        -- яка стверждує що попередній випадок не був використаний
        intro h ht
        cases ht with
        | plus h₁ h₂ =>
          exact hnp h₁ h₂ (typeCheck_correct h₁ (iha · h₁)) (typeCheck_correct h₂ (ihb · h₂))
    | and a b iha ihb =>
      split
      next => intro; contradiction
      next ra rb hnp =>
        intro h ht
        cases ht with
        | and h₁ h₂ =>
          exact hnp h₁ h₂ (typeCheck_correct h₁ (iha · h₁)) (typeCheck_correct h₂ (ihb · h₂))
  

  Нарешті, ми показуємо що перевірка типа для e може бути вирішена використовуючи Expr.typeCheck. Для цього ми робимо показуємо екземпляр типу Decidable (HasType e t) і за допомогою раніше доведених функцій Expr.typeCheck_complete та HasType.det показуємо як доводити вирішеність.

  instance (e : Expr) (t : Ty) : Decidable (HasType e t) :=
    match h' : e.typeCheck with
    | .found t' ht' =>
      if heq : t = t' then
        isTrue (heq ▸ ht')
      else
        isFalse fun ht => heq (HasType.det ht ht')
    | .unknown => isFalse (Expr.typeCheck_complete h')
  

  Файл який можна завантажити на Гісті.

• Nov 5, 2024

  Вартість програмного забезпечення з відкритим кодом

  Це переклад статті від Гарвадської школи бізнеса. Орігінал тут

  Зміст

  • Анотація
  • 1. Вступ
  • 2. Емпіричне налаштування та дані
  • 3. Методика
  • 4. Результати
  • 5. Висновок
  • Онлайн-додаток

  Manuel Hoffmann

  Harvard Business School

  Frank Nagle

  Harvard Business School

  Yanuo Zhou

  University of Toronto

  Copyright © 2024 by Manuel Hoffmann, Frank Nagle, and Yanuo Zhou. Working papers are in draft form. This working paper is distributed for purposes of comment and discussion only. It may not be reproduced without permission of the copyright holder. Copies of working papers are available from the author. The authors are grateful for financial and administrative support from the Linux Foundation without which the data from the Census would not have otherwise been available. We greatly appreciate the support of the Research Computing Services at Harvard Business School, the Laboratory for Innovation Science at Harvard, the Linux Foundation, and the software composition analysis data providers Snyk, the Synopsys Cybersecurity Research Center, and FOSSA. We thank Tianli Li and Misha Bouzinier for excellent research assistance. We are also thankful to the software developer Boris Martinovic as well as Rich Lander and Scott Hanselman from Microsoft for insights into the .NET ecosystem. We received helpful feedback from participants at the Harvard Business School Values and Valuations Conference, the Harvard Business School D3 Research Day, and the 2023 Academy of Management Conference. Funding for this research was provided in part by Harvard Business School.

  Вартість програмного забезпечення з відкритим кодом

  Manuel Hoffmanna Frank Nagle b Yanuo Zhouc This version: January 1, 2024

  Анотація

  Вартість негрошового (безкоштовного) продукту за своєю суттю важко оцінити. Поширеним прикладом є програмне забезпечення з відкритим кодом (ВВК), глобальне суспільне благо, яке відіграє життєво важливу роль в економіці та є основою для більшості технологій, які ми використовуємо сьогодні. Однак важко виміряти цінність ВВК через його негрошовий характер і відсутність централізованого відстеження використання. Таким чином, ВВК залишається значною мірою неврахованим в економічних показниках. Незважаючи на те, що попередні дослідження оцінювали витрати з боку пропозиції на відтворення цього програмного забезпечення, брак даних заважав оцінити набагато більшу цінність на стороні попиту (користування), яку створює ВВК. Тому, щоб зрозуміти повну економічну та соціальну цінність широко використовуваного ВВК, ми використовуємо унікальні глобальні дані з двох додаткових джерел, які фіксують використання ВВК мільйонами глобальних компаній. Спочатку ми оцінюємо цінність з боку пропозиції, підраховуючи вартість одноразового відтворення найпоширенішого ВВК. Потім ми розраховуємо вартість на стороні попиту на основі вартості заміни для кожної фірми, яка використовує програмне забезпечення та потребувала б створити його всередині компанії, якби ВВК не існувало. За нашими оцінками, вартість широко використовуваних ВВК на стороні пропозиції становить 4,15 мільярда доларів, але вартість на стороні попиту набагато вища – 8,8 трильйона доларів. Ми виявили, що компаніям довелося б витрачати в 3,5 рази більше на програмне забезпечення, ніж зараз, якби ВВК не існувало. Шість найкращих мов програмування в нашій вибірці становлять 84% цінності ВВК з боку попиту. Крім того, 96% цінності з боку попиту створюють лише 5% розробників ВВК.

  JEL Classification: H4; O3; J Keywords: Open-source software, global public good

  Acknowledgement: The authors are grateful for financial and administrative support from the Linux Foundation without which the data from the Census would not have otherwise been available. We greatly appreciate the support of the Research Computing Services at Harvard Business School, the Laboratory for Innovation Science at Harvard, the Linux Foundation, and the software composition analysis data providers Snyk, the Synopsys Cybersecurity Research Center, and FOSSA. We thank Tianli Li and Misha Bouzinier for excellent research assistance. We are also thankful to the software developer Boris Martinovic as well as Rich Lander and Scott Hanselman from Microsoft for insights into the .NET ecosystem. We received helpful feedback from participants at the Harvard Business School Values and Valuations Conference, the Harvard Business School D^3 Research Day, and the 2023 Academy of Management Conference.

  M5S 3E6, Canada, E-Mail: yanuo.zhou@rotman.utoronto.ca.

  1. Вступ

  У 2011 році венчурний капіталіст Марк Андріссен (Mark Andreessen) висловив знамениту думку про те, що «програмне забезпечення поїдає світ» (Andreessen, 2011), сьогодні мало хто сперечатиметься з цим. Нещодавно венчурний капіталіст Джозеф Джекс(Joseph Jacks) стверджував, що «відкрите програмне забезпечення з’їдає програмне забезпечення швидше, ніж програмне забезпечення з’їдає світ» (Jacks, 2022). Інші останні дослідження дійшли подібних висновків, показуючи, що програмне забезпечення з відкритим кодом (ВВК) – програмне забезпечення, вихідний код якого є загальнодоступним для перевірки, використання та модифікації та часто створюється децентралізованим способом і поширюється безкоштовно – з’являється в 96% кодових баз. (Synopsys 2023) і що деяке комерційне програмне забезпечення на 99,9% складається з вільно доступних ВВК (Musseau та ін., 2022). Хоча на початку свого існування ВВК часто копіював функції з існуючого пропрієтарного програмного забезпечення, сьогодні ВВК включає передові технології в різних сферах, включаючи штучний інтелект (AI), квантові обчислення, великі дані та аналітику. Однак, незважаючи на зростаючу важливість ВВК для всього програмного забезпечення (і, отже, для всієї економіки), виміряти його вплив було важко. Традиційно, щоб виміряти вартість, створену товаром або послугою, економісти множать ціну (p) на продану кількість (q). Проте в ВВК p зазвичай дорівнює нулю, оскільки вихідний код є загальнодоступним, а q невідомий через обмежену кількість обмежень щодо того, як код можна копіювати та повторно використовувати. Наприклад, якщо компанія завантажує частину ВВК із загальнодоступного репозіторія коду, вона може скопіювати її тисячі разів всередину (на законних підставах), а потім поділитися з постачальниками чи клієнтами (також на законних підставах), тому загальнодоступних даних для завантаження недостатньо. Незважаючи на те, що деякі нещодавні дослідження намагалися оцінити значення p (обговорюється нижче), дані для оцінки q були недоступні або важкооброблені для чогось іншого, ніж просто для кількох пакетів ВВК. Використовуючи нещодавно зібрані дані з багатьох джерел, мета цієї статті — надати оцінки як для p, так і для q та використати їх, щоб прояснити питання: яка цінність програмного забезпечення з відкритим кодом?

  Розуміння цінності ВВК має вирішальне значення не лише через роль, яку вона відіграє в економіці, але й через те, що вона є одним із найуспішніших і найвпливовіших сучасних прикладів багатовікової економічної концепції «загальних благ», яка має ризик зустріти долю, відому як «трагедія громад». Ця концепція сягає корінням ще в 4-е століття до нашої ери, філософ Аристотель, який писав: «Те, що є спільним для найбільшої кількості людей, потребує найменшої уваги. Люди найбільше звертають увагу на те, що є своїм, і менше піклуються про те, що є спільним». (Аристотель, 1981). Вільям Форстер Ллойд (1833) відновив цю ідею в сучасній економічній думці, навівши приклад спільних ділянок землі, які використовувалися для випасу худоби кількома пастухами, кожен з яких мав стимул надмірно використовувати спільний ресурс. Гаррет Гардін (1968) переніс цю концепцію в ширший дух часу, коли написав статтю, де обговорював проблему під назвою «Трагедія громад». Спираючись на цю роботу, Елінор Остром отримала Нобелівську премію за дослідження, що висвітлює шляхи уникнення трагедії громад шляхом координації зусиль громади, які не вимагають застосування державними законами для управління та охорони спільного надбання (Ostrom 1990). Паралелі між спільними пасовищами та спільною цифровою інфраструктурою є відчутними – доступність комунальної трави для годування худоби та, у свою чергу, годування людей, була критично важливою для аграрної економіки, а можливість не відтворювати код, який уже написав хтось інший, має вирішальне значення для сучасної економіки. Крім того, в обох контекстах, незважаючи на те, що знаємо, що трава і код є критично важливими факторами економіки, виміряти їх фактичну вартість важко. І, як вважається, сказав відомий математик і фізик лорд Кельвін: «Якщо ви не можете це виміряти, ви не можете це покращити». І якщо ви не можете покращити та підтримувати їх, такі загальні блага можуть розвалитися під вагою власного успіху, оскільки їх надмірно використовують, але в них недостатньо інвестують (Ліфшиц-Ассаф та Нейгл, 2021). Тому вимірювання цінності, яку створює ВВК, має вирішальне значення для майбутнього здоров’я цифрової економіки та решти економіки, яка побудована на ній.

  Важливо те, що останні дослідження намагалися вирішити ці проблеми вимірювання, але не змогли охопити як широту, так і глибину використання ВВК – прогалину, яку ми прагнемо заповнити цією роботою. Наприклад, дослідники намагалися розширити масштаби, використовуючи нові методології, щоб оцінити вартість заміщення робочої сили поточного корпусу ВВК, створеного в Сполучених Штатах як 38 мільярдів доларів у 2019 році (Robbins et al., 2021), а також того, що було створено в Європейському Союзі. як 1 мільярд євро (Blind et al., 2021) шляхом врахування витрат на оплату праці, які були б потрібні для переписування існуючого ВВК. Такі зусилля дуже добре допомагають оцінити, скільки коштуватиме заміна всього існуючого ВВК, якщо вони зникнуть завтра. Однак отримані оцінки ґрунтуються на двох важливих припущеннях. По-перше, що весь ВВК є однаково цінними з точки зору використання, а по-друге, що концепція ВВК все ще існуватиме, і суспільству потрібно буде лише один раз переписати код, таким чином вирішуючи вищезгадану проблему відсутнього значення для p, але не вирішуючи відсутнє значення q. У світі, де ВВК взагалі не існувало, кожну частину програмного забезпечення ВВК не потрібно було б переписувати лише один раз, а натомість мала б бути переписана кожною фірмою, яка використовує програмне забезпечення (припускаючи, що фірма може вільно ділитися програмним забезпеченням у межах його межі). Інші дослідження (Greenstein and Nagle, 2014; Murciano-Goroff, Zhuo, and Greenstein, 2021) заглибилися в цю гіпотезу, хоча й у вузькій манері, зосередившись лише на веб-серверах (які є загальнодоступними в Інтернеті і тому можуть легко виміряти). Використовуючи різні методи, обидва дослідження вимірюють q для цього одного типу програмного забезпечення та приписують p за допомогою підходу відновної вартості товару на основі цін на альтернативи із закритим кодом, які пропонують фірми. З даними зі Сполучених Штатів отримані оцінки показують вартість ВВК Apache Web Server у 2 мільярди доларів у 2012 році (Greenstein and Nagle, 2014) і загальну вартість у 4,5 мільярда доларів США для Apache та ВВК веб-сервера nginx у 2018 році (Murciano-Goroff та ін., 2021). Однак, хоча веб-сервери є важливою частиною екосистеми ВВК, вони становлять невелику її частину. Ми прагнемо спиратися на важливий внесок, зроблений цими існуючими дослідженнями, намагаючись вийти як широко, так і глибоко, щоб створити більш повну міру цінності ВВК.

  Щоб розглянути цінність ВВК як широко, так і глибоко, ми використовуємо дані з двох основних джерел, які дозволяють нам отримати уявлення про ВВК, що використовується в десятках тисяч компаній у всьому світі. Перший – це «Census II вільного програмного забезпечення з відкритим кодом – бібліотеки програм» (Nagle та ін., 2022). Проект Census II використовував партнерство з кількома фірмами, що займаються аналізом складу програмного забезпечення (SCA), щоб створити різноманітні списки найбільш широко використовуваних ВВК. SCA наймають для сканування кодових баз компанії, щоб переконатися, що вони не порушують жодних ліцензій ВВК, і, як побічний продукт, відстежують увесь код ВВК, який використовують їхні клієнти, і продукти, які вони створюють. Проект Census II зібрав дані з кількох SCA для створення набору даних про використання ВВК у десятках тисяч фірм на основі мільйонів точок даних (спостережень за використанням ВВК). Другим джерелом даних є набір даних BuiltWith, з якого ми використовуємо сканування майже дев’яти мільйонів веб-сайтів, щоб визначити основну технологію, що розгортається на цих веб-сайтах, включаючи бібліотеки ВВК. Дані BuiltWith використовувалися в багатьох академічних дослідженнях (DeStefano & Timmis 2023, Dushnitsky & Stroube 2021, Koning et al.. 2022), але, наскільки нам відомо, це перше дослідження, яке присвячене використанню ВВК. Дані Census II і дані BuiltWith доповнюють один одного, оскільки перший зосереджується на ВВК, вбудованому в програмне забезпечення, яке продає компанія, тоді як другий зосереджується на ВВК, вбудованому на веб-сайт компанії, таким чином зменшуючи ймовірність подвійного підрахунку спостережень у наборах даних. У сукупності ці два набори даних створюють найповніше вимірювання використання ВВК ( q ) на сьогодні. Крім того, зосереджуючись на ВВК, яка широко розгорнута та використовується компаніями, а не на розгляді всіх проектів, які існують у сховищі ВВК, ми вдосконалюємо методології попередніх досліджень, зменшуючи ймовірність помилки вимірювання, що виникає в результаті проектів, які публікуються як загальнодоступні ВВК, але фактично практично не використовуються. Неврахування цієї помилки вимірювання призведе до переоцінки фактичної вартості ВВК, оскільки проекти, які широко використовуються, оцінюватимуться так само, як проекти, які не використовуються взагалі.

  Щоб оцінити p, ми дотримуємося літератури, розглянутої вище, і використовуємо вартість праці по заміні. По-перше, ми обчислюємо витрати на оплату праці окремої фірми, щоб відтворити даний пакет ВВК, вимірюючи кількість рядків коду в пакеті, а потім застосовуючи модель конструктивних витрат II (Boehm, 1984; Boehm et al., 2009). – також відомий як COCOMO II – щоб оцінити кількість людино-годин, які знадобляться для написання коду з нуля. Потім ми використовуємо глобальні дані про заробітну плату від Salary Expert, щоб отримати точну оцінку витрат на оплату праці, які б понесла фірма, якби цієї частини ВВК не існувало. Ці витрати можна поєднати зі значеннями q вище на рівні пакету ВВК, щоб оцінити загальну вартість усіх ВВК як з боку пропозиції, так і з боку попиту.

  Ми знаходимо вартість у діапазоні від 1,22 мільярда до 6,22 мільярда доларів, якщо ми вирішили як суспільство відтворити увесь широко використовуваний ВВК зі сторони пропозиції. Проте врахування фактичного використання ВВК призводить до того, що вартість з боку попиту на порядки більша і коливається від $2,59 трлн до $13,18 трлн, якби кожна фірма, яка використовувала пакет ВВК, мала відтворити його з нуля (наприклад, концепції ВВК не існувало). Ми документуємо значну неоднорідність значення ВВК за мовою програмування, а також зусилль щодо внутрішнього та зовнішнього програмування. Крім того, ми знаходимо значну неоднорідність у внесках цінності програмістів, оскільки 5% програмістів відповідають за понад 90% цінності, створеної на стороні попиту та пропозиції. Дані, які ми використовуємо, є, мабуть, найповнішим джерелом даних для вимірювання цінності, створеної використанням компаніями ВВК на даний момент. Однак, як і для будь-якого проекту, докази не є повними, і ми стверджуємо, що недооцінюємо цінність, оскільки наші дані, наприклад, не включають операційні системи, які є значною мірою пропущеною категорією ВВК.

  Це дослідження робить чотири важливі внески до наукової літератури, практиків і політиків. По-перше, воно надає найповнішу оцінку вартості широко використовуваних ВВК на сьогоднішній день, враховуючи не лише пропозицію ВВК (ціну на її створення), але й використання/попит у масштабі, який не було зроблено раніше. У той час як попередні оцінки цінності ВВК були лише широкими (оцінка витрат з боку пропозиції великої групи ВВК) або глибокими (оцінка вартості, створеної одним конкретним типом ВВК), це дослідження робить і те, і інше за допомогою унікальних наборів даних, які дозволяють краще зрозуміти широту та глибину використання ВВК. Крім того, замість того, щоб вимірювати цінність усіх ВВК, це дослідження зосереджено на цінності ВВК, яка використовується компаніями для створення своїх продуктів і веб-сайтів, обмежуючи похибку вимірювання, що виникає в дослідженнях, які не можуть пояснити, для яких ВВК насправді використовується в виробництві. Цей внесок спирається на важливі дослідження (наприклад, Blind та ін., 2021; Greenstein та Nagle, 2014; Murciano-Goroff та ін., 2021; Robbins та ін., 2021), які намагалися визначити цінність цього життєво важливого ресурсу, який робить великий внесок у сучасну економіку, незважаючи на труднощі у вимірювання цього внеску. Роблячи це, дослідження додає ідеї до тривалої дискусії, пов’язаної з впливом інформаційних технологій (ІТ) на продуктивність (Brynjolfsson, 1993; Brynjolfsson and Hitt, 1996; Nagle, 2019a; Solow, 1987), відомої як «парадокс продуктивності», де інвестиції в ІТ можуть мати обмежений вплив на статистику продуктивності. Ці дебати тривають у новому контексті ШІ (Brynjolfsson, Rock, and Syverson, 2018). Наша робота сприяє цій розмові, висвітлюючи значну економію коштів на суспільному рівні (і, отже, підвищення продуктивності), яку створює існування ВВК.

  По-друге, наше дослідження вносить методологічний прогрес у вивчення нематеріального капіталу, висвітлюючи нові джерела даних, пов’язаних з інвестиціями в ВВК. Попередні дослідження показали, що нематеріальний капітал відіграє дедалі важливішу роль в економічному зростанні (Corrado, Hulten, and Sichel, 2009) і вартості фірми (Peters and Taylor, 2017), але його часто не вимірюють або неправильно розподіляють (Eisfeldt and Papanikolaou, 2014). Крім того, ми демонструємо, як ці джерела даних можна використовувати, щоб зрозуміти справжні інвестиції в програмне забезпечення, які робить фірма, і те, що вони повинні були б зробити, якби ВВК не існувало. Це важливо, оскільки інвестиції в програмне забезпечення стають дедалі важливішим типом нематеріального капіталу, який сприяє інноваціям (Branstetter, Drev, and Kwon, 2019) і продуктивності (Krishnan et al., 2000).

  По-третє, наші результати допомагають підкреслити для компаній і менеджерів важливість ВВК для їхнього виробництва та в ідеалі додають ваги аргументам про те, що користувачі ВВК повинні не лише безкоштовно користуватися, але й робити свій внесок у створення та підтримку ВВК (наприклад, Henkel, 2008; Нейгл, 2018). Такі внески становлять незначну частину витрат, які б зазнали фірми, якби ВВК не існувало, і активна участь користувачів ВВК у підтримці ВВК, яку вони використовують, має вирішальне значення для здоров’я та майбутнього добробуту екосистеми ВВК (Ліфшиц-Ассаф і Nagle, 2021; Чжан та ін., 2019).

  По-четверте, і нарешті, наше дослідження допомагає інформувати політиків, які нещодавно почали розуміти зростаючу важливість ВВК для економіки та вжили заходів для підтримки екосистеми (Європейська комісія, 2020; виконавчий наказ № 14028, 2021). Однак більшість цих зусиль пов’язані із забезпеченням безпеки існуючої екосистеми ВВК, що є досить важливим, але не доходить до підтримки створення нових ВВК. Наші результати допомагають пролити світло на важливість ВВК для загальної економіки та додати ваги закликам до більшої суспільної підтримки цього важливого ресурсу. Наші результати також показують, що більшість цінностей, створених ВВК, створюється невеликою кількістю учасників. Хоча вже давно відомо, що невелика кількість учасників ВВК виконує більшу частину роботи, ми додаємо нові відомості, які показують, що це ще більше стосується створення цінності широко використовуваних проектів ВВК і що суспільна підтримка цих осіб є критично важливою для майбутній успіху ВВК і, у свою чергу, економіки.

  Інша частина цього документа організована таким чином. Розділ 2 описує емпіричне налаштування та дані. Розділ 3 обговорює методи, включаючи проблеми вимірювання. У розділі 4 ми оцінюємо цінність програмного забезпечення з відкритим кодом. Розділ 5 завершується.

  2. Емпіричне налаштування та дані

  Хоча концепція вільного та відкритого програмного забезпечення існує з 1950-х років, вона стала більш популярною у 1980-х роках завдяки зусиллям Річарда Столмана та його запуску проекту GNU та Фонду вільного програмного забезпечення (Maracke, 2019). Однак саме в 1990-х роках ВВК набула популярності після того, як Лінус Торвальдс випустив ядро ​​Linux, широко поширену операційну систему ВВК (Tozzi, 2016). Сьогодні ВВК вважається ключовим будівельним блоком цифрової економіки та широко використовується розробниками програмного забезпечення в усьому: від телефонів до автомобілів, холодильників і передового штучного інтелекту (Lifshitz-Assaf and Nagle, 2021).

  Ми використовуємо два основних джерела даних, які доповнюють один одного, щоб оцінити цінність ВВК. Перший – це Cesus, звернений всередину. Це дозволяє нам ідентифікувати код ВВК, який входить до продуктів, які створюють компанії. Другий набір даних — це BuiltWith і спрямований назовні, що дозволяє нам ідентифікувати код ВВК, з яким споживачі безпосередньо взаємодіють через веб-сайти фірм. Оскільки необроблені дані в обох наборах даних містять лише назви пакетів, номери версій та імена менеджерів пакетів і не містять жодної інформації, пов’язаної з вихідним кодом, ми спочатку отримуємо загальнодоступне сховище коду для кожного пакета, яке містить інформацію на рівні пакета, включаючи рядки коду та використовуваних мов програмування. Можна хвилюватися про подвійний підрахунок для розрахунків вартості в результаті використання двох окремих наборів даних. Однак перекриття вибірки Census і BuiltWith дуже невелике: в обох наборах даних знайдено лише 18 пакетів. Крім того, малоймовірно, що подвійний підрахунок викликає занепокоєння, оскільки два набори даних фіксують різні виміри використання ВВК: Census фіксує упаковане програмне забезпечення, використання якого спрямоване всередину, тоді як BuiltWith фіксує використання на веб-сайтах, які спрямовані назовні. Нарешті, як додатковий набір даних ми використовуємо GHTorrent, детальну історію діяльності, пов’язаної з ВВК, на GitHub, найпопулярнішій платформі розміщення ВВК і широко використовуваному джерелі даних для досліджень ВВК (наприклад, Burton et al, 2017; Conti, Peukert і Roche, 2023; Fackler, Hofmann і Laurentsyeva, 2023; Ці детальні історичні дані дозволяють нам глибше зрозуміти, як створюється цінність ВВК, завдяки кращому розумінню розподілу внесків між окремими розробниками ВВК. Нижче ми описуємо деталі всіх трьох джерел даних та їхню підготовку до оцінки.

  Перепис. Другий перепис (Census II) вільного програмного забезпечення з відкритим кодом (тут: Перепис) спільно провели Linux Foundation і Лабораторія науки про інновації в Гарварді (Нагл та ін., 2022).¹ Перепис було створено шляхом агрегування даних від трьох великих компаній з аналізу складу програмного забезпечення (SCA), які мають тисячі клієнтів по всьому світу. SCA наймають для сканування кодової бази клієнта та збору даних про використання ВВК, вбудованого в їхнє власне програмне забезпечення, щоб переконатися, що вони не порушують жодних ліцензійних угод ВВК.² Часто це відбувається як частина процесу аудіту, пов’язаного зі злиттям і придбанням (merge and aсquistion). На відміну від інших вимірювань попиту на ВВК, доступних із загальнодоступних джерел, таких як підрахунок завантажень пакетів і зміни коду, спосіб збору цих даних гарантує, що ми спостерігаємо точну кількість і тип внутрішнього використання ВВК фірмами. Крім того, це дозволяє нам відстежувати залежності, на які покладається кожен пакет, щоб ми могли спостерігати непряме використання ВВК, яке зазвичай приховано та важко отримати.³ Результатом є понад 2,7 мільйона спостережень пакетів ВВК, які використовуються всередині продукти, створені фірмами-клієнтами SCA на 2020 календарний рік (з 1 січня по 31 грудня 2020 року).⁴

  Проект Census стандартизував назви пакетів на основі системи імен libraries.io – широко використовуваного сайту, підтримуваного Tidelift, який упорядковує інформацію про понад вісім мільйонів пакетів з відкритим кодом. Перепис зосередився на 2000 найпопулярніших пакетів на основі даних про використання, повідомлених трьома найвідомішими постачальниками SCA, щоб визначити найпоширеніші ВВК, а не довгий хвіст розподілу використання. Це призвело до того, що пакети з менш ніж п’ятьма спостереженнями використання були видалені. Оскільки пакунки, написані на мові програмування JavaScript і зазвичай розміщені в Node Package Manager (NPM), зазвичай менші (менша кількість рядків коду), ніж пакунки на інших мовах, і тому часто мають більші показники використання (оскільки розробники повинні включити багато невеликих пакетів замість кількох великих пакетів), перепис окремо відібрав 1000 найпопулярніших пакетів NPM і 1000 найпопулярніших пакетів, які не є NPM.

  Цей остаточний набір даних охоплює 70% загального використання ВВК, спостережуваного в необроблених даних перепису.⁵ Для кожного з цих 2000 пакетів ВВК у переписі ми визначили необроблений код, який підтримується на GitHub, найбільш поширеній платформі. для розміщення ВВК.⁶ Спочатку ми спробували отримати уніфікований покажчик ресурсів (URL) репозіторію GitHub для кожного пакета з libraries.io. Нам вдалося зіставити 1657 пакетів зі сховищами за допомогою цього початкового методу.⁷ Для URL-адрес без відповідного репозіторію ми здійснили пошук Google, дотримуючись методу Сінгха (2020). Зокрема, для кожного невідповідного пакета ми використовували Google API для пошуку назви пакета та «Сховища GitHub» і розглядали першу URL-адресу репозіторію GitHub у результатах як найкращу відповідну URL-адресу GitHub.⁸ Це призвело до додаткового 174 пакунки підійшли до репозиторію. Нарешті, ми вручну шукали URL-адреси для решти 169 пакетів, щоб визначити відповідне сховище. Весь цей процес призвів до зіставлення 1840 із 2000 пакетів Census до репозіторію коду з необробленим вихідним кодом для пакета. Було визначено, що невідповідні пакети були або видалені з GitHub, або стали власністю (і тому оригінальний вихідний код більше не був доступний), і, отже, ручний пошук дозволив нам видалити ці 160 невідповідних пакетів (менше 8% вибірки перепису). 2000) з високою достовірністю згідно з нашим аналізом.

  BuiltWith. Дані BuiltWith містять сканування всіх загальнодоступних веб-сайтів у всьому світі та ідентифікують технології, які вони використовують. На відміну від даних перепису, спрямованих усередину, які зосереджені на використанні ВВК, сканування даних BuiltWith для використання як пропрієтарних, так і ВВК на веб-сайтах фірм без чіткої диференціації. Щоб відокремити ВВК від пропрієтарного програмного забезпечення в BuiltWith, ми звернемося до підмножини всього програмного забезпечення веб-розробки з відкритим кодом у категорії технологій, яка включає «JavaScript та його бібліотеки», яка генерує 778 спостережень, що відповідають категорії NPM ВВК у даних перепису. Є дві причини для такого вибору вибірки. По-перше, ця дана категорія створена BuiltWith, і ми використовуємо її як проксі для ВВК, щоб відокремити її від грошового програмного забезпечення. По-друге, JavaScript, одна з основних технологій для створення веб-сайтів, є найпопулярнішою мовою програмування використовуємою на GitHub (GitHub, 2022) і, таким чином, дозволяє нам охопити найважливіші ВВК з точки зору попиту. Сканування охоплює 8,8 мільйона унікальних веб-сайтів і 72,8 мільйона відповідних спостережень за використанням ВВК з 1 січня по 16 листопада 2020 року. Крім того, щоб переконатися, що ми вимірюємо цінність використання ВВК у приватному секторі, ми зіставляємо прийнятні домени JavaScript ВВК від BuiltWith із веб-сайтами компаній, записаними в Orbis, Compustat і PitchBook, трьох широко використовуваних базах даних корпоративної діяльності, які фіксують зареєстровані підприємства по всьому світу. Виконання цього збігу гарантує, що ВВК, який використовується некомерційними веб-сайтами (наприклад, особистим веб-сайтом окремої особи), буде виключено з нашого аналізу. Це призводить до рівня відповідності 38,6%, що відповідає приблизно 3 мільйонам веб-сайтів різних фірм.

  Для даних BuiltWith ми не можемо застосувати перший метод, який використовуємо для перепису (використовуючи libraries.io для визначення URL-адреси сховища), оскільки BuiltWith надав лише назви технологій, пов’язані з пакетами, та іншу інформацію (наприклад, пакет і імена менеджерів пакунків) не включено.⁹ Отже, ми починаємо з виконання методу пошуку Google, згаданого вище, який призводить до відповідності 695 пакунків репозиторіям. Потім ми вручну здійснили пошук за URL-адресами Github для 83 із решти невідповідних пакетів, у результаті чого додано 46 пакетів. Загалом для даних BuiltWith ми змогли ідентифікувати 741 із 778 збігів пакетів із сховищами. Як і дані перепису, решта 37 невідповідних пакетів (менше 5%) виключено з нашого аналізу, оскільки їх було видалено з GitHub.

  База даних GHTorrent. Щоб отримати вимірювання дисперсії створення цінності ВВК, ми використовуємо базу даних GHTorrent, яка містить всю історію активності на GitHub за допомогою інтерфейсу прикладного програмування (API) GitHub Representational State Transfer (REST). Щоб оцінити внесок кожного розробника, ми використали його записи про репозиторії GitHub, комісії на рівні розробника та інформацію про загальнодоступний профіль розробника. Ми звузили вибірку для нашого аналізу внеску розробників у два етапи. По-перше, ми відвіяли репозиторії GitHub та їхні коміти з GHTorrent на основі URL-адрес сховища нашого спільного зразка Census-BuiltWith.¹⁰ По-друге, ми зосереджуємося на людському внеску в ВВК, видаливши приблизно вісім тисяч (12%) учасників GitHub, які ми вважали роботами.¹¹ Остаточна вибірка містить близько шістдесяти тисяч розробників і 2,3 мільйона комітів.

  Щоб підготувати ці три набори даних для оцінки, ми спочатку визначили кількість рядків коду та мови програмування, які використовуються для кожного пакета, використовуючи пакети ВВК pygount (для підрахунку кількості рядків коду) та linguist (для визначення мов програмування).[ ^12] Ми класифікуємо кожну окрему мову в одну з трьох різних груп, переходячи від більш ймовірно написаної людиною до більш імовірно написаної машиною (див. таблицю A1). Відро 1 містить мови програмування та мови розмітки (які, швидше за все, написані людиною), сегмент 3 містить дані (швидше за все, написані машиною), а сегмент 2 містить щось середнє, наприклад файли конфігурації та пакетну обробку (що інколи написані людиною, а інколи — машиною, але це важко визначити, лише дивлячись на код).¹² Для нашої первинної оцінки ми використовуємо лише сегмент 1, забезпечуючи перевірку надійності сегментів 2 і 3 у Додаток, і, таким чином, наші результати представляють нижню межу. Нарешті, для деяких аналізів ми копаємо глибше та показуємо 5 найкращих мов програмування (за класифікацією GitHub, 2022 рік за 2020 рік; рік, з якого взято наші дані). До 5 найкращих мов програмування входять C (включаючи C# і C++), Java, JavaScript, Python і Typescript. Ми також додаємо Go до цього списку найпопулярніших мов, оскільки вона стає все більш широко використовуваною мовою в ВВК.

  3. Методика

  Спочатку ми вимірюємо цінність ВВК, розглядаючи пропозицію та попит на ВВК, використовуючи підхід до ринку праці.¹³ Уявний експеримент полягає в тому, що ми живемо у світі, де ВВК не існує, і його потрібно відтворювати на кожній фірмі. який використовує дану частину ВВК. Використовуючи підхід ринку праці, ми розраховуємо вартість заміщення робочої сили кожного пакета ВВК. Щоб оцінити вартість кожного пакету, ми використовуємо COCOMO II (Boehm, 1984; Boehm та ін., 2009) на рівні окремого пакета, а потім підсумовуємо всі значення пакету, щоб отримати вартість заміщення ринку праці з боку пропозиції. Потім ми масштабуємо значення з боку пропозиції на кількість разів, коли фірми використовують кожен пакет, при цьому усуваючи багаторазове використання всередині кожної фірми, щоб отримати значення з боку попиту.

  По-друге, ми виходимо за межі сукупності та перевіряємо нерівність у процесі створення вартості. В ВВК, як і в багатьох творчих починаннях, зазвичай невелика група людей робить основну частину внесків, тоді як багато інших роблять невеликі внески (іноді це називається правилом 80/20, тобто 80% роботи зроблено) на 20% людей). Дослідження показали, що ці постійні учасники часто досягають впливових позицій у спільнотах ВВК завдяки їхнім зусиллям (Hanisch та ін., 2018). Тому, щоб краще зрозуміти дисперсію створення цінності серед розробників, ми спершу використовуємо дані GHTorrent і визначаємо внески окремих розробників двома способами: а) через їхні внески цінності ВВК безпосередньо та б) через загальну кількість сховищ, до яких вони зробили внесок. Потім ми перевіряємо, наскільки сконцентровані ці два показники внеску, щоб краще зрозуміти, багато чи мало розробників роблять внесок у загальну цінність, яку ми вимірюємо. Нижче ми пояснюємо точні деталі підходу до ринку праці та нерівності оцінок.

  3.1 Підхід до ринку праці Для підходу ринку праці ми оцінюємо вартість ВВК шляхом розрахунку відновної вартості пакета. Ми запитуємо, скільки коштуватиме відтворення пакета, найнявши програміста та заплативши йому конкурентоспроможну ринкову зарплату. Щоб оцінити це значення на стороні постачання ($V_{S}^{Labor}$), ми беремо повний список пакетів ВВК, розглянутий вище, а потім підраховуємо рядки коду в кожному унікальному пакеті.¹⁴ Для кожного унікального пакета, i, ми обчислюємо значення, а потім підсумовуємо всі ці значення, щоб отримати загальне значення:

  \[𝑉_{S}^{Labor}=\sum_{i=1}^{N}V_{S_i}=\sum_{i=1}^{N}P_i * 1 (1)\]

  У цьому розрахунку ми неявно не враховуємо жодних виробничих зовнішніх ефектів, оскільки ми припускаємо, що немає переливу знань від одного пакета до іншого, який би знизив вартість програмування.¹⁵ Ця методологія подібна до тієї, що використовується в інших роботах, які оцінити витрати з боку пропозиції ВВК (Blind et al., 2021; Nagle, 2019b; Robbins et al., 2021). Потім ми обчислюємо значення ВВК з боку попиту, додаючи інформацію про використання (Q) для кожного пакета:

  \[𝑉_{D}^{Labor}=\sum_{i=1}^{N}V_{D_i}=\sum_{i=1}^{N}P_i * Q_i (2)\]

  Тут ми не враховуємо зовнішні ефекти споживання, тобто ми не допускаємо отримання вигоди для широкої громадськості, коли пакет було створено, і ми також гарантуємо, що кожна фірма замінює пакет, який вони використовують лише один раз, оскільки замінений пакет може бути використаний у фірмі як клубний товар (наприклад, див. Cornes and Sandler, 1996). Значення $𝑉_{S}^{Labor}$ відображає вартість одноразового перепису всіх широко використовуваних ВВК (наприклад, концепція ВВК все ще існує, але всі ці пакунки потрібно було переписати з нуля), тоді як значення $𝑉_{D}^{Labor}$ відображає вартість кожної фірми, яка використовує один із цих пакетів ВВК, щоб заплатити розробнику за переписування цих пакетів (наприклад, сама ВВК більше не існує).

  Як для моделі пропозиції, так і для моделі попиту ми отримуємо доларову вартість для кожного пакета ($P_i$) за допомогою Constructive Cost Model II, також скорочено COCOMO II (Boehm 1984, Boehm et al. 2009). Ця модель раніше використовувалася Міністерством оборони Сполучених Штатів для оцінки вартості програмного проекту, а також у попередніх дослідженнях оцінки вартості ВВК (Blind et al., 2021; Nagle, 2019b; Robbins et al., 2021). Це дуже гнучка модель, яка дозволяє нам створювати нелінійні перетворення рядків коду в доларові значення. Він використовує наступне рівняння моделювання:

  \[E_i=\alpha\eta L_i^{\beta} (3)\]

  де 𝐿 представляє рядки кодів у тисячах, а E – зусилля в одиницях людино-місяць для кожного проекту i. Відповідно до Blind et al. (2021), ми використовуємо значення параметрів за замовчуванням для 𝛼, 𝛽 та 𝜂. Параметри 𝛼, 𝛽 є нелінійними коригуючими коефіцієнтами, встановленими на 2,94 і 1,0997 відповідно. Параметр 𝜂 — це коефіцієнт коригування зусиль, який можна змінити, щоб включити суб’єктивні оцінки атрибутів продукту, обладнання, персоналу та проекту. Оскільки ми не маємо попереднього значення для кожного проекту, ми встановлюємо 𝜂 значення за замовчуванням одиниці. Щоб отримати ціну (𝑃() кожного проекту ВВК, ми потім помножимо результати рівняння (3) на зважену глобальну заробітну плату, яку отримав би середній програміст на відкритому ринку. Щоб обчислити глобальну заробітну плату, ми включаємо місячну базову суму зарплати розробників програмного забезпечення від Salary Expert для 30 найкращих країн за кількістю розробників GitHub у 2021 році (Wachs та ін., 2022).¹⁶ Вага кожної країни — це частка активних учасників GitHub у загальній кількості учасників. у 30 найкращих країнах ми також створюємо межі, використовуючи ринок праці з низькою (Індія) і високою (США), щоб краще зрозуміти, як вартість буде змінюватися залежно від групи програмістів, які використовуються для відтворення всіх ВВК. .¹⁷

  3.2 Вимірювання внеску Щоб краще зрозуміти, як створюється цінність і однаково чи нерівномірно вона створюється, ми створюємо графічне зображення в три кроки. На першому кроці ми вимірюємо цінний внесок розробників. На другому кроці ми отримуємо показник кількості репозиторіїв, до яких вносяться розробники. Нарешті, ми надаємо графічне представлення обох, використовуючи загальновідому концепцію кривої Лоренца, щоб краще зрозуміти ступінь нерівності у внесках. Ми описуємо деталі нижче.

  Внесок вартості. Ми розрахували значення попиту та пропозиції ВВК, які вніс кожен розробник. На рівні сховища ми кількісно оцінили пропорційний внесок кожного розробника в роботу, підрахувавши їхню частку комітів до загальної кількості комітів для репозиторію. Згодом ця частка була помножена окремо на величину попиту та пропозиції сховища, щоб отримати доданий внесок цього окремого учасника в сховище. Нарешті, ми об’єднуємо цінні внески в усіх сховищах для кожного розробника. Індивідуальний цінний внесок унікального розробника Dev, $V_j^{Dev}$, можна виразити так:

  \[V_j^{Dev}=\sum_{j}^{N}\sigma_i^{Dev}*V_{ij} (7)\]

  де $\sigma_i^{Dev}$ — це частка комітів, зроблених головним розробником у сховищі i, а $V_{ij}$ — це значення попиту чи пропозиції для всього сховища i, указане в рівняннях (1) і (2), де 𝑗∈{𝐷,𝑆}, а N — це кількість сховищ у нашій основній вибірці, тобто Census і BuiltWith разом.

  Внесок у репозіторій. Це просто кількість сховищ, до яких вносить певний розробник, і вона виражається таким чином:

  \[N^{Dev}=\sum_{j}^{N}𝟙\{\sigma_i^{Dev} > 0\} (8)\]

  де 𝟙 — функція індикатора, що дорівнює 1, коли розробник має ненульову кількість комітів до репозиторію i. Цей захід передбачає різноманітні потреби ВВК, які вирішуються окремими розробниками. Разом із мірою внеску цінності вони допомагають нам зрозуміти, чи зосереджена загальна цінність у невеликій кількості розробників. Загалом для всієї екосистеми ВВК та її різноманітності може бути більш бажаним, якщо окремі розробники беруть участь у багатьох сховищах, а не лише в кількох.

  Вимірювання дисперсії внесків. Щоб графічно дослідити дисперсію значень внесків розробників, ми використали криві Лоренца (Лоренц, 1905) щодо значень як попиту, так і пропозиції. Криві Лоренца є усталеним способом представлення нерівності, і, таким чином, вони дозволяють нам краще зрозуміти, наскільки розпорошені внески розробників у ВВК у приватній економіці. Розробники систематично розташовані в порядку зростання на основі їхнього внеску в попит і пропозицію ВВК, як показано в рівнянні (7). Згодом ці ранги були нормалізовані до шкали від 0 до 100 процентилів, що слугує значенням осі абсцис для кривих Лоренца. З іншого боку, вісь ординат представляє відповідні внески вартості $\sigma_i^{Dev}$. Графічне представлення в розділі результатів прояснить ступінь нерівності, що стосується внесків вартості між розробниками. Щоб доповнити аналіз, ми додатково дослідили, наскільки розпорошений внесок сховища, $N^{Dev}$, побудувавши рівняння (8). Це дає нам змогу з’ясувати, чи є будь-яка істотна нерівність цінностей пов’язана з тим, що провідні учасники переважно зосереджуються на вузькій підмножині виключно популярних сховищ, чи, навпаки, з їхньої взаємодії з більш широким спектром успішних сховищ.

  4. Результати

  Після застосування підходу ринку праці з використанням COCOMO II ми отримуємо глобальні оцінки вартості ВВК. Щоб обчислити загальну цінність, нам спочатку потрібна базова кількість рядків коду (щоб обчислити значення з боку пропозиції), а потім статистика використання (для значення з боку попиту). Оскільки мовами програмування можуть бути суттєві неоднорідні значення, ми також показуємо найпопулярніші мови програмування протягом нашого досліджуваного періоду в 2020 році, як обговорювалося вище.

  — Таблиця 1 приблизно тут —

  Таблиця 1 показує описову статистику з обох наборів даних окремо. Внутрішній перепис (панель A) містить трохи більше 261,7 мільйона рядків коду, причому 72 % рядків припадають на найпопулярніші мови програмування. Середній пакет включає 142 тисячі рядків коду з дещо нижчим середнім показником 113 тисяч рядків коду для підмножини найкращих мов. Розглядаючи сторону попиту (використання), ми помічаємо, що пакети Census використовувалися понад 2,7 мільйона разів, при цьому 92 % цього використання припадає на найпопулярніші мови. Середній пакет використовувався 1472,4 рази з вищим використанням приблизно 1497,5 для найпопулярніших мов. Для зовнішніх даних BuiltWith ми знаходимо схожі шаблони, але на різних рівнях. Пакети, включені в BuiltWith, містять понад 82 мільйони рядків коду, 71% з яких відноситься до найкращих мов програмування. Середній пакет у зразку BuiltWith містить 111 тисяч рядків коду з нижчим середнім показником приблизно 80 тисяч рядків коду для найпопулярніших мов. Це пояснюється тим, що наші дані BuiltWith переважно складаються з пакетів на основі JavaScript, які часто менші за пакети, написані іншими мовами. Пакети BuiltWith використовувалися понад 142 тисячі разів, причому 99,97% припадає на найкращі мови. Далі ми використали ці необроблені спостереження, щоб обчислити вартість усіх ВВК за допомогою підходу ринку праці та оцінили вартість, створену з боку пропозиції та попиту.

  — Таблиця 2 приблизно тут —

  У таблиці 2 наведено оцінки вартості ВВК на основі спільної вибірки Census і BuiltWith, що стосується фірми. Усі оцінки в таблиці 2 базуються лише на мовах програмного забезпечення, класифікованих у сегменті 1 таблиці A1, які, швидше за все, будуть написані людиною, а не машиною.¹⁸ Перший стовпець містить оцінки із заробітною платою з низького доходу. країна (Індія), середня заробітна плата в світі та країна з високим доходом (Сполучені Штати Америки), відповідно (як описано вище). Щоб одноразово відтворити всі широко використовувані ВВК (наприклад, ідея ВВК все ще існує, але всі поточні ВВК видалені та потребують кодування з нуля), використовуючи програмістів із середньою заробітною платою розробника з Індії, знадобляться інвестиції $1,22 мільярда. Навпаки, якщо ми використовуємо середню зарплату розробника зі Сполучених Штатів, то відтворення всіх широко використовуваних ВВК потребуватиме інвестицій у розмірі 6,22 мільярда доларів. Використання пулу програмістів з усього світу, зважених на основі існуючих географічних внесків у ВВК, як обговорювалося вище, призвело б до інвестицій десь між країнами з низьким і високим рівнем доходу, $4,15 млрд. Корисно порівняти ці цифри з показниками подібних досліджень, щоб зрозуміти різницю в оцінці всіх ВВК (попередніх досліджень) і тих, які широко використовуються (наше дослідження). Роббінс та ін. (2021) і Блінд та ін. (2021) використали метод, схожий на наш, і оцінили, що вартість ВВК, створеного в США, становить 38 мільярдів доларів у 2019 році, а в ЄС – 1 мільярд євро у 2018 році. Wachs et al. (2022) показують, що приблизно 50% внесків ВВК надходять із США та ЄС разом. У сукупності це призведе до того, що ці дослідження дадуть глобальну вартість ВВК у 78 мільярдів доларів. Таким чином, наша середня оцінка вартості з боку пропозиції в 4,15 мільярда доларів лише для орієнтованих на фірму та широко використовуваних ВВК є надійною нижньою межею та підкреслює вищі оцінки загальної вартості з боку пропозиції ВВК, якщо не враховувати, чи чи не даний пакет ВВК широко використовується. Це додатково вказує на те, що значення з боку пропозиції найбільш широко використовуваних ВВК становить приблизно 5,5% від значення з боку пропозиції всіх ВВК.

  Другий стовпець таблиці 2 містить оцінки попиту на основі підходу ринку праці. Ми виявили, що якби компаніям довелося відтворити всі пакети ВВК, які вони використовували (наприклад, самого ВВК більше не існувало, і кожна фірма, яка використовувала пакет ВВК, мала б його відтворити), тоді загальні витрати становитимуть від $2,59 трлн до $13,18 трлн використання робочої сили лише з країни з низькою чи високою зарплатою відповідно. Група програмістів по всьому світу може відтворити всі ВВК, які широко використовуються, вартістю приблизно 8,80 трильйонів доларів. Інтерпретація цього числа трохи складніша, але все ж можлива. Згідно зі звітом Statista (2023), глобальний дохід від програмного забезпечення у 2020 році (тому ж році, що й наші дані) становив 531,7 мільярда доларів. Однак це потік, а не запас програмного забезпечення. Покладаючись на державні оцінки, згідно з якими програмне забезпечення повністю знецінюється протягом трьох років, ми можемо зробити зворотний розрахунок конверта та розглянути купівельну вартість повного запасу готового програмного забезпечення, використаного у 2020 році, як сукупність того, що було продано з 2018 по 2020 рік, що становить \ 1,54 трильйона доларів. Крім того, це лише витрати на готове програмне забезпечення та не включає програмне забезпечення, придбане на замовлення або розроблене власними силами. Тут найкращі оцінки інвестицій приватного сектору в програмне забезпечення в цілому походять із даних звіту про національний дохід і продукт США (NIPA 2023). У 2020 році дані національних рахунків показують, що в США приватні компанії витратили 479,2 мільярда доларів на програмне забезпечення, з яких 45% (215,5 мільярда доларів) було розфасовано. Якщо ми припустимо, що це постійне співвідношення для решти світу, то загальна сума, яку фірми витратили на програмне забезпечення, яке використовувалося в 2020 році, становила 3,4 трильйона доларів (= 1,54 трильйона доларів/0,45). Поєднуючи цю приблизну оцінку з оцінкою вартості ВВК з боку попиту на основі середньої глобальної заробітної плати ($8,8 трлн), це означає, що фірми витратили б $12,2 трлн (=$3,4 трлн + $8,8 трлн), або в три з половиною рази скільки вони зараз витрачають, якби їм потрібно було заплатити власним розробникам за написання ВВК, яким вони зараз користуються безкоштовно.

  — Малюнок 1 приблизно тут —

  На малюнку 1 показано неоднорідність значення ВВК для найпопулярніших мов програмування. На панелі A показано значення сторони постачання, а вартість праці відображається на вертикальній осі. Ми виявили, що пакети ВВК, створені в Go, мають найвищу цінність із вартістю 80 3 мільйони доларів, яку довелося б створювати з нуля, якби пакети ВВК не існували. Відразу за Go йдуть JavaScript і Java з $758 і $658 млн відповідно. Вартість C і Typescript становить 406 мільйонів доларів США та 317 мільйонів доларів відповідно, тоді як Python має найнижчу вартість серед найпопулярніших мов – близько 55 мільйонів доларів. JavaScript є не лише найпопулярнішою мовою на GitHub принаймні з 2014 року (GitHub, 2022), це також мова з одним із найвищих значень у наших даних. Навпаки, Python з часом ставав все більш популярним, піднявшись із четвертого місця на друге місце у 2020 році серед усіх пакетів ВВК на GitHub, тоді як він займає останнє місце серед наших найкращих мов.

  Панель B показує значення з боку попиту для найпопулярніших мов програмування. Виходячи з цінності використання, Go більш ніж у чотири рази перевищує цінність наступної мови, JavaScript. Typescript (мова, яка розширює JavaScript) значно зросла, піднявшись з десятого місця в топ-10 мов у 2017 році до четвертого місця в 2020 році, що також відображено в наших даних: Typescript є третьою за значенням мовою з боку попиту. За цими двома веб-мовами йдуть C, а Java та Python – далеко позаду.

  — Малюнок 2 приблизно тут —

  На малюнку 2 розділені оцінки значення ВВК для кожної мови за нашими внутрішніми (Census) і зовнішніми (BuiltWith) джерелами даних. Панелі A та B зосереджені на оцінці попиту та пропозиції для перепису. Ми отримуємо подібну модель, яка вже була встановлена ​​в сукупності під час об’єднання обох джерел даних (рис. 1), хоча вплив JavaScript є значно меншим. На стороні пропозиції Перепису в панелі А Java має друге за величиною значення, тоді як код JavaScript з Перепису сприяє значно нижчому значенню в сукупності. Подібним чином значення C, Python і Typescript на стороні пропозиції в основному визначаються переписом. З боку панелі B з боку попиту ми виявили, що Go є найпопулярнішою мовою для внутрішнього коду, тоді як усі інші мови здаються незначними у відносному вираженні.

  На рисунку 2, панель C і панель D показано значення попиту та пропозиції для набору даних BuiltWith. Значення сторони постачання на панелі C чітко вказує на те, що значення із зразка BuiltWith керується кодом JavaScript, що є хорошою перевіркою розумності, оскільки ми зосередилися на пакетах JavaScript для проксі для ВВК у зразку BuiltWith, як обговорювалося вище. Друге найвище значення створює TypeScript, що заспокоює, оскільки це надмножина JavaScript. Панель D демонструє подібну модель використання, де більша частина цінності виникає з JavaScript, тоді як TypeScript також відстає на другому місці. Інші мови вносять лише мізерні суми у значення попиту та пропозиції. Загалом ці висновки загалом узгоджуються з основними випадками використання різних мов (веб-програмування проти програмування додатків) та ідеєю, що мови, за допомогою яких генеруються цінності, не обов’язково ідентичні мовам, якими користується широка громадськість.

  — Малюнок 3 приблизно тут —

  На малюнку 3 показано значення попиту ВВК у галузях за 2-значними кодами NAICS з використанням онлайн-даних BuiltWith.¹⁹ Це можна інтерпретувати як значення, яке отримує кожна з цих галузей через існування ВВК. Галузь із найвищою вартістю використання — близько 43 мільярдів доларів — це «Професійні, наукові та технічні послуги». «Роздрібна торгівля», а також «Адміністративні та допоміжні послуги та послуги з управління відходами та відновлення» складають ще одну значну частину зовнішньої вартості ВВК з боку попиту з 36 і 35 мільярдами доларів США відповідно. Навпаки, галузі, які становлять лише невелику частину вартості, це «Гірнича промисловість, розробка кар’єрів, видобуток нафти та газу», «Комунальні послуги», «Сільське господарство, лісове господарство, рибальство та мисливство». Останні галузі є класичними галузями, не пов’язаними з обслуговуванням, і тому очікується, що програмне забезпечення відіграватиме там меншу роль.

  — Малюнок 4 приблизно тут —

  На малюнку 3 показано криві Лоренца та кількість сховищ, до яких долучилася частка програмістів для сторони пропозиції (панель A) і сторони попиту (панель B). Крива Лоренца, яка лежить прямо на лінії 45 градусів, означатиме дуже рівномірний розподіл значень між програмістами. Натомість панель A показує криву Лоренца як майже рівну лінію з різким збільшенням кінцевої частки програмістів. Це означає, що розподіл вартості пропозиції є дуже нерівномірним і значно більш концентрованим, ніж стандарт 80/20. Дійсно, останні п’ять відсотків програмістів, або 3000 програмістів, генерують понад 93% вартості з боку пропозиції. Подібним чином панель B показує – якщо врахувати використання – що останні п’ять відсотків створюють понад 96% вартості на стороні попиту. Загалом це вказує на те, що дуже невелика кількість програмістів створює основну частину коду ВВК, на який фірми сильно покладаються при створенні власного коду. Як на панелі A, так і на панелі B ми також бачимо збільшення кількості сховищ для останніх 10-15% програмістів, які роблять внесок у найвищу цінність, що означає, що нерівномірне значення, яке генерується декількома програмістами, є не просто до кількох дуже цінних сховищ, але завдяки внеску цієї жменьки учасників до значної кількості сховищ.

  5. Висновок

  У цьому дослідженні ми оцінюємо цінність широко використовуваного програмного забезпечення з відкритим кодом у всьому світі за допомогою двох унікальних наборів даних: даних Census of ВВК і даних BuiltWith. Ми можемо оцінити не лише цінність наявного коду з боку пропозиції (наприклад, вартість, яку знадобиться для переписування кожного фрагмента широко використовуваного ВВК), але й цінність з боку попиту для приватної економіки (наприклад, вартість взяти для кожної компанії, яка використовує частину ВВК, щоб переписати її). Хоча ми не зосереджуємося на довгому хвості ВВК, ми вважаємо це додатковим внеском нашого дослідження, оскільки зосередження на ВВК, яке широко використовується, дозволяє точніше зрозуміти цінність, яку створює ВВК, а не лише вимірювати вартість заміни для всіх ВВК (що переоцінило б справжнє значення, оскільки багато проектів ВВК не використовуються у робочому коді). Однак, незважаючи на те, що ми підкреслюємо значну цінність ВВК для нашого суспільства на основі широкого спектру даних про використання, неможливо ідентифікувати 100% ВВК, що використовується в усьому світі, тому наші оцінки з боку попиту, ймовірно, недооцінка справжньої вартості.

  З поправкою на використання, ми знаходимо велике значення ВВК на стороні попиту в 8,8 трильйона доларів США, коли використовуємо програмістів з усього світу, з деякими відхиленнями, залежно від того, чи будемо ми наймати програмістів лише з країни з низьким чи високим рівнем доходу. Існує суттєва неоднорідність значення в мовах програмування та щодо того, чи є код внутрішнім – тобто для створення продуктів, які продаються – чи зовнішнім – тобто використовується на веб-сайті компанії. 6 найпопулярніших мов програмування створюють 84 % цінності з боку попиту. Ми також демонструємо значну неоднорідність за галузями промисловості та, нарешті, неоднорідність ціннісних внесків самих програмістів. Понад 95% вартості на стороні попиту генерується лише п’ятьма відсотками програмістів, і ці програмісти беруть участь не лише в кількох широко використовуваних проектах, а й у значно більшій кількості проектів, ніж програмісти, які працюють у нижньому кінці розподілу вартості. .

  У сукупності наші результати показують значну цінність, яку ВВК робить для економіки, незважаючи на те, що це значення зазвичай дорівнює нулю шляхом прямого вимірювання, оскільки ціни дорівнюють нулю, а кількість важко виміряти, використовуючи лише публічні дані. Наше дослідження закладає основу для майбутніх досліджень не лише ВВК, але й усіх ІТ та їх зростаючого впливу на світову економіку.

  Посилання

  • Almeida, D. A., Murphy, G. C., Wilson, G., & Hoye, M. (2017, May). Do software developers understand open source licenses? In 2017 IEEE/ACM 25th International Conference on Program Comprehension (ICPC) (pp. 1-11). IEEE.
  • Andreessen, M. (2011). Why Software Is Eating The World. Accessed May 1, 2023. Source: https://www.wsj.com/articles/SB10001424053111903480904576512250915629460
  • Aristotle. (1981). Politics_._ Book 2, Chapter 3. T.A. Sinclair translation. Penguin Books, London.
  • Blind, K., Böhm, M., Grzegorzewska, P., Katz, A., Muto, S., Pätsch, S., & Schubert, T. (2021). The impact of Open Source Software and Hardware on technological independence, competitiveness and innovation in the EU economy. European Commission, Ed.
  • Blind, K., & Schubert, T. (2023). Estimating the GDP effect of Open Source Software and its complementarities with R&D and patents: evidence and policy implications. The Journal of Technology Transfer, 1-26.
  • Boehm, B. W. (1984). Software engineering economics. IEEE transactions on Software Engineering, (1), 4-21.
  • Boehm, B. W., Abts, C., Brown, A. W., Chulani, S., Clark, B. K., Horowitz, E., Madachy, R., Reifer, D., & Steece, B. (2009). Software cost estimation with COCOMO II. Prentice Hall Press.
  • Branstetter, Lee G., Matej Drev, and Namho Kwon. (2019). “Get with the program: Software-driven innovation in traditional manufacturing.” Management Science 65, no. 2: 541-558.
  • Brynjolfsson, E. (1993). The productivity paradox of information technology. Communications of the ACM, 36(12), 66-77.
  • Brynjolfsson, E., & Hitt, L. (1996). Paradox lost? Firm-level evidence on the returns to information systems spending. Management Science, 42(4), 541-558.
  • Brynjolfsson, E., Rock, D., & Syverson, C. (2018). Artificial intelligence and the modern productivity paradox: A clash of expectations and statistics. In The economics of artificial intelligence: An agenda (pp. 23-57). University of Chicago Press.
  • Burton, R. M., Håkonsson, D. D., Nickerson, J., Puranam, P., Workiewicz, M., & Zenger, T. (2017). GitHub: exploring the space between boss-less and hierarchical forms of organizing. Journal of Organization Design , 6 , 1-19.
  • Conti, A., Peukert, C., & Roche, M. (2023). “Beefing IT up for your Investor? Open Sourcing and Startup Funding: Evidence from GitHub.” Harvard Business School Working paper No. 22- 001.
  • Cornes, R., & Sandler, T. (1996). The theory of externalities, public goods, and club goods. Cambridge University Press.
  • DeStefano, T., and J. Timmis (2023). Demand Shocks and Data Analytics Diffusion, working paper.
  • Dushnitsky, G., & Stroube, B. K. (2021). Low-code entrepreneurship: Shopify and the alternative path to growth. Journal of Business Venturing Insights, 16, e00251.
  • Eisfeldt, A. L., & Papanikolaou, D. (2014). The value and ownership of intangible capital. American Economic Review, 104(5), 189-194.
  • European Commission. (2020). Open Source Software Strategy 2020-2023. Luxembourg: Office for Official Publications of the European Communities.
  • Executive Order No. 14028. (2021). Executive Order on Improving the Nation’s Cybersecurity. May 2021.
  • Fackler, T., Hofmann, M., & Laurentsyeva, N. (2023). Defying Gravity: What Drives Productivity in Remote Teams? (No. 427). CRC TRR 190 Rationality and Competition.
  • Greenstein, S., & Nagle, F. (2014). Digital dark matter and the economic contribution of Apache. Research Policy , 43 (4), 623-631.
  • GitHub (2022). “Octoverse: The state of open source software.” Accessed November 3, 2023. https://octoverse.github.com/2022/top-programming-languages.
  • Hanisch, M., Haeussler, C., Berreiter, S., & Apel, S. (2018, July). Developers’ progression from periphery to core in the Linux kernel development project. In Academy of Management Proceedings (Vol. 2018, No. 1, p. 14263). Briarcliff Manor, NY 10510: Academy of Management.
  • Hardin, G. (1968). “The Tragedy of the Commons”. Science. 162 (3859): 1243–1248.
  • Henkel, J. (2009). Champions of revealing—the role of open source developers in commercial firms. Industrial and Corporate Change, 18(3), 435-471.
  • Jacks, J. (2022). Open Source Is Eating Software FASTER than Software Is Eating The World. Accessed May 1, 2023. Source: https://www.coss.community/cossc/open-source-is-eating-software-faster-than-software-is-eating-the-world-3b01
  • Kim, D. Y. (2020). Product Market Performance and Openness: The Moderating Role of Customer Heterogeneity. In Academy of Management Proceedings (Vol. 2020, No. 1, p.21309). Briarcliff Manor, NY 10510: Academy of Management.
  • Koning, R., Hasan, S., & Chatterji, A. (2022). Experimentation and start-up performance: Evidence from A/B testing. Management Science, 68(9), 6434-6453.
  • Krishnan, M. S., Kriebel, C. H., Kekre, S., & Mukhopadhyay, T. (2000). An empirical analysis of productivity and quality in software products. Management science, 46(6), 745-759.
  • Lerner, J., & Tirole, J. (2005). The scope of open source licensing. Journal of Law, Economics, and Organization, 21(1), 20-56.
  • Lorenz, M. O. (1905). “Methods of measuring the concentration of wealth”. Publications of the American Statistical Association. Publications of the American Statistical Association , Vol. 9, No. 70. 9 (70): 209–219. Bibcode:1905PAmSA…9..209L. doi:10.2307/2276207. JSTOR 2276207.
  • Lifshitz-Assaf, H., & Nagle, F. (2021). The digital economy runs on open source. Here’s how to protect it. Harvard Business Review Digital Articles. https://hbr.org/2021/09/the-digital-economy-runs-on-open-source-heres-how-to-protect-it.
  • Lloyd, W. F. (1833). Two lectures on the checks to population: Delivered before the University of Oxford, in Michaelmas Term 1832. JH Parker.
  • Maracke, C. (2019). Free and Open Source Software and FRAND‐based patent licenses: How to mediate between Standard Essential Patent and Free and Open Source Software. The Journal of World Intellectual Property, 22(3-4), 78-102.
  • Murciano-Goroff, R., Zhuo, R., & Greenstein, S. (2021). Hidden software and veiled value creation: Illustrations from server software usage. Research Policy , 50 (9), 104333.
  • Musseau, J., Meyers, J. S., Sieniawski, G. P., Thompson, C. A., & German, D. (2022, May). Is open source eating the world’s software? Measuring the proportion of open source in proprietary software using Java binaries. In Proceedings of the 19th International Conference on Mining Software Repositories (pp. 561-565).
  • Nagle, F. (2018). Learning by contributing: Gaining competitive advantage through contribution to crowdsourced public goods. Organization Science, 29(4), 569-587.
  • Nagle, F. (2019a). Open source software and firm productivity. Management Science, 65(3), 1191-1215.
  • Nagle, Frank (2019b). “Government Technology Policy, Social Value, and National Competitiveness.” Harvard Business School Working Paper, No. 19-103, March 2019.
  • Nagle, F., Dana, J., Hoffman, J., Randazzo, S., & Zhou, Y. (2022). Census II of Free and Open Source Software—Application Libraries. _Linux Foundation, Harvard Laboratory for Innovation Science (LISH) and Open Source Security Foundation (OpenSSF). https://www.linuxfoundation.org/research/census-ii-of-free-and-open-source-software-application-libraries.
  • NIPA (2023). Bureau of Eonomic Analysis, NIPA Table 5.6.5. accessed: 2023- 11 - 14, source:https://apps.bea.gov/iTable/?reqid=19&step=3&isuri=1&select_all_years=0&nipa_table_list=331&series=q&first_year=2013&last_year=2023&scale=-9.
  • Nordhaus, William D., 2006, “Principles of National Accounting for Nonmarket Accounts,” in _A
  • New Architecture for the US National Accounts_ , editors, Dale W. Jorgenson, J. Steven Landefeld, and William D. Nordhaus, University of Chicago Press.
  • Ostrom, Elinor (1990). Governing the commons: The evolution of institutions for collective action. Cambridge: Cambridge University Press.
  • Peters, R. H., & Taylor, L. A. (2017). Intangible capital and the investment-q relation. Journal of Financial Economics, 123(2), 251-272.
  • Robbins, C., Korkmaz, G., Guci, L., Calderón, J. B. S., & Kramer, B. (2021). A First Look at Open-Source Software Investment in the United States and in Other Countries, 2009-2019.
  • Singh, Shivendu Pratap (2020) Products, Platforms, and Open Innovation: Three Essays on Technology Innovation. Doctoral Dissertation, University of Pittsburgh. (Unpublished)
  • Solow, R. (1987). “We Better Watch Out.” New York Times Book Review , July 1987, p. 36.
  • Statista (2023). Statista Software Worldwide, accessed 2023- 11 - 14, source: - https://www.statista.com/outlook/tmo/software/worldwide#revenue, accessed November 2023.
  • Synopsys (2023). 2023 OSSRA: A deep dive into open source trends. Accessed May 1, 2023. Source : https://www.synopsys.com/blogs/software-security/open-source-trends-ossra-report/
  • Tang, S., Wang, Z., & Tong, T. (2023). Knowledge Governance in Open Source Contributions: The Role of Gatekeepers. In Academy of Management Proceedings (Vol. 2023, No. 1, p.17622). Briarcliff Manor, NY 10510: Academy of Management.
  • Tozzi, C. (2016). “Open Source History: Why Did Linux Succeed?” Channel Futures , August, 2016. Accessed November 3, 2023. https://www.channelfutures.com/open-source/open-source-history-why-did-linux-succeed
  • Wachs, J., Nitecki, M., Schueller, W., & Polleres, A. (2022). The geography of open source software: Evidence from github. Technological Forecasting and Social Change , 176 , 121478.
  • Williamson, S. (2006). Notes on macroeconomic theory. University in St. Louis. Department of Economics.
  • Zhang, Y., Zhou, M., Mockus, A., & Jin, Z. (2019). Companies’ participation in oss development–an empirical study of openstack. IEEE Transactions on Software Engineering, 47(10), 2242 - 2259.

  Малюнок 1 Цінність програмного забезпечення з відкритим кодом: найпопулярніші мови

  Панель A. Сторона постачання

  

  Панель B. Сторона попиту

  

  Примітка. Цифри показують вартість ринку праці для 5 найкращих мов за GitHub plus Go. На панелі A відображається сторона постачання, а на панелі B – використання. Що стосується праці, ми використовуємо нашу розрахункову середню глобальну заробітну плату для програмістів, як пояснюється в розділі методології.

  Малюнок 2 Значення відкритого коду для 5 найкращих мов + Go та джерел даних

  Панель А. Перепис. Сторона постачання

  

  Панель Б. Перепис. Сторона попиту

  

  Панель C. BuiltWith. Сторона постачання

  

  Панель D. BuiltWith. Сторона попиту

  

  Примітка. Цифри показують ринкову вартість робочої сили та товарів для 5 найпопулярніших мов (згідно з GitHub) + Go, розділених за джерелами даних, спрямованими всередину (Census) і зовнішніми (BuiltWith). Панелі A та B показують значення з боку пропозиції та попиту для перепису, а панелі C та D — значення з боку пропозиції та попиту для BuiltWith.

  Малюнок 3 Значення відкритого коду в різних галузях із веб-сайтів

  

  Примітка. На малюнку показано вартість праці з боку попиту в галузях із 2-значним кодом NAICS із використанням даних Built With. Для компаній (доменів), які пов’язані з кількома галузями, ми взяли середнє значення та розподілили його між галузями.

  Малюнок 4 Розподіл створення цінності з відкритим кодом

  Панель A. Сторона постачання

  

  Панель B. Сторона попиту

  

  Примітка. Цифри показують криву Лоренца внеску вартості ринку праці на одного розробника (синім кольором), а також кількість сховищ, у які внесла частка програмістів (жовтим кольором). На панелі A відображається сторона постачання, а на панелі B – використання.

  Таблиця 1 Описова статистика рядків коду та використання

  	Sum	Mean	SD	Obs
  Панель А: Перепис
  Рядки коду – усі пакети	261,653,728	142,203.1	887,937.2	1,840
  Рядки коду – 5 найкращих мов і Go	189,673,184	113,712.9	702,832.1	1,668
  Використання – Усі пакети	2,709,155	1472.4	2,167.9	1,840
  Використання – 5 найкращих мов і Go	2,497,785	1497.5	2,228.8	1,668
  Панель B: BuiltWith
  Рядки коду – усі пакети	82,504,613	111,342.3	613,488.1	741
  Рядки коду – 5 найкращих мов і Go	58,664,935	79,925.0	354,415.0	734
  Використання – Усі пакети	142,794.4	192.7	733.4	741
  Використання – 5 найкращих мов і Go	142,751.2	194.5	736.6	734

  Примітка. Статистика базується на рядках кодів різних репозиторіїв. Панель A (B) відображає загальну суму, середнє значення, стандартне відхилення та кількість спостережень для даних перепису (BuiltWith) у рядках коду та використання з використанням усіх пакетів із групи 1 (див. таблицю A1).

  Таблиця 2 Вартість відкритого коду на ринку праці

  	Пропозиція робочої сили	Попит на робочу силу
  Заробітна плата: низька	$1.22 Billion	$2.59 Trillion
  Заробітна плата: глобальна	$4.15 Billion	$8.80 Trillion
  Заробітна плата: висока	$6.22 Billion	$13.18 Trillion

  Примітка. Сценарій високої заробітної плати базується на середній заробітній платі в США, а сценарій низької заробітної плати – це середня заробітна плата програмістів в Індії у 2020 році. Загальна заробітна плата – це середня заробітна плата в країнах у таблиці A4, зважена відповідно до їхніх внесків у ВВК. Ці оцінки включають лише мови з програмного забезпечення, класифікованого у сегменті 1 (див. таблицю A1).

  Онлайн-додаток

  Таблиця A1 Мови в кожному сегменті

  Тип	Мова
  Панель A: сегмент 1 – мови
  Мова розмітки	BIBTEX
  Мова розмітки	COLDFUSION HTML
  Мова розмітки	DOCBOOK XML
  Мова розмітки	HAML
  Мова розмітки	HTML
  Мова розмітки	HXML
  Мова розмітки	JAVAEE XML
  Мова розмітки	MARKDOWN
  Мова розмітки	MASON
  Мова розмітки	MXML
  Мова розмітки	RELAX-NG COMPACT
  Мова розмітки	RHTML
  Мова розмітки	TEX
  Мова розмітки	XML
  Мова розмітки	XQUERY
  Мова розмітки	YAML
  Мова програмування	ABNF
  Мова програмування	ACTIONSCRIPT
  Мова програмування	ADA
  Мова програмування	APPLESCRIPT
  Мова програмування	ARDUINO
  Мова програмування	ASPECTJ
  Мова програмування	ASPX-CS
  Мова програмування	ASPX-VB
  Мова програмування	AWK
  Мова програмування	C
  Мова програмування	C#
  Мова програмування	CHARMCI
  Мова програмування	CLOJURE
  Мова програмування	COFFEESCRIPT
  Мова програмування	COMMON LISP
  Мова програмування	CSS
  Мова програмування	CUDA
  Мова програмування	CYTHON
  Мова програмування	D
  Мова програмування	DART
  Мова програмування	DELPHI
  Мова програмування	EASYTRIEVE
  Мова програмування	EC
  Мова програмування	ELIXIR
  Мова програмування	ELM
  Мова програмування	EMACSLISP
  Мова програмування	ERLANG
  Мова програмування	F#
  Мова програмування	FISH
  Мова програмування	FORTH
  Мова програмування	FORTRAN
  Мова програмування	FORTRANFIXED
  Мова програмування	GAP
  Мова програмування	GHERKIN
  Мова програмування	GLSL
  Мова програмування	GO
  Мова програмування	GRAPHVIZ
  Мова програмування	GROOVY
  Мова програмування	HASKELL
  Мова програмування	HAXE
  Мова програмування	IDL
  Мова програмування	JAVA
  Мова програмування	JAVA SERVER PAGE
  Мова програмування	JAVASCRIPT
  Мова програмування	KOTLIN
  Мова програмування	LESSCSS
  Мова програмування	LIQUID
  Мова програмування	LIVESCRIPT
  Мова програмування	LLVM
  Мова програмування	LOGOS
  Мова програмування	LUA
  Мова програмування	MATHEMATICA
  Мова програмування	MINISCRIPT
  Мова програмування	MODULA- 2
  Мова програмування	NASM
  Мова програмування	NIX
  Мова програмування	OBJECTIVE-C
  Мова програмування	OBJECTIVE-J
  Мова програмування	OCAML
  Мова програмування	OPENEDGE ABL
  Мова програмування	PAWN
  Мова програмування	PERL
  Мова програмування	PHP
  Мова програмування	PL/PGSQL
  Мова програмування	POSTSCRIPT
  Мова програмування	POVRAY
  Мова програмування	PROLOG
  Мова програмування	PROPERTIES
  Мова програмування	PUPPET
  Мова програмування	PYTHON
  Мова програмування	REASONML
  Мова програмування	REBOL
  Мова програмування	REDCODE
  Мова програмування	REXX
  Мова програмування	RUBY
  Мова програмування	RUST
  Мова програмування	S
  Мова програмування	SASS
  Мова програмування	SCALA
  Мова програмування	SCILAB
  Мова програмування	SCSS
  Мова програмування	SLIM
  Мова програмування	SMALLTALK
  Мова програмування	SOLIDITY
  Мова програмування	STANDARD ML
  Мова програмування	SWIFT
  Мова програмування	SWIG
  Мова програмування	TADS 3
  Мова програмування	TCL
  Мова програмування	THRIFT
  Мова програмування	TRANSACT-SQL
  Мова програмування	TREETOP
  Мова програмування	TYPESCRIPT
  Мова програмування	VB.NET
  Мова програмування	VBSCRIPT
  Мова програмування	VCL
  Мова програмування	VIML
  Мова програмування	WEB IDL
  Панель B: Відро 2 – Допоміжні мови
  Асемблер/Компілятор/Інтерпретатор/Макропроцесори	GAS
  Асемблер/Компілятор/Інтерпретатор/Макропроцесори	M4
  Асемблер/Компілятор/Інтерпретатор/Макропроцесори	RAGEL IN RUBY HOST
  Конфігурація	CMAKE
  Конфігурація	INI
  Конфігурація	MAKEFILE
  Конфігурація	NGINX Configuration FILE
  Конфігурація	NSIS
  Конфігурація	SQUIDCONF
  Конфігурація	TERRAFORM
  Конфігурація	TOML
  Форматування	GROFF
  IDE	NETBEANS PROJECT
  Механізм шаблонів	CHEETAH
  Механізм шаблонів	GENSHI
  Механізм шаблонів	PUG
  Механізм шаблонів	SMARTY
  Механізм шаблонів	VELOCITY
  Terminal/Batch	ANT
  Terminal/Batch	APACHECONF
  Terminal/Batch	BASH
  Terminal/Batch	BATCHFILE
  Terminal/Batch	MAVEN
  Terminal/Batch	POWERSHELL
  Terminal/Batch	RPMSPEC
  Terminal/Batch	SINGULARITY
  Terminal/Batch	TCSH
  Перекладний	GETTEXT CATALOG
  Панель C: сегмент 3 – дані
  Дані	BNF
  Дані	DIFF
  Дані	DTD
  Дані	E-MAIL
  Дані	JSON
  Дані	PROTOCOL BUFFER
  Дані	RESTRUCTUREDTEXT
  Дані	TEXT ONLY
  Дані	XSLT

  Таблиця A2 Включено 30 найкращих країн із глобальною заробітною платою

  Країна
  United States
  China
  Germany
  India
  United Kingdom
  Brazil
  Russia
  France
  Canada
  Japan
  South Korea
  Netherlands
  Spain
  Poland
  Australia
  Sweden
  Ukraine
  Italy
  Switzerland
  Indonesia
  Taiwan
  Colombia
  Argentina
  Mexico
  Norway
  Belgium
  Denmark
  Finland
  Vietnam
  Austria

  Примітка. 30 найкращих країн відсортовані в порядку зростання за часткою користувачів GitHub, і вони включають 88% активності GitHub з 2020 року.

  Таблиця A3 Цінність ринку праці з відкритим кодом із використанням мов у сегментах 1 і 2

  	Пропозиція робочої сили	Попит на робочу силу
  Заробітна плата: низька	$1.23 Billion	$2.60 Trillion
  Заробітна плата: глобальна	$4.18 Billion	$8.84 Trillion
  Заробітна плата: висока	$6.26 Billion	$13.24 Trillion

  Примітка. Сценарій високої заробітної плати базується на середній заробітній платі в США, а сценарій низької заробітної плати – це середня заробітна плата програмістів в Індії у 2020 році. Загальна заробітна плата – це середня заробітна плата в країнах, указаних у таблиці A 4. Оцінки включають лише мови з груп 1 і 2 (див. таблицю A1).

  Таблиця A4 Вартість ринку праці з відкритим вихідним кодом із використанням мов у сегментах 1, 2 і 3

  	Пропозиція робочої сили	Попит на робочу силу
  Заробітна плата: низька	$1.88 Billion	$3.52 Trillion
  Заробітна плата: глобальна	$6.41 Billion	$11.96 Trillion
  Заробітна плата: висока	$9.59 Billion	$17.91 Trillion

  Примітка. Сценарій високої заробітної плати базується на середній заробітній платі в США, а сценарій низької заробітної плати – це середня заробітна плата в Індії для програмістів у 2020 році. Загальна заробітна плата – це середня заробітна плата в країнах, указаних у таблиці A 4. Оцінки включають лише мови з груп 1, 2 , і 3 (див. таблицю A1).

  Таблиця A 5 Кошик товарів – еквівалентне програмне забезпечення з відкритим кодом і пропрієтарне програмне забезпечення

  Програмне забезпечення з відкритим кодом	Закрите програмне забезпечення
  Apache Http Server	Windows Server 2008
  Audacity	Adobe Audition
  Blender	Autodesk Maya
  Elasticsearch	Amazon Kendra
  FileZilla	SmartFTP
  FreeCAD	AutoCAD
  GIMP	Adobe Photoshop
  GNU Octave	MATLAB
  GnuCash	QuickBooks
  KeePass	1Password
  LibreOffice	Microsoft Office Suite
  MariaDB server	Microsoft SQL Server
  Metabase	Tableau
  MySQL	Oracle MySQL
  OpenVPN	ExpressVPN
  PSPP	SPSS
  Redis	Redis Enterprise
  TensorFlow	TensorFlow Enterprise
  VirtualBox	VMware Workstation
  VLC Media Player	CyberLink PowerDVD

  Таблиця A6 Товарно-ринкова вартість відкритого коду з використанням мов у сегментах 1, 2 і 3

  	Goods-Demand Bucket 1	Goods-Demand Bucket 1-2	Goods Demand, Bucket 1-3
  Заробітна плата: низька	$177 Million	$179 Million	$242 Million
  Заробітна плата: глобальна	$177 Million	$179 Million	$242 Million
  Заробітна плата: висока	$177 Million	$179 Million	$242 Million

  Примітка. Сценарій високої заробітної плати базується на середній заробітній платі в США, а сценарій низької заробітної плати – це середня заробітна плата в Індії для програмістів у 2020 році. Загальна заробітна плата – це середня заробітна плата в країнах, указаних у таблиці A 4. Оцінки включають лише мови з груп 1, 2 , і 3 (див. таблицю A1).

  Додаток A) Підхід до ринкової оцінки товарів

  Як альтернативний метод оцінки замість використання відновної вартості праці ми використовуємо підхід відновної вартості товару. Ми визначаємо кілька пакетів ВВК, які мають подібні грошові альтернативи із закритим вихідним кодом, і розглядаємо витрати, якби всім комерційним користувачам безкоштовного ВВК довелося замінити це програмне забезпечення на грошову альтернативу (подібно до розрахунків Грінстайна та Нейгла (2014) та Мурчіано-Гороффа та ін. (2021) для веб-серверів). Потім ми можемо використати це альтернативне значення p у поєднанні зі значеннями q, наведеними вище, щоб оцінити вартість заміни товару ВВК. Цей метод ґрунтується на пропозиціях Нордгауза (2006, стор. 146), який каже, що «…ціна ринкових і неринкових товарів і послуг повинна розраховуватися на основі порівнянних ринкових товарів і послуг». Ми не очікуємо, що оцінки за двома методами будуть подібними. Навпаки, вартість цих двох методів суттєво різниться, оскільки останній товарно-ринковий підхід припускає фіксовану ціну, щоб продати товар кілька разів, і ця фіксована ціна зазвичай нижча за загальну вартість, оцінену на основі відтворення всіх пакетів з боку праці. Різниця між цими оцінками є, по суті, результатом того, що фірма втручається, щоб відтворити відсутні пакети ВВК і потім продає їх за грошову ціну, а не всім фірмам, які повинні відтворювати ці пакети з нуля самостійно. З підходом до ринку товарів уявний експеримент все ще полягає в тому, що ми живемо у світі, де ВВК не існує, але його потрібно відтворити за допомогою однієї фірми, яка потім стягує ціну за товар, який зараз є безкоштовним. Щоб оцінити ВВК за допомогою підходу ринку товарів, ми створили кошик еквівалентних запатентованих товарів-замінників, які оцінюються на відкритому ринку як заміна продукту ВВК. Ця методологія узгоджується з тією, що використовувалася в попередній літературі (Greenstein and Nagle, 2014; Murciano-Goroff et al., 2021), хоча в обох цих дослідженнях використовувався лише один товар, а не кошик, оскільки вони були зосереджені лише на одному типі ВВК (веб-сервери). Оскільки немає легкодоступної бази даних для власних еквівалентів ВВК, ми проводимо пошук на основі суб’єктивного сприйняття популярності ВВК, а потім шукаємо грошові, закриті замінники для них. Отриманий кошик із 20 пакетів ВВК із запатентованими замінниками є гарним уявленням про різноманітність ВВК. Програмне забезпечення варіюється від засобів масової інформації та програмного забезпечення для дизайну до програм статистичного аналізу, керування базами даних і програмного забезпечення веб-сервера.²⁰

  На основі нашого еквівалентного кошика пропрієтарних товарів-замінників ВВК ми потім отримуємо ціни для кожного еквівалента пропрієтарного програмного забезпечення та розраховуємо вартість пропозиції на ринку праці COCOMO для кожного продукту ВВК у кошику, який ми використовуємо як проксі – через відсутність коду з пропрієтарне програмне забезпечення – для цінності пропрієтарного програмного забезпечення COCOMO з боку пропозиції робочої сили (наприклад, вартість, яка знадобиться, щоб заплатити програмісту за написання цього пропрієтарного програмного забезпечення з нуля). Потім ми обчислюємо середню вартість кошика COCOMO на стороні пропозиції робочої сили $V_{S,Basket}$ і середню ціну кошика $P_{S,Basket}$.²¹ Оскільки , ми знаємо вартість пропозиції на ринку праці для всіх ВВК, $V_{S,Basket}$, ми можемо налаштувати наступне рівняння та отримати ціну ВВК, $P_S$ для ринку товарів для всіх ВВК за допомогою простого перетворення масштабування:

  \[\frac{P_S}{V_{S}^{Labor}}=\frac{P_{S,Basket}}{V_{S,Basket}} P_S=\frac{V_{S}^{Labor}}{V_{S,Basket}}P_{S,Basket} (4)\]

  Це призводить до наступної вартості пропозиції на ринку товарів:

  \[V_{S}^{Goods}=P_S * 1. (5)\]

  Тоді ми можемо отримати еквівалентні ринкові вартості товарів з боку попиту наступним чином:

  \[V_{D}^{Goods} =𝑃_S∗Q. (6)\]

  З боку товарного ринку ми розглядаємо еквівалентну ціну, яку фірма стягувала б, якби виробляла всі наявні широко використовувані ВВК, а потім продавала їх як продукт клієнтам.

  Таблиця A6, стовпець 3, показує, що вартість на стороні попиту коливається від 177 до 244 мільйонів доларів для різних сегментів, незалежно від країни походження, з якої наймають програмістів. Природно, ринкова вартість товару буде значно меншою, ніж вартість попиту на робочу силу, оскільки ця уявна фірма буде отримувати прибуток за порівняно низькою ціною, виробляючи програмне забезпечення один раз, а потім продаючи його багатьом клієнтам. Крім того, у той час як Greenstein and Nagle (2014), а також Murciano-Goroff et al. (2021) зосереджені лише на одному конкретному типі програмного забезпечення (веб-серверах), ми намагаємося розширити їхній підхід до багатьох товарів. Однак обмеження даних стають сильнішими обмеженнями в цьому контексті, що за своєю суттю ускладнює оцінку вартості за допомогою цього підходу, вимагаючи значно більше припущень. Замість чистого підходу ринку товарів, це потребує допомоги підходу ринку праці в плані масштабування для оцінки, що зрештою призводить до суттєвої недооцінки вартості ВВК. Крім того, стратегія ціноутворення аналогів пропрієтарного програмного забезпечення чутлива до ринкового попиту. Оскільки підхід ринку товарів поширюється на кілька товарів, сильним неявним припущенням є те, що ринковий попит на наше програмне забезпечення для кошика та наш зразок ВВК подібні, тому вони призводять до співмірних цін.

  Альтернативний і ще більш спрощений розрахунок на задній частині ринку товарів, який не враховує рядки коду та не покладається на масштабування підходу ринку праці, полягав би просто в множенні ціни еталонного товару на використання. Ми можемо взяти мінімальну, середню та максимальну ціни кошика пропрієтарних товарів, зафіксованих у векторі базових цін p = (69,99, 1610,17, 5800), і просто помножити їх на використання комбінованої вибірки Census і BuiltWith (таблиця 1). . Виходячи з цих умовних припущень про власну ціну, вартість попиту на ринку товарів коливатиметься від 0,2 до 16,5 трильйонів доларів США (мінімальна ціна – максимальна ціна), а середня ціна дасть оцінку вартості в 4,5 трильйона доларів. Однак, незважаючи на те, що ця оцінка створює дещо більше розбіжностей, ніж підхід до ринку праці, вона за своєю суттю є хибною, оскільки просто припускає, що умовні ціни є ідентичними для кожного продукту з відкритим кодом на основі базової ціни. Крім того, ми вважаємо, що цей дуже простий зворотний бік конверта є порівнянням апельсина з яблуками, оскільки товари в нашому кошику є повністю функціональними, автономними пакетами програмного забезпечення, тоді як пакети в наборах даних Census і BuiltWith складаються з бібліотек програм, які зазвичай менші, ніж такі окремі пакети.

  Враховуючи всі складнощі та припущення, які доводиться робити через брак даних для підходу товарного ринку, ми робимо більший акцент на підході вартості робочої сили, виділеному в основній частині, але ми включаємо цей метод тут для повноти.

  1. точні методології збору та агрегування даних детально описано у звіті про перепис населення, автором якого є Нейгл та інші (2022). ↩

  2. Ліцензії на використання ВВК дуже відрізняються, і хоча деякі ліцензії є дуже відкритими та дозволяють використовувати код у будь-який спосіб, зокрема в межах власного коду, який буде доступний для продажу за ненульовою ціною, інші ліцензії обмежити повторне використання, лише якщо отриманий код випущено під тією ж ліцензією ВВК (відома як копілефт). Детальне обговорення ліцензій ВВК можна знайти в Лернера та Тіроля (2005) та Алмейди та інших (2017). ↩

  3. непряме використання ВВК фіксується аналізом залежностей і є необхідним для точного вимірювання повного спектру ВВК, на який покладається фірма. Наприклад, якщо власний код фірми викликає ВВК-пакет A, а пакет A, у свою чергу, викликає пакет B, тоді лише дивлячись на прямі виклики, ви пропустите, що пакет B був необхідним будівельним блоком для власного коду фірми. ↩

  4. Перепис визначає пакет ВВК як «одиницю програмного забезпечення, яке може бути встановлено та кероване менеджером пакунків», а менеджер пакунків — як «програмне забезпечення, яке автоматизує процес інсталяції та іншого керування пакетами» (Nagle та інші, 2022). ↩

  5. Пакети, які становлять решту 30% повних даних перепису в розподілі використання з довгим хвостом, не були представлені в остаточному звіті, тому їх не можна включити в наш аналіз. ↩

  6. GitHub — це платформа для хостингу та співпраці, яку учасники можуть використовувати для координації розробки та розповсюдження проектів ВВК. GitHub, заснований у 2008 році, став найбільшим у світі центром розробки ВВК. У січні 2023 року GitHub мав понад 370 мільйонів сховищ і понад 100 мільйонів розробників. Окрім особистих користувачів, платформу GitHub активно використовує широкий спектр приватних компаній, у тому числі Microsoft (яка купила GitHub у 2018 році), Facebook, Google та численні інші малі та великі фірми. ↩

  7. Ми спробували отримати доступ до всіх URL-адрес сховища, отриманих під час перевірки працездатності, щоб переконатися, що вони в робочому стані. Для тих, до яких ми не змогли отримати доступ на GitHub, ми вручну знайшли правильні URL-адреси. ↩

  8. для перевірки надійності ми випадковим чином вибрали 50 збігів пакетів із сховищем, отриманих за допомогою методу пошуку Google, і перевірили їх вручну. Усі збіги було вручну підтверджено правильними, що забезпечує додаткову підтримку для автоматичного методу зіставлення. ↩

  9. Оскільки назви пакета та менеджера пакунків відсутні, точна відповідність за допомогою libraries.io була неможливою. Назви технологій – це назви продуктів, призначені для клієнтів, і можуть бути менш технічними та точними, ніж назви пакетів для цілей внутрішньої розробки. Таким чином, використання назв технологій у пошуку libraries.io може спричинити значну неоднозначність. ↩

  10. Коефіцієнт відповідності становить понад 96%, причому невідповідні сховища складають лише 0,15% від нашого розрахованого значення попиту на ВВК, яке обговорюється нижче. ↩

  11. фільтрація базується на класифікації «підроблених користувачів» від GHTorrent, а також на будь-яких іменах користувачів, які містять слова «бот» або «робот», оточені спеціальними символами. Цей метод є більш консервативним, ніж інші методи виявлення ботів, як той, що використовується в GitHub Innovation Graph (https://innovationgraph.github.com/), який покладається на порогове значення частоти місячних комітів. ↩

  12. Зауважте, що ми зосереджені на вартості відтворення коду ВВК, написаного людьми, а не роботами. Однак напряму видалити всі внески ВВК з облікових записів роботів тут неможливо, оскільки ми не можемо побачити точні рядки коду, написані обліковими записами роботів на GitHub. ↩

  13. В альтернативній версії ми використовуємо поєднання підходу до ринку праці та товарів, який більше узгоджується з Greenstein and Nagle (2014) та Murciano-Goroff та ін. (2021). Однак застосування цього методу в наших умовах вимагає багатьох додаткових припущень через обмеження даних. Для простоти ми називаємо це підходом ринку товарів, для якого ми надаємо деталі та статистику, а також обмеження в Додатку A. ↩

  14. ми використовуємо лише чисті рядки коду, за винятком рядків документації та порожніх рядків. Отже, ми недооцінюємо справжню цінність відтворення кожного пакета. ↩

  15. Подібно до репрезентативної моделі агента (наприклад, див. Williamson 2006), можна подумати, що кожен пакет відтворюється окремими програмістами, які є ідентичними копіями один одного (і, отже, мають однаковий рівень кваліфікації, але не стають вищими ефективний через навчання). ↩

  16. у Wachs et al. є 179 округів. (2022), але 30 найбільших країн складаються з понад 88% глобальних активних учасників, а кожна з решти має менше 0,6% частки. 30 найкращих країн наведено в таблиці A 2. ↩

  17. ми обираємо референтні країни з високою та низькою заробітною платою на основі комбінації кількості активних розробників GitHub і середньорічної базової заробітної плати розробника програмного забезпечення. ↩

  18. таблиці в додатку показують еквівалентні значення з таблиці 2, якщо включити сегменти мови програмного забезпечення 1 і 2 (таблиця A3) і всі три сегменти мови програмного забезпечення (таблиця A4). ↩

  19. оскільки перепис містив конфіденційну інформацію про клієнтів, він не виявив галузей у всьому наборі даних, тому ми можемо показати значення для галузей лише за допомогою зовнішніх даних із BuiltWith. Ми зіставляємо веб-сайти BuiltWith з галузевою інформацією з наборів даних Orbis і Compustat. 94,6% веб-сайтів BuiltWith узгоджуються з галуззю завдяки цьому процесу. Для компаній (доменів), які пов’язані з кількома галузями, ми взяли середнє значення та розподілили його між галузями. ↩

  20. Таблиця A5 показує кошик ВВК та їх власних еквівалентів, які ми використовували. Щоб створити цей кошик, ми шукали пропрієтарне програмне забезпечення, яке мало еквівалент ВВК, подібний за загальною функцією та набором функцій, і намагалися визначити пари програмного забезпечення, які в сукупності охоплювали широкий і репрезентативний набір типів ВВК, які існують. ↩

  21. ми отримали середню ціну власного кошика товарного ринку, використовуючи 3 роки життя програмного забезпечення, тобто 1/(1-0,66), тому коефіцієнт амортизації становить 0,33. Це узгоджується з правилами Служби внутрішніх доходів США (IRS) щодо амортизації програмного забезпечення, де сказано: «Якщо ви можете амортизувати вартість комп’ютерного програмного забезпечення, використовуйте прямолінійний метод протягом терміну корисного використання 36 місяців». https://www.irs.gov/publications/p946#en_US_2022_publink1000107354. ↩

• Oct 24, 2024

  Порівняння перевірки запозичень Rust із аналогом у C#

  Це переклад орігінальної статті із англійської. Усі дяки туди!

  Хвилинку! C# має засіб перевірки запозичень?

  Дивіться: класичний приклад безкоштовної безпеки пам’яті у Rust…

  // error[E0597]: `shortlived` does not live long enough
  
  let longlived = 12;
  let mut plonglived = &longlived;
  {
  	let shortlived = 13;
  	plonglived = &shortlived;
  }
  
  *plonglived;
  

  …портуючи на C#:

  // error CS8374: Cannot ref-assign 'shortlived' to 'plonglived' because
  // 'shortlived' has a narrower escape scope than 'plonglived'
  
  var longlived = 12;
  ref var plonglived = ref longlived;
  {
  	var shortlived = 13;
  	plonglived = ref shortlived;
  }
  
  _ = plonglived;
  

  Гаразд, C# не поділяє концепцію «запозичення» із Rust, тому технічно було б неправильно називати це «перевіркою запозичень», але на практиці коли люди говорять про «перевірку запозичень Rust», вони говорять про весь статичний аналіз, який Rust робить для забезпечення безпеки пам’яті, тому C#, на мою думку, відповідає цим вимогам.

  Коли я вперше побачив цю фічу в C# (а також Span-и, ref struct-и та stackalloc), я був вражений: де всі кутові дужки та апострофи? Як це можливо, щоб я міг писати ефективний і перевірено-безпечний код на C# без ступеня з теорії типів? У цьому документі я сподіваюся коротко підсумувати своє розуміння безпеки пам’яті в C#, провести пряме порівняння між конструкціями C# і відповідними конструкціями Rust-у і, можливо, пролити світло на те, які саме компроміси зробив C#, щоб зробити це настільки зручним для користувача.

  Коротка історія безпеки посилань¹ C#

  З самого початку (2000-і) у C# було ключове слово ref для параметрів, що передаються у функцію за посиланням, але це було майже все, що ви могли з ним зробити. Якщо ви хочете робити ефективні речі з виділеною на стеку пам’яттю та опосередкованою адресацією², ви би зазвичай використовуєте «unsafe» частини мови або робили виклики до C++. Лише у 2017 році із випуском C# версії 7 ми почали бачити як ця фіча стала узагальнюватися у щось більш корисне. Із того часу C# додав:

  • ref локальні змінні
  • ref результати
  • безпечні ініціалізатори stackalloc
  • readonly struct та ref struct
  • in параметри (і пізніше ref readonly параметри)
  • умовні ref вирази
  • розширення до stackalloc
  • ref поля

  У процесі додавання вищезазначених фіч C#-у потрібно було визначити правила щодо використання ref, які й надалі забезпечуватимуть безпеку пам’яті. Специфікація мови називає ці правила «безпечними контекстами посиланнь»³ (див. тут і тут). «Безпечний контекст посилання», швидше за все, більш відомий програмістам Rust як термінів життя ⁴, область вихідного тексту у якому дійсний доступ/використання посилання.

  Порівняння безпечних контекстів і термінів життя

  Як і в Rust, у C# неможливо явно оголосити час життя значення. На відміну від Rust, у C# також неможливо призначити ім’я тривалості життя за допомогою узагальнених параметрів типу. В обох мовах правильне використання функції має бути зрозумілим лише за її оголошенням і не потребує аналізу її тіла. У Rust це означає, що терміни життя повинні з’явитися в декларації функції:

  //                  V name the lifetime using generic type parameter
  //                          V --------- V reference named lifetime in parameter and return types
  fn return_reference<'a>(r: &'a i32) -> &'a i32 {
  	r // <-- compiler makes sure we return what we claim to in the signature
  }
  

  C# не має окремого синтаксису для цього. Тим не менш, еквівалентний код все ще компілюється:

  // Нема термінів життя!
  ref int ReturnReference(ref int r){
  	return ref r;
  }
  

  Компілятор C# просто припускає, що термін життя повертаємого значення такий самий, як і термін життя параметра. Rust може зробити те саме…

  // Нема термінів життя!
  fn return_reference(r: &i32) -> &i32 {
  	r
  }
  

  …і називає цю фічу уникнення терміну життя⁵. У Rust уникнення терміну життя є необов’язковим, і програміст завжди може явно вказати час життя всіх посилань. У C#, навпаки, компілятор повинен визначити час життя для всіх оголошень функцій. Наприклад, така функція Rust повертає лише один із двох своїх аргументів:

  //                  V---V Two lifetimes for our two parameters
  //                              V------------------------V Return lifetime is the same as that of
  //                                                         the first parameter
  //                                           V Second parameter lifetime is unused
  fn return_reference<'a, 'b>(r: &'a i32, r2: &'b i32) -> &'a i32{
  	r // <-- compiler would not allow us to return r2 here
  }
  

  Уникнення терміну життя не реалізовано для функцій цієї форми, оскільки, здається, немає розумного значення за умовчанням для вибору. Тим не менш, C# повинен вибрати один:

  // Нема термінів життя!  Зачекайте.  А що вони є?
  ref int ReturnReference(ref int r, ref int r2){
  	return ref r;
  }
  

  Оскільки не має сенсу «вибирати» або r, або r2 для терміну життя повертаємого значення, C# консервативно припускає, що повернення може бути будь-яким із них. Таким чином, припускається, що і аргументи, і повертаємого значення мають однаковий час життя, який у специфікації називається «контекст виклику»⁶. Еквівалентна функція Rust виглядала б так:

  //                  V only one lifetime, called "caller-context"
  fn return_reference<'cc>(r: &'cc i32, r2: &'cc i32) -> &'cc i32{
  	r // <-- compiler allows us to return either r or r2
  }
  

  Це є менш корисним, ніж оригінальна функція Rust. Наприклад, наступний код буде успішно скомпільовано із першим оголошенням, але не з другим:

  fn wrapper(r: &i32) -> &i32{
  	let i = 12;
  	return_reference(r, &i) // error[E0515]: cannot return value referencing local variable `i`
  }
  

  і в C#:

  ref int Wrapper(ref int r){
  	var i = 12;
  	// Cannot use a result of 'Program.ReturnReference(ref int, ref int)'
  	// in this context because it may expose variables referenced by
  	// parameter 'r2' outside of their declaration scope
  	return ref ReturnReference(ref r, ref i);
  }
  

  Тут ми бачимо перший компроміс C#: терміни життя менш явні, але також менш потужні. Усталення також можуть бути неінтуїтивними: скажімо, ми хочемо написати метод на структурі, який повертає посилання на одного з членів структури. У Rust це просто:

  struct Foo {
  	member: i32
  }
  
  impl Foo {
  	fn get_member<'a, 'b>(&'a self, unused: &'b i32) -> &'a i32 {
  		&self.member // <-- compiler would not allow us to return `unused`
  	}
  }
  

  Насправді це настільки поширене явище, що Rust не вимагає від вас явного запису темріну життя, знову ж таки завдяки «уникненню терміну життя»:

  struct Foo {
  	member: i32
  }
  
  impl Foo {
  	fn get_member(&self, unused: &i32) -> &i32 {
  		&self.member // <-- would still not be allowed to return `unused`
  	}
  }
  

  Однак еквівалентний код C# не компілюється:

  struct Foo {
  	int member;
  
  	ref int GetMember(ref int unused){
  		// error CS8170: Struct members cannot return 'this' or
  		// other instance members by reference
  		return ref this.member;
  	}
  }
  

  Це тому, що усталення C# є протилежністю Rust: метод struct, який повертається за посиланням, може повертати будь-яке посилання, інакше ніж неявне посилання this. Приклад нижче компілюється:

  struct Foo {
  	int member;
  
  	ref int GetMember(ref int unused){
  		return ref unused;
  	}
  }
  

  Історія C# сягає корінням у стиль програмування OOP/Java, і якщо дозволити методам повертати посилання this, ви не зможете писати такий код:

  ref int DoAThing(ref int p){
  	// This reference is safe to return because it
  	// could only be referencing p
  	return ref new Foo().DoWhatever(ref p);
  }
  

  Відсутність явних анотацій терміну життя означає, що C# має вибирати, які шаблони дозволені, а які ні.

  Аварійний вихід: збір сміття

  Припустімо, ми хочемо написати функцію, яка повертає посилання на ціле число в буфері, якщо воно його знаходить:

  ref int Find(Span<int> haystack, int needle){
  	for(var i = 0; i < haystack.Length; i++)
  		if(haystack[i] == needle)
  			return ref haystack[i];
  
  	throw new Exception("Not Found");
  }
  

  Замість того, щоб створювати виключення, ми вирішили, що ця функція має завжди повертати щось, навіть якщо це не в haystack. Але нам більше нема чого повертати! Наступний код не компілюється:

  ref int Find(Span<int> haystack, int needle){
  	for(var i = 0; i < haystack.Length; i++)
  		if(haystack[i] == needle)
  			return ref haystack[i];
  	var def = 0;
  	return ref def; // Cannot return local 'def' by reference because it is not a ref local
  }
  

  Природно, що все що оголошене у Find, випаде з області видимості, коли Find повернеться, і тому не може бути повернуто за посиланням. Однак C# має надздібність. Ми можемо написати наступне:

  ref int Find(Span<int> haystack, int needle){
  	for(var i = 0; i < haystack.Length; i++)
  		if(haystack[i] == needle)
  			return ref haystack[i];
  	var def = new int[1];
  	return ref def[0];
  }
  

  Масив, на який посилається def, і значення, що повертається функцією, будуть існувати, поки на нього є посилання. Rust не має еквівалента цьому. Найближче, що ви можете отримати (я вважаю), це щось на зразок наступного:

  fn find(haystack: &[i32], needle: i32) -> Cow<i32> {
  	for item in haystack {
  		if *item == needle {
  			return Borrowed(item);
  		}
  	}
  	Owned(0)
  }
  

  Це не прозоро для викликача функції. Якби ми хотіли мати витік пам’яті, ми могли б написати наступне:

  fn find(haystack: &[i32], needle: i32) -> &i32 {
  	for item in haystack {
  		if *item == needle {
  			return item;
  		}
  	}
  	Box::leak(Box::new(0))
  }
  

  Box::leak повертає посилання, яке перетворюється на &'static i32, де 'static представляє термін життя програми (тобто «назавжди»). Із 'static терміном життя найлегше мати справу, оскільки його можна сконвертувати у будь-який інший термін життя. У C# збирач сміття існує, щоб робити посилання триваючими вічно, і тому кожне посилання на купу в C# можна вважати еквівалентним до Rust 'static.

  Ігноруючи наслідки продуктивності, це здається однозначно гарною річчю: 'static може показувати будь-куди, тому те, що всі посилання на купу є 'static гарантує максимальну гнучкість. На жаль, ні:

  Action CreateCounter(ref int i){
  	return () => {
  		// Cannot use ref, out, or in parameter 'i' inside
  		// an anonymous method, lambda expression, query
  		// expression, or local function
  		i += 1; 
  	};
  }
  

  Оскільки посилання на купу можуть існувати вічно, розміщувати ref у купі заборонено. Це означає, що ref не можна використовувати в лямбда-захопленнях або змінних членів класу/структури. Натомість мова надає ref struct, свого роду структуру, яка може містити refи, але також зобов’язана ніколи не потрапляти в купу.

  So: garbage collection lets C# do things safely that are impossible to do in Rust, but splits the language into the “garbage collected” and “stack allocated” worlds. Rust has a stack/heap distinction, but doesn’t need the concept of a “stack-only” or “heap-only” type. Отже: збирання сміття дозволяє C# безпечно робити те, що неможливо зробити в Rust, але розділяє мову на світи «можливо збирати сміття» та «виділено на стеку». Rust має різницю між стеком і купою, але не потребує концепції типу «лише стек» або «лише купа».

  Спільне використання XOR мутації

  У Rust кожне посилання або:

  • Спільне: може існувати кілька посилань і з них можна читати, але в жодне не можна писати
  • Ексклюзивне: посилання можна зчитувати або записувати, але дозволено існувати лише одне незапозичене посилання

  Це обмеження є центральним для гарантій безпеки Rust, але C# його не потребує. Причина полягає в тому, що Rust має враховувати можливість того, що посилання може стати недійсним у будь-який час. Наприклад:

  let mut v = vec![1, 2, 3];
  let r = &v[0];
  v.push(4);
  // r could be invalid now
  

  Навпаки, у C# посилання на купу ніколи не є недійсними, тоді як refи можуть бути недійсними лише після виходу з блоку:

  var v = new List<int>{1, 2, 3};
  var sp = CollectionsMarshal.AsSpan(v);
  ref var r = ref sp[0];
  v.Add(4);
  // r is definitely still valid (kinda)
  

  Щоб гарантувати правильність, перевірка запозичень Rust має заборонити будь-які операції, які можуть зробити посилання недійсним, доки воно використовується. Усе, що потрібно зробити C#, це переконатися, що посилання на дані, виділені стеком, ніколи не виходить за межі області, у якій воно було створено.

  Чому, здається, ніхто про це не говорить?

  Можливо, я погано шукаю ці речі, але ці зміни в C#, здається, повністю пройшли поза увагою в місцях, де ви читали про безпеку пам’яті та продуктивність. Можливо, це просто тому, що додавання мов відбувається дуже повільно, або, можливо, спільноти C# і Rust настільки мало збігаються, що недостатньо людей, які програмують обома мовами, щоб помітити подібність. Можливо, є щось, що робить ref підмножину C# настільки непридатною для використання, що люди її просто ігнорують (я, визнаю, поки що лише трохи погрався з нею).

  Ось моя теорія: C# вже мав еквівалент усіх цих речей у своїй «небезпечній» підмножині, тому, коли вводилися, зміни ref-безпеки зазвичай були оформлені як «наближення продуктивності безпечного коду до продуктивності небезпечного». що, мабуть, є протилежною до точки зору Rust «наближення безпеки високопродуктивного коду до безпеки мов високого рівня». Можливо, така постановка питання змушує людей випустити із уваги те, що хоча дві мови рухаються в протилежних напрямках, вони насправді можуть зближуватися одна до одної.

  1. Безпека посилань, це у англомовній літературі ref safety ↩

  2. Опосередкованою адресацією я називаю тут indirection ↩

  3. Безпечні контексти посиланнь у англомовній літературі ref safe contexts ↩

  4. Термін життя, тривалості життя, хоч і незвично це lifetime ↩

  5. Уникнення терміну життя це lifetime elision ↩

  6. Контекст виклику у англомовній документації називається caller-context ↩

• Oct 24, 2024

  Learning programming by immersion

  This is translation of post in Ukrainian

  I just read article about Stephen Krashen’s theory on second language acquisition and it struck me with similarities which I see in the learning how we build software. Maybe that can be said about any skill acquisition, but given that programming languages and natural languages have some similarities I would try to speculate a bit.

  Stehen’s idea is that your learn languages in one way: “When we understand what people say and when we understand what we read”. He distinguish learning and acquiring of the language. Learning is process where person deliberately study grammar rules, phrases and vocabulary and then consciously attempt to apply them as they speak. Acquisition on the other hand is unconsciousness process which naturally happen then person reading and speaking in new language. Acquisition happens when person immerse in the language environment where reading and listening to stories and eventually start to get grammar rules without actively thinking about them. That happens when persons perceive a lot of understandable material when person start intuitively grasp the material.

  I would stop explaining Stephen’s works, and suggest read short introduction and his own books and works to get ideas. From this point I concentrate on the similarities which I think interesting.

  First obvious similarity is that you never learn any programming language by study its grammar, syntax constructs and base library. Yes, you do study these, but from what we see in the classes it never enough for you to get why things that way. You have to painfully write some amount of code to understand how to apply each single language construct. Same with patterns of programming, even if you read and memorize descriptions you rarely get them from first time. You learn only after you apply them multiple times.

  Second observation, is that you never learn second programming language by simply learning syntax rules. You again should immerse into new language, and try again and again study and read other people’s code to get idea what is right. That also hint on acquistion and learning is not substitution to it. Only after you study couple programming languages from same family you may do that trick and just learn syntax. Same as if you know Kazakh, you know Turkish, but you still have to learn idioms from that language, and sometimes your words would sound funny to otherside. Yes, I seen that in programming language too.

  Third observation is that winning not most effective technical tools, but languages which have commmunities which have lot of simple stories how to learn language. That hugely helps with immersion into it, and as such people learn language faster. These stories is open-source projects and libraries. People learn from the tools they are using, and the simpler and less sophisticated tools available, that’s the better to understand how they working, and as such language in which they are written.

  Forth observation is that we still have disconnect between university education and what mythical industry want on it’s workplace. I think the reason for that, is that university is tailored for learning, and acquistion is not designed to be part of it. You should learn complex constructs and somehow apply them on your own. There not enough similar reference materials probably. I do not say that theoretical education somehow should be easier, not at all, but maybe there some complimentary activities can be intervowen into fabric of it.

  All of that is not a new observations. All of that very much part of myths of programming community. What if we should look more closely on the language educators, and attempt to learn from them? I think we have a lot of interesting initiatives which simplify programming acquision, but what if we need even more quality content for novices?

  Just thoughts!

• Oct 13, 2024

  Вивчення програмування через занурення

  Я щойно прочитав статтю про теорію Стівена Крашена щодо оволодіння другою мовою, і мене вразили паралелі, які я бачу у навчанні того, як ми будуємо програмне забезпечення. Можливо, це можна сказати про будь-яке оволодіння навичками, але, зважаючи на те, що мови програмування та природні мови мають певні схожості, я спробую трохи пофантазувати.

  Ідея Стівена полягає в тому, що мови вивчаються одним способом: “Коли ми розуміємо, що люди говорять, і коли розуміємо, що читаємо”. Він розрізняє вивчення та засвоєння мови. Вивчення – це процес, коли людина свідомо вивчає правила граматики, фрази та лексику, а потім свідомо намагається застосовувати їх під час розмови. Засвоєння, з іншого боку, є несвідомим процесом, який відбувається природним чином, коли людина читає і розмовляє новою мовою. Засвоєння відбувається, коли людина занурюється в мовне середовище, де вона слухає і читає історії, і зрештою починає засвоювати граматичні правила, не думаючи про них активно. Це стається, коли людина сприймає багато зрозумілого матеріалу і починає інтуїтивно засвоювати його.

  Я припиню пояснювати роботи Стівена і рекомендую прочитати короткий вступ та його власні книги й праці, щоб отримати уявлення. З цього моменту я зосереджуся на подібностях, які, на мою думку, є цікавими.

  Перша очевидна паралель полягає в тому, що ви ніколи не вивчите жодної мови програмування, просто вивчаючи її граматику, синтаксичні конструкції та базову бібліотеку. Так, ви справді вивчаєте це, але, як ми бачимо на заняттях, цього ніколи не достатньо, щоб зрозуміти, чому усе влаштовано саме так. Вам доведеться болісно написати певну кількість коду, щоб зрозуміти, як застосовувати кожну окрему конструкцію мови. Те саме стосується й шаблонів програмування: навіть якщо ви читаєте та запам’ятовуєте їх описи, ви рідко зрозумієте їх з першого разу. Ви навчитеся лише після того, як застосуєте їх багато разів.

  Друге спостереження: ви ніколи не вивчите другу мову програмування, просто вивчаючи її синтаксичні правила. Вам знову потрібно зануритися в нову мову, знову і знову пробувати, вивчати та читати чужий код, щоб зрозуміти, що є правильним. Це також натякає на те, що засвоєння та навчання — не взаємозамінні процеси. Тільки після того, як ви вивчите кілька мов програмування з однієї родини, ви зможете просто вивчати синтаксис. Так само, як якщо ви знаєте казахську, ви розумієте турецьку, але вам все одно доведеться вивчити ідіоми іншої мови, і інколи ваші слова можуть звучати смішно для півбесідника. Так, я бачив це і в мовах програмування.

  Третє спостереження полягає в тому, що перемагають не найбільш ефективні технічні інструменти, а мови, які мають спільноти, що мають багато простих історій про те, як вивчити мову. Це значно допомагає в зануренні в неї, і тому люди швидше вивчають мову. Цими історіями є проєкти з відкритим кодом та бібліотеки. Люди вчаться за допомогою інструментів, які вони використовують, і чим простіші та менш складні ці інструменти, тим легше зрозуміти, як вони працюють, а отже, і мову, якою вони написані.

  Четверте спостереження полягає в тому, що все ще існує розрив між університетською освітою і тим, що міфічна індустрія хоче бачити на робочому місці. Я думаю, що причина цього полягає в тому, що університет орієнтований на навчання, а засвоєння не є частиною цього процесу. Ви повинні вивчати складні конструкції і якось застосовувати їх самостійно. Можливо, немає достатньо подібних довідкових матеріалів. Я не кажу, що теоретична освіта повинна бути більш простішою, зовсім ні, але, можливо, в її структуру можна вплести якісь додаткові діяльності.

  Усі ці спостереження не є новими. Усе це є частиною міфів програмістської спільноти. А що, якби ми уважніше подивилися на викладачів мов і спробували навчитися в них? Я думаю, що у нас вже є багато цікавих ініціатив, які спрощують засвоєння програмування, але що, якби нам потрібно ще більше якісного контенту для новачків?

  Просто мої думки!

• Oct 7, 2024

  Швейцарский закон: Открытый исходный код по умолчанию

  Данная статья, является переводом с украинского. Также есть черновик перевода на казахский

  Открытый исходный код и открытые правительственные данные

  Через весь интернет пролетела новость, что швейцарское правительство теперь должно выкладывать все программные продукты, под лицензиями открытого кода. Это меня очень заинтересовало, но из-за того что Швейцария не англоязычная страна, то информации о том что именно было сделано, было очень мало. А как известно, анализ законов это не о том, что публикуют в новостях. Надо читать сами законы, пусть и в переводе, и стараться самостоятельно делать выводы. Также любому разработчику конечно интересны не только законы, но и код. Где этот магический открытый исходный код. Поэтому я постарался найти достаточно информации чтобы было и что почитать и что поклацать.

  Что именно сделала Швейцария

  Если коротко, то новый швейцарский закон требует от федеральной администрации, во-первых, опубликовать все свое программное обеспечение как программное обеспечение с открытым исходным кодом или сокращенно ОИК (OSS) (ст. 9). Во-вторых, государственные органы будут обязаны обнародовать свои данные как открытые правительственные данные, или ОПД (OGD) (ст. 10). В марте 2023 года Национальный совет и Совет кантонов Швейцарии приняли Федеральный закон об использовании электронных средств для выполнения государственных обязанностей (EMBAG). Этот закон уже вступил в силу и он стал новым законом Швейцарии о цифровизации для ее центральных и кантонских федеральных администраций. Этот закон делает требованием «электронные средства как вариант взаимодействия c по умолчанию» (ст. 3) и также описывает правовую основу для таких технологически аспектов информационных систем как интерфейсы, операционная совместимость, стандарты и пилотные проекты (статьи 12 - 15). Как и другая типичная мировая практика в области прозрачности государственной деятельности, этот закон предусматривает исключения для персональных данных и данных, имеющих отношение к национальной безопасности. Эти два требования к федеральным администрациям быть открытыми по умолчанию побуждают к значительному изменению структуры использования программного обеспечения в сторону большей открытости и прозрачности. Также, эти требования должны упростить повторное использование программного обеспечения и данных в государственных учреждениях.

  Предыстория

  История ОИК в Швейцарии началась около 12 лет назад. Вопрос о том, должна ли федеральная администрация публиковать ОИК начался с подачи Федерального верховного суда Швейцарии, который инициировал обсуждение в 2011 году. В то время Федеральный верховный суд опубликовал свое приложение OpenJustitia под лицензией ОИК. Его цель состояла в том, чтобы позволить другим судам использовать юридическое программное обеспечение и, как следствие, сэкономить налоговые поступления. Компании Weblaw это не понравилось. Она хотела продавать собственное программное обеспечение кантональным судам. Она утверждала, что с ней конкурирует Федеральный верховный суд. Это вызвало бурную общественную дискуссию в то время и в последующие годы. Например, в 2014 году политические инициативы, и после этого в 2016 году сделаны юридические заключения с разных сторон рассматривали вопрос о том, должно ли государство выпускать собственное программное обеспечение под лицензией ОИК, и если да, то на каких условиях. В итоге лоббирование со стороны парламентской группы по цифровой устойчивости (Parldigi) и успешная работа по разработке открытого программного обеспечения в IT-индустрии привели к созданию EMBAG. Новый закон не только разрешает выпуск ВВК, он фактически делает публикацию исходного кода обязательным, «если права третьих сторон или соображения безопасности не исключают или не ограничивают это». Поэтому сейчас все федеральные агентства Швейцарии начинают задумываться о публикации ОИК, и как конкретно они теперь должны работать. EMBAG создает идеальную правовую базу для реализации требований глобальной кампании ЕС Public Money, Public Code. В то же время, выпуск ОИК также приносит практическую пользу внешним поставщикам IT-услуг, работающим на рынке Швейцарии, поскольку позволяет им использовать программное обеспечение, которое они разработали для федеральной администрации, в проектах для других клиентов.

  Важность открытости по умолчанию

  На данный момент пока неясно, какие ключевые требования будут высказываться к публикации ОИК на практике. В 2020 году было составлено практическое пособие и стратегическое руководство по ВВК в федеральных администрациях Швейцарии(веб-архив). Этими рекомендациями руководит секция цифровой трансформации и управления информационно-коммуникационными технологиями Федеральной канцелярии Швейцарии. Однако в разделе «Выпуск ОИК» на данный момент указано, что федеральные ведомства сами несут ответственность за то, публикуют ли они ОИК и как сотрудничают с общинами. Поэтому надо ждать четких определений и рекомендации о том, как федеральные ведомства должны выполнять статью 9 EMBAG.

  Кантон Берн пока явлется лидером в полисимейкинге. Его IT-регулирование позволило офисам этого кантона выкладывать собственное программное обеспечение в виде ОИК с 2018 года. Кантон Берна также опубликовал правила и чек-листы для изложения ОИК. Что пример Берна также демонстрирует, как на самом деле законы с мягкими рекомендациями иметь ОИК сами по себе приводят к выпуску очень небольшого количества новых приложений ОИК. С 2018 года на профиле кантона Берн на GitHub было опубликовано только одно приложение. Соотношение выгод и затрат от публикации ОИК обычно слишком мало для отдельных агентств.

  Кроме того, многие администрации до сих пор недостаточно осведомлены о преимуществах ОИК для экономики в целом. Как следствие, административные офисы врядли не будут прилагать дополнительных усилий и выпускать свои внутренние приложения как ОИК, без лишней необходимости. Вот почему правило «открытый исходный код по умолчанию» в EMBAG является очень важным – теперь власти должны выполнять это требование. Выпуск ОИК становится новой нормой и не делать ОИК будет более сложно бюрократически.

  Открые государственные данные по умолчанию

  В дополнение к программному обеспечению, статья 10 EMBAG требует, чтобы федеральная администрация также обнародовала свои данные «в режиме по умолчанию» в будущем. Так же, как и в случае с выпуском ОИК, основными причинами этого правила в отношении открытых правительственных данных (ОПД) являются экономические соображения и содействие инновациям. Вышеупомянутая парламентская группа Parldigi также готовила политическую базу для этой темы в течение долгого срока. Прямого политического сопротивления, как это было с ОИК по этому вопросу не было. Однако предыдущие стратегии Федерального совета в отношении ОПД никак не побудили большинство федеральных агентств обнародовать какие-либо данные. Существующая швейцарская платформа для открытых правительственных данных opendata.swiss включает данные только из нескольких федеральных ведомств. Суммарно сейчас на этом портале уже есть коллекция из 9 000 наборов метаданных, описывающих данные государственного сектора.

  Одной целью, точно не самой важной, считается, что принцип «открытость по умолчанию» в EMBAG приведет к культурному сдвигу в отношении ОПД, и поможет иметь больше открытых государственных данных. В будущем федеральные ведомства должны публиковать свои данные бесплатно, оперативно, в машиночитаемом и открытом формате. Любая организация сможет повторно использовать эти данные для любых целей (ст. 10 (4)). Требования открытых данных порождают вопросы, как правильно управлять данными, и тем более как управлять открытыми правительственными данными. Правительственные органы сейчас производят и используют огромные объемы данных, как и любая компания в современном мире. Но часто до сих пор неясно, кто именно отвечает за какие сборы данных и где именно эти данные хранятся и обрабатываются. Кроме того, отсутствуют общие правила, гарантирующие совместимость, безопасность данных и конфиденциальность.

  Федеральное статистическое ведомство (BFS), отвечающее за хранение и сбор государственных данных, запустило интенсивное обучение для государственных служащих. Его целью является улучшение их знаний и опыта работы с данными. Федеральное статистическое ведомство имеет отдельное подразделение ОПД, которое занимается оперативной и стратегической работой по обнародованию федеральных данных. Это подразделение также уже имеет связи с кантонами и муниципалитетами. В отличие от ОИК, ОПД более понятен государственным учреждениям, благодаря поддержке BFS и знакомству с родом деятельности этой организации. Это также довольно типично для других стран.

  Международный контекст для Швейцарии

  Сейчас Швейцария смотрит на опыт ЕС, Германии и Франции для внедрения открытого кода и открытых данных. Германия и Франция являются логичным выбором для Швейцарии в силу мультиязычия и культурных и экономических связей. Попробую рассмотреть на что можно там посмотреть и провести аналогии.

  Согласно данным OSS Benchmark многие федеральные ведомства Швейцарии уже публикуют большое количество компонентов и приложений из ОИК. Однако все эти процессы происходят без какой-либо координации и довольно хаотично. Федеральные ведомства, если они не имели такого опыта ранее, нуждаются в практической поддержке, так как в издательстве ОИК без опыта можно легко затрагивать технические, организационные и юридические вопросы. Поэтому Швейцария смотрит на опыт Европейской комиссии, которая имеет программный офис с открытым исходным кодом (OSPO), и желает иметь свой локальный аналог. Департаменты наподобие OSPO могут посмотреть на многие различные аспекты которых нуждается ОИК в организациях, и могут консолидировать экспертизу которой сейчас так не хватает федеральным администрациям в Швейцарии. Главной идеей этой адаптации является чтобы этот офис способствовал обмену знаниями, заимствованию мирового опыта и способствовал налаживанию связей между департаментами при сотрудничестве над ОИК.

  Рассмотрим следующий пример - Германию. У нее есть свой национальный портал Open CoDE, на котором госадминистрация выкладывает решения по ОИК. Федеральное правительство Германии, несколько земель и многие муниципалитеты уже опубликовали более 100 программных решений на платформе. Это нужно рассматривать как работу Германии по продвижению цифрового суверенитета на рабочем месте в государственном управлении и общему продвижению IT-проектов. Open CoDE является частью деятельности правительства Германии по цифровому суверенитету. Правительство Германии также создало Центр цифрового суверенитета в Берлине. Этот центр направлен на наладить связь между государственным управлением и сообществами с открытым исходным кодом. Это аналог структуры OSPO от Европейской комиссии.

  Следующая страна - Франция. Франция запустила CodeGouv в 2021 году, это прямой аналог Open CoDE в Германии. Он содержит около 500 программных продуктов. Эта национальная инициатива состоит из многочисленных приложений OSS, руководящих принципов и дискуссионных форумов для обмена полученным опытом и конкретными ИТ-решениями. Имея бюджет в 30 миллионов евро, французская программа с открытым исходным кодом выполняет различные задачи. Одним из них является предоставление более 9 000 OSS-репозиториев от более чем 100 органов власти на онлайн-портале.

  Выводы

  Я вижу, что вводя EMBAG имеет целью следующие цели

  • улучшить расходы федерального бюджета на цифровую инфраструктуру
  • заимствовать мировой опыт в направлении государственной открытости
  • продвигать свои позиции в мире в разрезе цифровой устойчивости

  Также из-за мелкого размера страны, и большой децентрализации, Швейцария может себе позволить иметь такие радикальные законы. Я считаю, что надо смотреть какие практические проблемы будут в Швейцарии, чтобы учиться на их ошибках, потому что они довольно радикально взялись за дело.

• Sep 30, 2024

  Ашық код ретінде қабылданған: бұл швейцариялық заң.

  Бұл мақала украин тілінен аударылған. Сонымен қатар, орыс тілінде аудармасы бар.

  Ашық бастапқы код және ашық үкіметтік деректер

  Интернетте швейцариялық үкіметтің енді барлық бағдарламалық өнімдерді ашық код лицензиясымен жариялау керектігі туралы жаңалық тарады. Бұл маған өте қызықты болды, бірақ Швейцария ағылшын тілді ел болмағандықтан, нақты не істелгені туралы ақпарат өте аз болды. Белгілі болғандай, заңдардың талдауы жаңалықтарда жарияланатын нәрсе емес. Заңдардың өзін оқу керек, аудармасында болса да, және өздігінен қорытынды жасауға тырысу керек. Сонымен қатар, кез келген әзірлеушіге тек заңдар ғана емес, код та қызықты. Сол сиқырлы ашық код. Сондықтан мен оқуға да, тексеруге де жеткілікті ақпарат табуға тырыстым.

  Швейцария не нақты істеді

  Қысқаша айтқанда, жаңа швейцариялық заң федералдық әкімшіліктен, біріншіден, барлық бағдарламалық жасақтамасын ашық бастапқы кодты бағдарламалық жасақтама ретінде жариялауды талап етеді. Екіншіден, мемлекеттік органдар өздерінің деректерін ашық үкіметтік деректер ретінде жариялауға міндетті болады:

  2023 жылдың наурыз айында Швейцарияның Ұлттық кеңесі мен Кантонаралық кеңесі Үкіметтік міндеттерді орындауға арналған электрондық құралдарды пайдалану туралы федералдық заңды (EMBAG) қабылдады. Бұл заң қазірдің өзінде қолданыста және Швейцарияның орталық және кантондық федералдық әкімшіліктері үшін цифрландыруға қатысты жаңа заңына айналды. Ол «әдепкі ретінде электронды құралдарды» қолдануды талап етеді (3-бап) және стандарттар, интерфейстер, өзара әрекеттестік және пилоттық жобалар сияқты аспектілер үшін құқықтық негізді қалыптастырады (12 - 15-баптар). Заңның маңызды аспектілерінің бірі – федералдық әкімшілік бағдарламалық жасақтамасы мен деректеріне қатысты жаңа ережелер.

  • Біріншіден, EMBAG бойынша, федералдық әкімшілік өзінің қызметкерлері немесе аутсорсерлер әзірлеген бағдарламалар мен модульдерді ашық бастапқы кодты бағдарламалық жасақтама (OSS) ретінде қолжетімді етуі керек (9-бап).
  • Екіншіден, EMBAG федералдық әкімшіліктен барлық үкіметтік деректерді ашық үкіметтік деректер (OGD) ретінде жариялауды талап етеді (10-бап).

  Әлемдік тәжірибеге сай, бұл заң жеке деректерге немесе ұлттық қауіпсіздікке қатысты деректерге арналған ерекшеліктерді қарастырады. «Әдепкі ретінде ашықтық» қағидасына негізделген осы екі ереже ашықтық пен айқындыққа қарай елеулі парадигмалық өзгеріске әкеледі. Сондай-ақ, олар бағдарламалық жасақтама мен деректерді қайта пайдалануды жеңілдетуі керек.

  Бұл заңның қабылдануына әкелген саяси процестер

  Швейцариялық қоғам федералдық әкімшілік ашық бастапқы кодты (ВВК) жариялауы керек пе деген тақырыпта 12 жылдан астам уақыт бойы пікірталас жүргізіп келеді. Бұл 2011 жылы Жоғарғы федералдық сот бастамасымен басталды, ол өз OpenJustitia қосымшасын ВВК лицензиясымен жариялады. Оның мақсаты басқа соттарға осы құқықтық бағдарламалық жасақтаманы пайдалануға мүмкіндік беру және нәтижесінде салық түсімдерін үнемдеу болды. Алайда Weblaw компаниясына бұл ұнамады. Ол өз бағдарламалық жасақтамасын кантондық соттарға сатқысы келді. Компания Жоғарғы федералдық сот онымен бәсекелесіп жатыр. деп мәлімдеді. Бұл сол кезде және кейінгі жылдары қоғамдық пікірталас тудырды. Мысалы, 2014 жылы саяси бастамалар, көтеріліп, 2016 жылы әртүрлі тараптар құқықтық қорытындылар жасап, мемлекеттің өз бағдарламалық жасақтамасын ВВК лицензиясымен жариялауы керек пе, егер керек болса, қандай шарттармен жариялауы тиіс екенін талқылады. Соңында, цифрлық тұрақтылық жөніндегі парламенттік топтың (Parldigi) жүргізген лобби жұмыстары және IT-индустриядағы ашық бағдарламалық жасақтама әзірлеу бойынша табысты жобалар EMBAG заңын қабылдауға әкелді. Жаңа заң ВВК жариялауға рұқсат беріп қана қоймай, «егер үшінші тараптардың құқықтары немесе қауіпсіздік талаптары оны жоққа шығармаса немесе шектемесе», бастапқы кодты жариялауды міндетті етіп қояды. Сондықтан қазір Швейцарияның барлық федералдық агенттіктері ВВК жариялау және енді қалай жұмыс істеу керектігі туралы ойлана бастады. EMBAG ЕО-ның Public Money, Public Code атты жаһандық науқанының талаптарын жүзеге асыру үшін тамаша құқықтық негізді қалыптастырады. Сонымен қатар, ВВК жариялау Швейцария нарығында жұмыс істейтін IT қызметтерін ұсынатын сыртқы жеткізушілерге де практикалық пайда әкеледі, өйткені оларға федералдық әкімшілік үшін әзірлеген бағдарламалық жасақтаманы басқа клиенттермен жобаларда қолдануға мүмкіндік береді.

  Неліктен «әдепкі ретінде» маңызды қадам болып табылады?

  Қазіргі уақытта ВВК жариялауға қатысты қандай негізгі талаптар іс жүзінде қолданылатыны әлі де белгісіз. 2020 жылы Швейцарияның федералдық әкімшіліктерінде ВВК бойынша практикалық нұсқаулық пен стратегиялық ұсыныстар әзірленген болатын. Бұл ұсынымдарды Швейцария Федералдық канцеляриясының цифрлық трансформация және ақпараттық-коммуникациялық технологияларды басқару бөлімі әзірлейді. Алайда, «ВВК-ны жариялау» бөлімінде федералдық органдар ВВК жариялау және қауымдастықтармен ынтымақтастық орнату үшін өздері жауап беретінін көрсетілген. Басқаша айтқанда, қазіргі уақытта федералдық органдардың EMBAG-тың 9-бабын қалай орындауы керектігі туралы нақты техникалық сипаттамалар мен ұсынымдар өте қажет. Бұл жерде Берн кантоны алда келеді. 2018 жылдан бастап оның IT-реттеулері кантондық кеңселерге ВВК атауымен өз бағдарламалық жасақтамаларын жариялауға мүмкіндік берді. Берн кантоны сонымен қатар ВВК жариялауға арналған ережелер мен тексеру тізімдерін жариялады. Бірақ Берннің мысалы мұндай заңдардың өздігінен ВВК-ның өте аз жаңа қосымшаларын шығаруға әкелетінін көрсетеді. 2018 жылдан бері Берн кантонының GitHub-профилінде тек бір ғана қосымша жарияланған. Жеке агенттіктер үшін ВВК жариялаудың шығындары мен пайдасы арасындағы қатынас көбіне тым төмен болып келеді. Сонымен қатар, көптеген әкімшіліктер әлі күнге дейін ВВК-ның жалпы экономика үшін артықшылықтарын жеткілікті түрде білмейді. Соның салдарынан, әкімшілік кеңселер қажет болмаса, қосымша күш жұмсап, өздерінің ішкі қосымшаларын ВВК ретінде жарияламайды. Сондықтан EMBAG-тағы «әдепкі ретінде ашық бастапқы код» ережесі өте маңызды – енді билік органдары бұл талапты орындауға міндетті. ВВК жариялау жаңа нормаға айналуда.

  Мемлекеттік деректерді әдепкі ретінде ашу

  Бағдарламалық жасақтамаға қосымша ретінде, EMBAG-тың 10-бабы федералдық әкімшілікке болашақта өз деректерін де «әдепкі ретінде» жариялауды талап етеді. Ашық үкіметтік деректерге (ВУД) қатысты осы ереженің негізгі себептері де ВВК сияқты экономикалық тұрғыдан тиімділік пен инновацияларға қолдау көрсету болып табылады. Parldigi парламенттік тобы да осы тақырып бойынша саяси негіз әзірлеп келеді. Бұл мәселеде ВВК сияқты тікелей саяси қарсылық болған жоқ. Дегенмен, ВУД-қа қатысты Федералдық кеңестің бұрынғы стратегиялары көптеген федералдық агенттіктерді қандай да бір деректерді іс жүзінде жариялауға ынталандырмады. Қазіргі Швейцарияның ашық үкіметтік деректер платформасы opendata.swiss бірнеше ғана федералдық ведомстволардың деректерін қамтиды. Қазіргі уақытта осы порталда мемлекеттік сектор деректерін сипаттайтын 9 000 метадеректер жинағынан тұратын коллекция бар.

  EMBAG-тағы «әдепкі ретінде ашықтық» принципі ВУД-қа қатысты мәдени өзгерістерге әкеледі және үкіметтің жүйелі жұмысы арқылы ашық деректердің көбеюіне ықпал етеді деп күтілуде. Алдағы уақытта федералдық ведомстволар өз деректерін тегін, жедел түрде, машинамен оқылатын және ашық форматта жариялауы тиіс. Кез келген ұйым осы деректерді кез келген мақсатта қайта пайдалана алады (10-бап (4)). Ашық деректерге қойылатын талаптар деректерді дұрыс басқару, әсіресе ашық үкіметтік деректерді қалай басқару керектігі туралы сұрақтар туындатады. Мемлекеттік органдар да, заманауи әлемдегі кез келген компания сияқты, қазірдің өзінде үлкен көлемде деректер шығарып, оларды қолдануда. Алайда, көбінесе, қандай деректерді кімнің жинауға жауапты екені және олар нақты қай жерде сақталып, өңделетіні әлі де түсініксіз. Сонымен қатар, үйлесімділікті, деректер қауіпсіздігін және құпиялылықты қамтамасыз ететін жалпы ережелер жоқ. ВУД-ты кәсіби түрде жариялау осы және басқа да мәселелерді шешуді білдіреді. Бұл өте күрделі мәселе, және көптеген мекемелерде бұл үшін қажетті тәжірибе жетіспейді. Сондықтан осы салаға жауапты Федералдық статистика басқармасы (BFS) мемлекеттік қызметкерлерге арналған қарқынды оқыту бағдарламасын іске қосты. Оның мақсаты – мемлекеттік қызметкерлердің деректермен жұмыс істеу бойынша білімдері мен тәжірибесін арттыру.

  Федералдық статистика басқармасының құрамында федералдық деректерді жариялаумен айналысатын ВУД бөлімшесі бар, ол білікті кадрлармен қамтамасыз етілген және оперативтік әрі стратегиялық жұмыстарды атқарады. Бұл бөлімше кантондармен және муниципалитеттермен де байланыс орнатқан. ВВК-дан айырмашылығы, ВУД институционалдық және кадрлық тұрғыдан BFS ішінде айқын және тұрақты орынға ие. Бұл жағдай басқа елдер үшін де әдеттегі құбылыс болып табылады.

  Швейцария үшін халықаралық контекст

  Қазіргі уақытта Швейцария ашық код пен ашық деректерді енгізу үшін ЕО, Германия және Францияның тәжірибесіне сүйенуде. Осы елдердегі тәжірибеге назар аудара отырып, ұқсастықтар мен аналогияларды қарастырып көрейін.

  Қазіргі уақытта Швейцария ВУД қызметін ұйымдастыруда жақсы тәжірибеге ие. Бірақ ВВК қосымшаларын шығару мәселесінде ұйымдастырушылық және қаржылық жағынан әлі де шешілмеген сұрақтар бар. OSS Benchmark мәліметтері бойынша, Швейцарияның көптеген федералдық ведомстволары қазірдің өзінде ВВК-мен көптеген компоненттер мен қосымшаларды жариялап келеді. Алайда, бұл процестер ешқандай үйлестірусіз және жеткілікті деңгейде ретсіз жүзеге асуда. Бұрын мұндай тәжірибесі болмаған федералдық ведомстволарға практикалық қолдау қажет, өйткені ВВК шығаруда тәжірибенің жоқтығынан техникалық, ұйымдастырушылық және құқықтық мәселелер туындауы мүмкін. Сондықтан Швейцария Еуропалық комиссияның Ашық бастапқы кодтың бағдарламалық кеңсесі (OSPO), тәжірибесіне назар аударуда және өздерінің жергілікті аналогын құрғысы келеді. OSPO сияқты бөлімдер ұйымдағы ВВК-ға қажетті көптеген аспектілерді қарастырады және Швейцариядағы федералдық әкімшіліктерде қазір жетіспей жатқан сараптамаларды біріктіре алады. Бұл бейімдеудің басты идеясы – осы кеңсе білім алмасуды, халықаралық тәжірибені үйренуді және ВВК бойынша ынтымақтастықта департаменттер арасындағы байланыстарды орнатуды қолдау болып табылады.

  Келесі мысалды – Германияны қарастырайық. Германияның мемлекеттік әкімшілігі ВВК шешімдерін жариялайтын өзінің ұлттық Open CoDE порталы, бар. Германияның федералдық үкіметі, бірнеше жергілікті аймақтар мен көптеген муниципалитеттер платформада 100-ден астам бағдарламалық шешімдерді жариялаған. Бұл Германияның мемлекеттік басқаруда жұмыс орнындағы цифрлық егемендікті қамтамасыз ету және жалпы IT-жобаларды ілгерілету бойынша жүргізіліп жатқан жұмыстары ретінде қарастырылуы керек. Open CoDE – Германия үкіметінің цифрлық егемендікке қатысты қызметінің бір бөлігі. Германия үкіметі сонымен қатар Берлинде Цифрлық егемендік орталығын құрды. Бұл орталық мемлекеттік басқару мен ашық бастапқы код қауымдастықтары арасындағы байланысты нығайтуды мақсат етеді. Бұл құрылым Еуропалық комиссияның OSPO-ға балама болып табылады.

  Келесі ел – Франция. Франция 2021 жылы CodeGouv платформасын іске қосты, ол Германиядағы Open CoDE-ге тікелей балама болып табылады. Бұл платформада шамамен 500 бағдарламалық өнім бар. Аталған ұлттық бастама көптеген ВВК қосымшаларын, нұсқаулықтарды және тәжірибе алмасуға арналған IT-шешімдерге қатысты пікірталас форумдарын қамтиды. 30 миллион еуро бюджеті бар француздық ашық бастапқы код бағдарламасы әртүрлі міндеттерді жүзеге асырады. Солардың бірі – 100-ден астам мемлекеттік органның 9 000-нан астам ВВК репозиторийлерін онлайн порталға орналастыру.

  Қорытындылар

  Мен EMBAG-тың енгізілуі келесі мақсаттарға бағытталған деп есептеймін:

  • федералдық бюджеттің цифрлық инфрақұрылымға жұмсалатын шығындарын оңтайландыру;
  • мемлекеттік ашықтық саласындағы халықаралық тәжірибені пайдалану;
  • цифрлық тұрақтылық тұрғысынан әлемде өз ұстанымын нығайту.

  Сонымен қатар, елдің шағын аумағы мен жоғары деңгейдегі децентрализациясына байланысты, Швейцария осындай түбегейлі заңдарды қабылдауға мүмкіндік бере алады. Швейцарияның бұл іске радикалды түрде кіріскенін ескере отырып, олардың қандай практикалық қиындықтарға тап болатынын бақылап, қателіктерінен сабақ алуымыз керек деп ойлаймын.

• Sep 26, 2024

  Tokens in different languages

  How different languages define tokens?

  One guy ask in the chat, “how should I define tokens? should I combine token information with position in file?”. That’s simple question, and coming from C#, for me answer was obviously yes. But, I was curios how other languages define different tokens.

  So here compilation of links to GitHub, so you can take a look at yourself, how it’s done by the industry already. You would not find anything surpising. For me that’s cool, you can real old book and immidiately know how industry did it. Probably you should read different books, so you will see different approaches.

  C#/Roslyn

  • SyntaxToken.cs

  C++/Clang

  • Token.h

  C++/GCC

  • cpplib.h

  Dart

  • token.h

  Erlang

  • erl_scan.erl

  Haskell/GHC

  • Lexer.x
  • SrcLoc.hs

  Java/OpenJDK

  • Tokens.java

  JavaScript/V8

  • token.h

  Go

  • token.go

  Kotlin

  • KtToken.java

  Lua

  • llex.h

  Ocaml

  • defs.h

  PHP

  • tokenizer.stub.php

  Python/CPython

  • state.h

  R

  • gram.c

  Ruby

  • rubyparser.h

  Rust

  • token.rs
  • span_encoding.rs

  Scala

  • Lexer.scala

  Swift

  • Token.h

  TypeScript

  • types.ts
  • types.ts

  Zig

  • Tree.zig

  What to have your favorite language here? Drop me a line.

• Aug 22, 2024

  Відкритий код як усталено: це швейцарський закон

  Відкритий вихідний код і відкриті урядові дані

  Через увесь інтернет пролетіла новина що швейцарський уряд тепер повинен викладати усі програмні продукти, під ліцензіями відкритого коду. Це дуже мене зацікавило, але через те що Швейцарія не англомовна країна, то інформація про те що саме було зроблено, було дуже мало. А як відомо, аналіз законів це не про те що публікують у новинах. Треба читати самі закони, хай і у перекладі, та намагатися самостійно зробити висновки. Також будь якому розробнику звісно цікаві не тільки закони, а і код. Дей цей магічний відкритий код. Тому я спробував знайти достатньо інформації щоб було і що почитати і що потицяти.

  Що саме зробила Швейцарія

  Якщо коротко, то новий швейцарський закон вимагає від федеральної адміністрації, по-перше, публікувати все своє програмне забезпечення як програмне забезпечення з відкритим вихідним кодом. По-друге, державні органи будуть зобов’язані оприлюднювати свої дані як відкриті урядові дані:

  У березні 2023 року Національна рада та Рада кантонів Швейцарії ухвалили Федеральний закон про використання електронних засобів для виконання урядових обов’язків (EMBAG). Цей закон вже діє і він став новим законом Швейцарії про цифровізацію для її центральної та кантонських федеральних адміністрацій. Він робить вимогою «електроні засоби як усталено» (ст. 3) і також створює правову основу для таких аспектів як стандарти, інтерфейси, операційна сумісність та пілотні проекти (статті 12 - 15). Одним із важливих аспектів є нові положення закону щодо програмного забезпечення та даних федеральної адміністрації.

  • По-перше, відповідно до EMBAG, федеральна адміністрація повинна зробити програми та модулі, розроблені її власними співробітниками або аутсорсерами, доступними як програмне забезпечення з відкритим вихідним кодом, або скорочено ВВК(OSS) (ст. 9).
  • По-друге, EMBAG вимагає від федеральної адміністрації оприлюднювати всі урядові дані як відкриті урядові дані, або ВУД(OGD) (ст. 10).

  Як типова світова практика, цей закон передбачає винятки для персональних даних або даних, які мають відношення до національної безпеки. Ці два правила «відкритості як усталено» спонукають до значної зміни парадигми в бік більшої відкритості та прозорості. Вони також повинні спростити повторне використання програмного забезпечення та даних.

  Політичні процеси які призвели до цього закону

  Швейцарське суспільство вже понад 12 років веде дискусію, чи повинна федеральна адміністрація публікувати ВВК. Це почалося із подачі Федерального верховного суду, який ініціював дискусію у 2011 році. У той час він опублікував свій додаток OpenJustitia під ліцензією ВВК. Його мета полягала в тому, щоб дозволити іншим судам використовувати правове програмне забезпечення і, як наслідок, заощадити податкові надходження. Компанії Weblaw це не сподобалося. Вона хотіла продавати своє власне програмне забезпечення кантональним судам. Віна стверджувала, що Федеральний верховний суд конкурує з нею. Це викликало бурхливу суспільну дискусію в той час і в подальші роки. Наприклад у 2014 році політичні ініціативи, і після цього у 2016 зроблені юридичні висновки із різних боків розглядали питання про те, чи повинна держава випускати власне програмне забезпечення за ліцензією ВВК, і якщо так, то за яких умов. Зрештою, лобіювання з боку парламентської групи з цифрової стійкості (Parldigi) та успішна робота з розробки відкритого програмного забезпечення в IT-індустрії призвели до створення EMBAG. Новий закон не лише дозволяє випуск ВВК, він фактично робить публікацію вихідного коду обов’язком, «якщо права третіх сторін або міркування безпеки не виключають або не обмежують це». Тому зараз усі федеральні агентства Швейцарії починають задумуватися про публікацію ВВК, і як конкретно вони тепер повинні працювати. EMBAG створює ідеальну правову базу для реалізації вимог глобальної кампанії ЄС Public Money, Public Code. У той же час, випуск ВВК також приносить практичну користь зовнішнім постачальникам IT-послуг працюючим на ринку Швейцарії, оскільки дозволяє їм використовувати програмне забезпечення, яке вони розробили для федеральної адміністрації, в проектах для інших клієнтів.

  Чому «як усталено» це дуже важливий крок

  На поточний момент ще незрозуміло, які ключові вимоги будуть застосовуватися до публікації ВВК на практиці. У 2020 році був складений практичний посібник і стратегічна настанова по ВВК у федеральних адміністраціях Швейцарії. Цими рекомендаціями керує секція цифрової трансформації та управління інформаційно-комунікаційними технологіями Федеральної канцелярії Швейцарії. Однак у розділі «Випуск ВВК» наразі зазначено, що федеральні відомства самі несуть відповідальність за те, чи публікують вони ВВК і як співпрацюють із громадами. Іншими словами, зараз терміново потрібні чіткі специфікації та рекомендації щодо того, як федеральні відомства мають виконувати статтю 9 EMBAG. Кантон Берн тут вже на крок попереду. Його ІТ-регулювання дозволило кантональним офісам випускати власне програмне забезпечення під назвою ВВК з 2018 року. Кантон Берна також опублікував правила та чек-лісти для викладення ВВК. Але приклад Берна також демонструє, як насправді такі закони самі по собі призводять до випуску дуже малої кількості нових додатків ВВК. З 2018 року на профілі кантону Берн на GitHub було опубліковано лише одну заявку. Співвідношення вигод і витрат від публікації ВВК зазвичай занадто мале для окремих агентств. Крім того, багато адміністрацій досі недостатньо обізнані про переваги ВВК для економіки в цілому. Як наслідок, адміністративні офіси не будуть докладати додаткових зусиль і випускати свої внутрішні додатки як ВВК, без зайвої потреби. Ось чому правило «відкритий вихідний код як усталено» у EMBAG є дуже важливим – тепер органи влади повинні виконувати цю вимогу. Випуск ВВК стає новою нормою.

  Відкрити державні дані як усталено

  На додаток до програмного забезпечення, стаття 10 EMBAG вимагає, щоб федеральна адміністрація також оприлюднювала свої дані «як усталено» у майбутньому. Так само, як і у випадку з випуском ВВК, основними причинами цього правила щодо відкритих урядових даних (ВУД) є економічні міркування та сприяння інноваціям. Парламентська група Parldigi також готувала політичну базу для цієї теми протягом багатьох років. Прямого політичного опору, як це було із ВВК по цьому питанню не було. Однак попередні стратегії Федеральної ради щодо ВУД не спонукали більшість федеральних агентств фактично оприлюднити будь-які дані. Існуюча швейцарська платформа для відкритих урядових даних opendata.swiss включає дані лише з декількох федеральних відомств. Сумарно зараз на цьому порталі вже є колекція із 9 000 наборів метаданих, описуючих дані державного сектору.

  Однією метою, точно не самою важливою, вважається що принцип «відкрито як усталено» у EMBAG також призведе до культурного зсуву щодо ВУД, і допоможе мати більше відкритих даних, через системну урядову працю бути більш відкритими. У майбутньому федеральні відомства повинні публікувати свої дані безкоштовно, оперативно, в машинозчитуваному і відкритому форматі. Будь-яка організація зможе повторно використовувати ці дані для будь-яких цілей (ст. 10 (4)). Вимоги відкритих даних породжують питання, як правильно керувати даними, і тим паче як керувати відкритими урядовими даними. Урядові органи зараз виробляють і використовують величезні обсяги даних, як і будь-яка компанія в сучасному світі. Але часто все ще незрозуміло, хто саме відповідає за які збори даних і де саме ці дані зберігаються та обробляються. Крім того, відсутні загальні правила, що гарантують сумісність, безпеку даних та конфіденційність. Професійний випуск ВУД означає вирішення цих та інших проблем. Це дуже складне питання, і у багатьох установ на це часто не вистачає необхідної експертизи. Тому Федеральне статистичне відомство (BFS), яке відповідає за цю сферу, запустило інтенсивне навчання для державних працівників. Його метою є вдосконалення їхніх знань та досвіду роботи з даними.

  Федеральне статистичне відомство також має підрозділ ВУД, який кваліфіковано укомплектований і займається оперативною та стратегічною роботою з оприлюднення федеральних даних. Цей підрозділ також вже має зв’язки з кантонами та муніципалітетами. На відміну від ВВК, ВУД має чітку стабільну позицію всередині BFS із інституційної та кадрової точки зору. Це також доволі типова ситуація для різних країн.

  Міжнародний контекст для Швейцарії

  Зараз Швейцарія дивиться на досвід ЕС, Німеччини і Франції для впровадження відкритого коду і відкритих даних. Спробую розглянути на що можна там подивитися і провести аналогії.

  В поточний момент Швейцарія має гарний досвід в організації діяльності ВУД. Цього не можна сказати про випуск додатків з ВВК, де залишаються питання з організаційної та фінансової сторони.

  Згідно із даними OSS Benchmark багато федеральних відомств Швейцарії вже публікують велику кількість компонентів і додатків із ВВК. Однак усі ці процеси відбувається без будь-якої координації і доволі хаотично. Федеральні відомства, якщо вони не мали такого досвіду раніше, потребують практичної підтримки, оскільки у видавництві ВВК без досвіду можна легко порушити технічні, організаційні та юридичні питання. Тому Швейцарія дивиться на досвід Європейської комісії, яка має програмний офіс з відкритим вихідним кодом (OSPO), і бажає мати свій локальний аналог. Департаменти накшталт OSPO дивляться на багато різних аспектів яких потребує ВВК в організації, і можуть консолідувати експертизу якої зараз так бракує федеральним адміністраціям в Швейцарії. Головною ідеєю цієї адаптація є щоб цей офіс сприяв обміну знаннями, запозиченню світового досвіду і сприяв налагодженню зв’язків між департаментами при співпраці над ВВК.

  Розглянемо наступний приклад - Німеччину. Вона має свій національний портал Open CoDE, на якому державна адміністрація викладає рішення із ВВК. Федеральний уряд Німеччини, кілька земель і багато муніципалітетів вже опублікували понад 100 програмних рішень на платформі. Це треба розглядати як працю Німеччини по просуванню цифрового суверенітету на робочому місці в державному управлінні та загальне просування IT-проектів. Open CoDE є частиною діяльності уряду Німеччини щодо цифрового суверенітету. Уряд Німеччини також створив Центр цифрового суверенітету в Берліні. Цей центр має на меті налагодити зв’язок між державним управлінням та спільнотами з відкритим вихідним кодом. Це аналог структури OSPO із Європейської комісії.

  Наступна країна - Франція. Франція запустила CodeGouv у 2021 році, це прямий аналог Open CoDE у Німеччині. Він містить близько 500 програмних продуктів. Ця національна ініціатива складається з численних додатків OSS, керівних принципів та дискусійних форумів для обміну отриманим досвідом та конкретними ІТ-рішеннями. Маючи бюджет у 30 мільйонів євро, французька програма з відкритим вихідним кодом виконує різні завдання. Одним з них є надання понад 9 000 репозиторіїв OSS від більш ніж 100 органів влади на онлайн-порталі.

  Висновки

  Я бачу що вводячи EMBAG має на меті наступні цілі

  • покращити витрати федерального бюджету на цифрову інфраструктуру
  • запозичувати світовий досвід у напрямку державної відкритості
  • просувати свої позиції в світі у розрізі цифрової стійкості

  Також через дрібний розмір країни, і велику децентралізованість, Швейцарія може собі дозволити мати такі радикальні закони. Я вважаю що треба дивитися які практичні проблеми будуть в Швейцарії, щоб вчитися на їх помилках, бо вони доволі радикально взялися за справу.

• Apr 9, 2024

  Безкоштовні датасети із супутників!

  Знайшов класний тред із супутниковою зйомкою. Що цікаво, вони усі безкоштовні. Тому якщо вас цікавить сучасна геодезія, або агрономія, або планування інфраструктури, думаю буде цікаво подивитися.

  Найбільш часто використовувані безкоштовні багатоспектральні супутникові зображення:

  • Sentinel 2
  • Landsat-8

  Sentinel 2 має роздільну здатність ~10 м (для RGB), а Landsat-8 — ~30 м (для RGB).

• Jan 31, 2024

  Придумана складність у програмуванні!

  Студентам та джунам-фрілансерам присвячується.

  За останні кілька років мені кілька разів доводилося чути від розробників різного рівня досвіду, але переважно початківців:

  — Нещодавно я написав чудову, корисну, дуже складну програму

  Де ці епітети – чудовий, корисний та дуже складний стояли в один ряд і мали означати якісь виключно цінні якості цього твору. Щодо слів чудовий, корисний, то в цьому немає сумніву, але те, що слова дуже складний в цьому ряду – це, звичайно, нісенітниця.

  Чому це відбувається? Чому людина народжується і приходить у програмування із цілком здоровими ідеями. Вона вважає, що найвища похвала його програмі — це елегантність та простота. Простота це, напевно, найцінніше, що можна сказати про програму.

  І раптом, провчившись п’ять років в елітному виші, він змінює свої ідеї, змінює їх найнеймовірнішим чином, перетворюючи на протилежність того що було спочатку?

  В чому справа? Справа в тому, що програмування — це середовище, не схоже на багато інших видів діяльності. Навіть будучи тричі Едісоном, ви ніколи не зможете змусити котитися велосипед із квадратними колесами. Але нажаль програміст може. У програмування цілком імовірно зробити такий велосипед, що котиться і це відрізняє нашу діяльність від інших.

  Тобто коли людина приходить у програмування і тільки вперше стикається з можливостями, що відкриваються перед нею, у неї з’являється відчуття всемогутності. Будь-яке завдання, поставлене перед програмістом, можна вирішити. І насправді, витрачаючи справді серйозні зусилля, можна зробити цей злощасний велосипед.

  Більше того, коли людина дійсно вирішує це завдання, яке стало складним через неправильне проектування, він відчуває колосальний емоційний підйом. тобто йому доводилося боротися з протидіючим середовищем та усіма перешкодами, що виникали на його шляху через його неправильні початкові умови. Як він їх долав, і велосипед котився.

  І виникає такий рефлекс, я зробив складну програму, молодець. Рефлекс абсолютно неадекватний. Він не адекватний насамперед тому що проблема складної програми не тільки і навіть не стільки в тому, що на неї були витрачені якісь невідповідні зусилля, а в тому, що цю складну програму буде важко далі розвивати. А як відомо, виживають лише ті програми, що розвиваються. Звісно розвиваються у виробничому сенсі. Якщо програма перестає розвиватися, вона вмирає.

  При зміні програми у майбутньому, особливо в тій частині, яка виявилася складною, виявляється, що розробник більше не може впоратися з цією складністю. Цей складний розділ був написаний у стані колосального творчого підйому, завдяки якому розробнику вдалося втримати в голові всі тонкощі алгоритму. Але минуло два-три тижні, а можливо, і більше, і всі ці алгоритмічні фокуси стерлися з пам’яті і відновити їх абсолютно безнадійно. І так програма вмирає. Вона загасає у виробничому випадку. Якщо розробник студент і він навчається, він представив свою програму викладачеві, програма спрацювала, всі задоволені, результат отриманий, і таким чином цей неправильний рефлекс закріплюється, і тому лише через роки до програміста повертається почуття реальності. Аналогічним чином ситуації трапляються у початківців які самостійно працюють на фрілансі, або без ретельного нагляду із боку досвідчених працівників. Ти зробив програму, клієнт вдоволений, ти отримав гроші. Хто буде потім це підтримувати це зовсім інше питання. Знову ми бачимо підкріплення не правильного рефлексу.

  Із досвідом складність справді стає ворогом, ворогом номер один, і коли програміст відчуває, що його алгоритм ускладнюється, його реакція зазвичай не така: “ого, як чудово зараз я почну вирішувати складне завдання” а “що ж це таке? імовірно я щось наплутав у проектуванні, треба повертатися на крок або два назад і спробувати зрозуміти що пішло не так». Це те, до чого приходить програміст, але приходить дійсно не без додаткових зусиль.

  Ну, підбиваючи підсумок, можна сказати, що у програмуванні немає складних завдань, як і немає складних для реалізації предметних областей. Є нерадиві програмісти або хто ще не достатньо досвідчений і не приділяє належної уваги боротьбі з цією складністю.

• Jun 7, 2023

  MSBuid як мова програмування!

  Зі сторони виглядає що багато програмістів побоюються MSBuild і намагаются ніколи його не чіпати. Це на мою думку не дуже продуктивно. Багато цих страхів щодо MSBuild через те що у нього є свою, і досить незвична для програміста, термінологія. Я спробую показати що MSBuild це лише дінамічна мова програмування, досить чудернацька, але лише мова програмування. Можливо це полегшить читачу шлях його вивчення.

subscribe via RSS