Open Source during War: Challenges of Independent Development Teams in Ukraine

To launch an important initiative, in September — October 2022 I interviewed 15 independent development teams that make open source products for Ukraine’s victory in the war.

During the research, I came up with interesting findings and conclusions that I want to share with you in this post.

General observations:

  1. Share of source code. According to interviewees, open source accounts for up to 90% of the code of solutions they develop, and the role of open source is key in most of the solutions used.
  2. “Not only software”. During the war, open hardware architectures are actively used as open source software. It allows achieving the maximum cheapness of solutions.
  3. “Licensing afterwards”. During the war, no one looks at licenses. The main aim is to eliminate more enemies. Although everyone understands that for the MVP to turn into a business, it will be necessary to put everything in order after the end of the war. But that will be after the war.
  4. “Changed code is not published”. Since an open source solution can be easily exploited by an enemy, developers generally do not plan to publish their code.
  5. “The new Kalashnikov assault rifle”. Many solutions use the Raspberry Pi platform and autopilot or other software. This bunch is aptly called “the new Kalashnikov in the age of computers“. The platform allows not only to quickly prototype but also to release working solutions “in production on the battlefield”.

Respondents also noted the main problems of teams and solutions:

  1. Lack of good open source solutions and experts in radio electronics;
  2. Many developers don’t know how to work with open source, they are prejudiced that it’s worse and lack the qualifications to deploy complex open source solutions. According to the interviewees, “it’s easier to write a basic solution from scratch than deal with a complex and old one”;
  3. The open source ecosystem lacks tools for development and debugging;
  4. Duplicate solutions: since developers don’t use common repositories, and don’t publish their solutions, in such “anarchy” it sometimes turns out that some duplicated solutions are made by different teams without knowing each other;
  5. No unified architecture and development standards, especially among volunteer groups, which leads to delays in integrating products into infrastructure or more general solutions;
  6. Most of the programmers contracted into the army spend a lot of time on shifts, not actually on programming;
  7. No good systems for monitoring experiments between teams in AI development;
  8. There are no ready-to-use pipelines for the release of cloud solutions;
  9. Not enough datasets;
  10. The issue of AI rights that are developed on datasets with incomprehensible authorship;
  11. The question of how the developed IT systems will be operated and by whom is inefficiently solved.

Instead of conclusion

Undoubtedly, in the first 2–3 months of the war, a community of Ukrainian programmers was able to create a fairly large number of open source solutions that are useful during the war “right now and today”.

Due to the continuation of the military conflict, both sides are improving their tools.

IT infrastructure and solutions need to be expanded and improved, which requires a more thoughtful architecture, qualified personnel, management and complex infrastructure.

This is essentially equivalent to the release of IT solutions “into a full-fledged commercial production” during the war. For such tasks, open source often shows unpreparedness in the commercial sphere, and therefore in the military.

It’s also worth noting the problem with licenses. Software developers have to deliberately violate the license in terms of hiding the code from publication so as not to disclose it to the enemy.

This issue needs to be somehow systematically settled at the level of standard licenses.

For example, by introducing “open source licenses for military communities”, which allow disclosure of the code only within certain communities.

I hope this post was useful to you!

Best regards,

Vitaliy Goncharuk


Head of NGO “Tech Institutions”