‹‹‹ Blog Overview

Introduction

The space industry as a whole is at a literal crossroads, one could say. This goes much beyond just “new space” vs. established companies or “commercial” access to space. The power is shifting, and the locations of where progress and innovation are happening are visibly moving. The way IP is being handled is a critical aspect of this shift, which also applies to software. Software plays an ever increasing role in just about every aspect of the aerospace industry or, more specifically, its space sector. It controls, it models, it analyzes, it predicts, it supervises, it plans, it takes over roles that were previously the exclusive domain of dedicated hardware. Its importance can not be understated. It does not make sense to speak about the “software industry” as an isolated phenomenon anymore as developing & maintaining software have become integral parts of other industries such as the space industry. Software development skills are a key enabler in the toolkit of many scientists and engineers of virtually every discipline that touches space. As a result, many industries, including the space sector, are subjected to cultural developments that arose within the software industry, first and foremost the idea of “open source”. Some industries have adapted and greatly benefited form “open source”. Others have yet to follow such as the space industry – because of, but not limited to, rather specific reasons.

Engineers and scientists trained after the year 2000, to whom could be referred to as the “cubesat generation”, have had a lot of freedom to experiment with new and “alternative” technologies while in university, prominently including open source software. Though, once transitioning out of university and into industry, many have been literally “re-trained” in the “established ways” of doing things. Few had the opportunity to professionalize what they had started as students. On an agency level, there are certainly attempts at introducing new thinking, some of which became rather prominent, even outside of the space industry. The Ingenuity helicopter on Mars is a good example, which uses the open source flight software “fprime”. On one of the most widely used online platforms for collaborative software development, the contributors to projects that was used by JPL’s Ingenuity project even received a special badge, which has become a well-known status symbol among software developers.

Some perceive the idea of open source as an ideological competition to proprietary software, which is really not. Some even falsely refer to it as socialism or communism. However, open source merely is a different approach in dealing with IP, resulting in different business models. It comes with different trade-offs and benefits. Those industries who embraced it hugely benefited from it, though the transition usually was not trivial. In almost all instances, it boosted innovation and growth, lowered the barrier to entry for new competitors and improved the overall quality of products – if done wisely. It requires a certain critical momentum, a critical application that transitions to open source with greatly improved use cases and handling, for an industry or sector to begin a transition as a whole. The initial adoption phase usually lasts for about two years, after which proprietary applications are virtually eliminated for a given use case across the industry. Other use-cases then follow.

The presented paper is intended to provide an overview for the uninitiated: What is open source? What is software? How do other industries handle it? What are business models? How does a transition look like? What are common misconceptions and actual benefits? Citations therefore, in many cases, directly point to resources that can be interpreted as overviews and collections of references themselves. They are intended to provide the reader new or not completely familiar with the subject matter a gentle introduction. While the author has experience in both, the north American and the European space industry, the presented point of view is inherently European. While there are many similarities between both markets, the European market appears to be even further behind than the north American one. It must be noted that this is not a fundamentalist, ideological stance for open source in the footprints of the likes of Richard Stallman. It is a practical observation from a business point of view. How can we, the space industry, in particular the one in Europe where the author resides, reinvent ourselves to innovate, get back into a leading position, grow our businesses and sustain our status long-term?

Terminology

What is “software”?

For the purpose of this paper, the term “software” needs to be briefly defined. Software can be understood as a sequence of instructions that can be executed by a computer. The sequence of instructions is usually refereed to as “code”. Code can have varying degrees of abstractions, also referred to as “programming languages”, from barely understandable machine languages to high-level, human readable abstractions sometimes referred to as “high languages”. Notably, a computer can only understand the lowest of abstractions: Machine code. Any higher abstraction therefore must be translated, also known as “compiled”, into machine code or interpreted. The translation process must be carefully configured, which is a complicated problem on its own. While machine code can be read, understood and edited by specially trained humans, it is an extremely hard and time-consuming task. Machine code is therefore in many jurisdictions legally and technically falsely understood as something that “hides” what the software is actually doing. In reality, it is just a matter of resources, time and money, if one wants to understand it.

It should be noted that the spectrum of abstractions was recently extended into natural languages via LLMs, which, at the end of the day, also only generate code that eventually gets compiled into machine code or interpreted.

The life-cycle of software

No matter the applied or chosen model of software or systems development, software always has a life-cycle. It tends to remain “unfinished”, except for special use cases. Software requires maintenance like any type of infrastructure. The reasons are manyfold. In short, circumstances and the environment in which software exists keep constantly evolving, which does not even include the desire of adding new features to a given piece of software. Software is, but all means, always a component of a larger system and never self-serving. Yet it also has components of its town, sometimes coming from third parties, referred to as “dependencies”. As the larger system or dependencies change – even if it is only structural changes – software must follow. Maintenance is almost always underestimated, both from an engineering point of view but also from a managerial / economic point of view. Maintainability must be taken into account when developing new software right from the start. Limits to maintainability – not potential lack of quality – are the dominating reason why software projects stall, are dropped and / or need to be re-developed from scratch. Yet developing well-thought-through software that can life a long live is not a trivial task at all and challenging even for the largest and financially most solvent organizations. It must be added though that quality and reliability is of cause also critical and, depending on the use-case, anything but trivial to achieve on its own.

On top of that, as more and more people develop software as part of their work as scientists an engineers of other disciplines, without given proper training in software development, design thinking has taken a back-row-seat both in both day-to-day business and education. Software has become structurally bad in an impressive number of cases, which is especially true for highly specialized applications. To be clear, this is about its code: It is barely maintainable; its states and state transitions are not even fully understood by its developers who, in too many cases, do not even know how to think appropriately in order to understand the consequences of their development. The final nail in the coffin usually comes from management mistakes. Employees are often forced to complete projects in certain budgets and time frames without fully comprehending the task ahead of them. Ultimately, the aspect of a life-cycle is largely ignored. The contemporary solution to the aforementioned problems appears to be outsourcing, i.e. buying software “from somewhere else” or paying for online services, i.e. “the cloud”, which is falsely deemed as more professional.

For reference, software development for space applications within the European space sector, is currently standardized via ECSS-E-ST-40C, dating to 2009, and is supported by ECSS-E-HB-40A, dating to 2013, as well as ECSS-E-TM-40-07, dating to 2011.

What is “open source”?

If only machine code is provided to an end user or customer, usually for a fee, a piece of software is referred to as proprietary. While the machine code could theoretically be analyzed, this is usually explicitly prohibited through license agreements which are forced onto paying customers, next to restrictions through laws. Open source evolves around the idea that the original higher levels of abstraction, which were translated into machine code, are available for review and editing. In legal terms, open source is commonly defined following the OSI’s definition based upon three characteristic properties:

• The software, i.e. the source code, is available in a human-readable form.
• The software may be copied, distributed and used freely.
• The software may be altered and re-distributed in its altered form.

To facilitate the mentioned properties, open source software usually gets distributed with a special open source license. The most critical aspect of an open source license is its “copyleft”. Broadly speaking, there are two family of licenses, one similar to the GPL, the other similar to the BSD/MIT licenses. Both allow commercial use, though with varying implications. The GPL-like licenses have a reciprocal or strong “copyleft”. It usually forces edits and improvements to be made available to the original authors under the same license. Although this software can usually be a component of a commercial product, one has to be careful with how far the license of such an open source component “infects” more components of the product. Certain special reciprocal licenses with weaker “copyleft”, e.g. the Lesser GPL, avoid such infections. The opposite extreme can be found in licenses with “non-copyleft” (BSD/MIT), which basically state that the code can be used and edited in any way imaginable, even within proprietary products – in many cases only requiring to attribute the original authors. It is worth noting that most common open source licenses, certainly most relevantly the GPL-family, have been found enforceable in a number of jurisdictions, including the US and several EU member states.

Open source beyond software

Although open source is mainly associated with software, its philosophy can also be applied to hardware and other IP. A few noteworthy examples illustrate the idea. The Open Compute Project, having its origins at Facebook, facilitates the sharing of data center product designs and industry best practices. It is a substantial body of hardware-related IP that is basically developed and distributed in the open. The RISC computer architecture in its many reincarnations is another interesting technology. Some of its variations such as OpenRISC for instance are developed under licenses very similar to open source. In the creative space, but also for many types of data, CC licenses have become a dominating form of distributing and extending existing work.

What does “open sourcing” mean?

If a formerly proprietary product is turned into open source, this transition is sometimes referred to as “open sourcing”. It is a trend that has lately presented itself in many industries. Besides, “open sourcing” sometimes also refers to products being intentionally developed as open source from scratch, accompanied by matching marketing. The role of the software-tool “git” and platforms like “Github” can not be underestimated in this context, although other similar platforms existed earlier, for instance “SourceForge”. The widespread use of “git”, a distributed revision management tool crucial for modern software development and open source itself, and the ease of use and availability of “Github”, sometimes referred to as the “Facebook for software and open source software development”, have created a space in which “open sourcing” is a kind of event that is taken seriously. As stated earlier, not only software can be “open sourced”. Other forms of IP have lately shown up on platforms like Github as well.

The motivations for open sourcing are again manyfold. The most trivial one might be marketing, though there can also be very strategic motivations. The history of audio & video coding formats, see here and here, for instance is long and convoluted, dominated by massive legal conflicts over patents i.e. control over certain markets, which drastically limited competition and innovation. There have been repeated attempts at creating open i.e. royalty-free patent pools next to dedicated structures for legally defending them plus central, closely related open source projects. Others see “open sourcing” of IP as a means of furthering their business by fostering competition. The “Patent Pledge” made by Tesla in 2014, while certainly controversial and combined with specific limitations that one could interpret as “not being fully open source”, is a prime example.

The most common motivation though for “open sourcing” is to attract contributions by third parties, i.e. a distributed work load. A single organization may be able to develop a semi-decent product, but they may fail to perfect it or to keep it alive for long. By opening the source code to users – but also competitors – it creates an incentive for everybody involved in the use case of this software to use and, subsequently, co-maintain and further develop the software. While there is certainly management overhead, third-party contributions are by design open source themselves, which improves the original product. The organization controlling the project automatically has the potential to gain a larger market share and to effectively control the direction in which a certain technology is moving. As a side effect, if enough critical momentum is reached, an open source project started even by a small organization may attract more developers than a proprietary project of a large competing organization might have.

Open source business models

There are many more or less well established and practiced business models for open source. Feature development on demand, consulting and training are among them. Though, it should be noted that open source shines the most if viewed in a wider context, as a component of a larger system.

Proprietary vs. open source duopolies

It is not a clean transition from proprietary to open source software in all cases. Many disciplines and industries have developed duopolies, featuring two dominant software solutions with one being proprietary and the other being open source. While some of those duopolies can be understood as friendly competition with more or less separate use cases, many are fought hard usually from side of the manufacturer of the proprietary product. This goes to show how existing open source is viewed from a business angle.

Arguments against vs. common misconceptions about open source

There are many arguments against open source, mainly but not only caused by deeply routed misconceptions on what software and what open source are. Also, lobbying efforts and information campaigns “stretching the truth” have done their part.

Noticing open source solutions – education

Probably the most simple one: Education among the seasoned professionals. Unless someone is really interested in software / hardware development in one way or another, open source can appear as if it does not exist. The convenience of just buying a proprietary product is also worth noting. On a university level, open source does exist a bit more, though many university are currently pushing back into proprietary solutions – a trend that is common in both north America and Europe. Current students are therefore only subjected to open source if there is motivated lecturers or other extra-curricular activities driving the students to do their own research. The heydays of open source at universities are certainly over.

Overall quality and mode of operation

Many understand open source as products of “poor quality” and call it “tinkering”. This may well be true for many open source projects on the surface, but the spectrum is broad. The open source ecosystem is not as protected and coherent as commercial proprietary products and ecosystems. The mode of operation of development is different and, more importantly, the mode of participation and use differs drastically. Open source is not free in a sense that it does not cost money to use. One must actively participate and pay to make sure it does what is required in a given use case. The quality argument therefore comes down to the misconception that open source must be cheaper than proprietary software because there is not price sticker.

File formats and protocols

Certain open source tools can not read or write file-formats (flawlessly) which are perceived as “industry standard”. Microsoft’s Excel file formats are prime examples, which are only partially documented and inherently complicated. Few open source tools can read them in a meaningful manner and none can claim full or even partial flawless compatibility. The underlying issue can therefore be understood as the proprietary nature of the file format itself, which forces users into using the proprietary tools which can read and write them properly. Proprietary file formats should conceptually be treated as “not owning data” in the first place. In even more extreme ways, some SaaS solutions have reached a state where a lot of data can not be exported at all, so there is not even a file or data format to begin with, at least from a user’s perspective. If proprietary software or SaaS solutions stop working, the data is in many cases simply “lost”. The lack of open formats and the ability to export data are therefore the actual problems.

Software Security

Open source is referred to as insecure. Some say that proprietary software is better because its design (and flaws) are hidden, hence “security by obscurity”. This has been proven wrong in countless cases. Security can only be achieved by quality. This is especially true when it comes to critical software such as solutions of logging into remote systems. Custom solutions have a history of problems while more common open source solutions, reviewed by generations of developers, have rightfully gained the trust of many developers and users. The open source tool OpenSSH for instance, also know as “ssh”, secures most parts of the modern internet and therefore far more expensive things than space assets. If ssh was broken, the security of many satellites would implicitly as a result also fall apart for example. OpenSSH had its fair share of security issues, but because it is open source, many people reviewed, analyzed and fixed them so that OpenSSH is now viewed as one of the most secure products in the market. Most software security problems, at the end of the day, can be attributed to bad management and lack of education, which is solidified by the proprietary nature of projects and businesses.

There is one rightfully worrying aspect in the open source security sphere though, the security of the supply chain. The problem can be described as a combination of blind trust in third-party open source dependencies and a lack of funding for many open source projects, i.e. the misconception that open source does not cost anything. Noteworthy examples can be found in malicious open source software being distributed by open source package repositories for a number of programming languages, NPM for JavaScript for instance with its recent issues, see here and here, or PyPI for Python with its recent events, see here and here. There are also more sophisticated attacks emerging like the XZ Utils backdoor, indirectly targeting OpenSSH, which must be taken absolutely seriously but appear to be rare.

Supply chain economy

As mentioned earlier, the financial foundation and overall economic responsibilities are critical for the success of open source. The now infamous Heartbleed security bug in OpenSSL, an extremely widely used open source software library, which is estimated to have caused damages at the order of magnitude of .5 billion USD let to the start of the CII – an industry initiative which for the first time actually provided funding for the development of OpenSSL and highlighted the issue broadly. As critical as OpenSSL was (and still is), its development and more importantly maintenance was virtually unfunded. Investing in open source always implies investing into the supply chain, i.e. dependencies, if the investment is intended to be successful.

Liability

Who is liable if the licenses of open source projects explicitly excludes any form of liability? A commonly asked question. One might prefer to buy a commercial, most likely proprietary product instead. In reality, many if not most industries at least in Europe became used to perceiving “software flaws” as a form of “higher power” against which nothing can be done. “Software flaws” in proprietary products and services causing virtually global outages of office, cloud and security solutions have, despite their impressive scale, rarely let to compensation or litigation.

Cost Savings

Many proponents of open source advertise it as a means to save cost. This really is not the case as explained earlier.

Point of contact

A proprietary product is ideally accompanied by commercial support offered by its maker, at least in theory. The maker might go out of business and all knowledge and even the source code might get lost, as it has happened many times. Open source projects on the other hand usually do not have a single point of contact for support. Many larger projects have an ecosystem of developers and contributing companies who happen to also offer commercial support. For smaller projects, no such dedicated offers might exist. It is true that arranging proper support for an open source project can be challenging, but it is just a different way of thinking about cost – again. If no support is available, one must understand and support the software independently or financially incentivize a third party to start offering support. On the upside, this creates a certain form of ownership of the project and its IP.

IP and patents

The fear of patents is another commonly cited problem. Open source projects might be in violation of existing patents as many of its authors do not check for collisions with existing software or mathematical patents. However, it is entirely the same for proprietary software, though the violation of a patent might be a little harder to spot. Software patents are an ongoing subject of discussion in industry and politics, with fairly significant arguments against them regardless of the software being open source or proprietary. A big enough open source project with a big enough ecosystem of users might have a good chance at defending against legal attacks simply based upon its size. Open source projects have been found to result in prior art in a surprising number of cases, essentially voiding competing patents.

Compliance Rules

Publicly traded companies, companies planning to become publicly traded or critical suppliers of publicly traded companies have a tendency to be subject to compliance rules of ever increasing complexity – though compliance rules also extend to other types of organizations. While compliance rules are not a bad idea fundamentally, they have lately fostered herd dynamics, especially when it comes to IT and IT security. At the same time, IT administrators, once academically educated, well versed people, have gradually been substituted by people with limited professional training in common “best” practices, usually proprietary in nature, and virtually no academic background. This combination of a lack of education, a lack of critical thinking and a stiff set of compliance rules has really put the breaks onto any chance of actual innovation or change in aforementioned companies and organizations. Open source is not understood at all in this context and there is not even the willingness to understand it by the very people responsible for IT. On a management level, technical knowledge is equally in decline, resulting a lack of opposition to what IT departments are doing or not doing.

The most atrocious result of this development can be summarized as “the internet is dangerous”. For fear of threads from the internet, while more and more company infrastructure is needlessly being exposed to it, the use of the internet is increasingly limited for staff. This has resulted in engineers and scientists who do not even know how to properly use an online search engine anymore. One can make a living by explaining how to use Google for finding actual, meaningful technical information. Yet the modern internet is the place where open source and openly available knowledge resides. No access to knowledge results in a lack of (continued) education and little awareness for alternative paths to the established yet in many cases inferior proprietary products used. In less extreme terms, proprietary products and / or their manufacturers might have certifications that competing open source projects do not have but which are required by compliance rules. It almost goes without saying that many of those certifications are practically worthless.

License compatibility

As detailed earlier, there are different types of open source licenses, some of which carry certain risks when it comes to own IP. Those licenses and their consequences are a widely misunderstood issue when using and / or incorporating open source into commercial products. This is usually cited as a reason for not using or incorporating open source at all. A simple read of the licenses and the many guidelines provided by well-known non-profits in the field would clear many of those misunderstandings, which is yet again a question of (access to) education and financial resources.

Actual vs. Assumed Regulatory Constraints

The probably most significant issue in the space industry is actual and perceived regulatory constraints. Blocking regulatory constraints are nowadays typically cited when it comes for instance to personal data that is currently unavailable but desired, ideally opt-out, from people free of charge, for training “AI” (machine learning) models. This is by all accounts pure gas lighting and has nothing to do with the problem at hand or a lack of innovation. Other, more pressing reasons exist that hamper innovation and growth.

For the space industry, it is first and foremost export regulations which are important to understand. Open source is in many cases not touched for fear of violating those regulations, but there are several aspects that need to be taken apart. First, current regulations are rarely read and understood in detail, so organizations limit themselves more than actually needed to “be on the safe side”.

Second, some regulations are legitimately outdated or meaningless. Plenty of technologies for instance in the fields of guidance or sensors do exist as open source, available globally on the internet. Yet interacting with those projects or developing a similar open source project might actually not be allowed under current export regulations. This is predominantly a problem in the US, but to a lesser extend in view of contemporary sanctions towards the East also a European topic. IP and technological leadership shall be protected from enemy powers. Protection only makes sense of there is some kind of noteworthy leadership, which especially in Europe is openly vanishing. Protection also assumes that there are practical and technical means allowing effective protection. Citing the experience on compliance stated earlier and the fact that everything is connected to the internet, protection really is not an argument thanks to lack of means. It would be easier to protect leadership through radical openness accompanied by a substantial lead in education and skill. The third aspect is again more of a European problem, the adherence to regulations which do not apply to a given organization in its surrounding jurisdiction. For example, despite not being operating in or selling to the US, many European companies tend to follow many provisions of US regulations, namely EAR and ITAR. The commonly cited reason is that, one day, one might actually want to do business in the US. Allegorical, it is literally the hope of Mr Musk one day knocking on their door. In contrast, one could say that Europe does not have anything that even remotely matches the operation and technology of SpaceX and that we, the Europeans, should focus on our own market as opposed to hoping for bread crumbs from overseas, but this is only the author’s personal opinion.

Actual Benefits of Open Source

Significant and straight forward: Vendor locks can be avoided, both caused by proprietary software and SaaS. Sudden and / or extreme changes in license cost and conditions are not a risk anymore. The infamous practice of “enshittification” has, through online CAD and other applications, entered the space sector which is naturally B2B rather than an end-consumer market – which can easily be avoided by using open source instead. Open source also implies open standards, i.e. open file formats and protocols, limiting the power of companies in this field. It also limits the ability of larger organizations to misuse standardization and certification against its competitors, as Microsoft’s attempt at ISO, see here and here, infamously illustrates. Open source can, by definition, not be discontinued. Open source means low barrier to entry for new players, even the literal “students in the basement”. This has been true throughout the history of software but is a phenomenon that is still mostly missing from the space industry. Open source, if done right first and foremost from an economic point of view, results in maintainable, long-living software of comparatively high quality.

“Sanctions might be coming to your country next” as many people in the middle east are used to and the Russians have found out the hard way since 2022. Locally installed software such as CAD) as well as cloud offerings and online services such as Github have had their fair share of infamous stories relating to sanctions. Open source is a way to be independent of those. Recent years have seen a drastic increase in the use of sanctions, tariffs and trade restrictions, which is why recent examples should be understood as a warning sign to those who currently still feel unaffected. Noteworthy, this is also an issue with software running locally if “Always-on DRM” is employed, which is increasingly becoming the norm.

Case Studies

Operating System Kernels

The Linux Kernel project is the poster-child of open source, in many ways. It has at any given time 2k to 3k active developers and an estimated value in the single digit billions of USD. It is now the globally most widely used operating system kernel. Darwin, the core of MacOS is open source, though publication sized in 2023. Many less significant operating system kernels are open source, first and foremost from the BSD family of operating systems, but also several embedded and real-time systems. Even Microsoft has begun to open-source Windows on a component-level, though not the kernel itself yet. Microsoft also began contributing to Linux in 2009. Through Azure cloud, it is now running and investing more into Linux than Windows.

The ML/AI story

The area of ML / AI is famous for its history if rapid advances followed by long periods of silence, which are referred to as “AI winters”. The last AI winter really ended when Google made Tensorflow 1.0, a machine learning software library, open source in summer 2016 after initial unstable open source releases in late 2015, boosting research in this field dramatically. If it was not for open source and low barrier to entry, ML / AI would not be where it is today. Tensorflow was certainly not the first open source project in this field, but it was technologically advanced, flexible, relatively easy to use and could make use of many types of hardware for accelerating computations. Its open source nature also meant that researchers in the field, even from competing companies, started contributing to it directly.

Cloud Computing

Cloud providers are driven by open source, literally. It provides the starting points for their software stacks. For them, it has generated massive amounts of wealth. While the flexibility to scale up and down quickly has caused a migration of many services into cloud infrastructure, it has more and more become a hype that has increased cost for customers rather than saving them. Cloud is therefore an interesting example of what open source can do for a few if the majority keeps ignoring it.

The GIS ecosystem

The GIS ecosystem is a classic example of a duopoly of two rather dominant players, QGIS as an open source project vs. ESRI ArcGIS as a proprietary product. It is a case of a relatively healthy competition, which has resulted in technological advances on both sides and offers users to go down both paths depending on their needs. Both tools can exchange data although there are occasional attempts from the proprietary side to introduce new proprietary data formats or to make it harder to read existing ones.

The CAD ecosystem

Although there are noteworthy tools on both, the proprietary and the open source side, when it comes to CAD, it is not a classic duopoly. FreeCAD is properly the best tool in the open source space, but it is nowhere near commercial tools. Lately, SaaS solutions have gained more and more momentum. There is no real open source ecosystem for business use cases.

The R&D computation ecosystem

Tools, software libraries and programming language implementations used for data analysis, modeling and simulation have seen an interesting evolution in recent years. Proprietary language ecosystems like IDL and Matlab were almost evaporated by Python, Julia and R as well as their ecosystems in many fields. The sheer flexibility and versatility of Python especially could not be matched by its proprietary counterparts. Interestingly, Matlab is still relevant thanks to LabView, for which there is no counterpart in the open source ecosystem.

Governments

A number of government institutions have realized the befits of open source, mostly for office and communication applications. The LiMux project of the city of Munich, Germany, and its story with respect to Microsoft’s lobbying efforts is an interesting one. Other noteworthy examples include the Italian military, see here and here, the French National Gendarmerie, sere here and here, the French Ministry of Foreign Affairs, the French Ministry of Agriculture and more. There are sizable regional efforts in Spanish health care organizations. A list of known LibreOffice migrations gives a good additional overview. Open standards and protocols, lately Matrix for chats, have resulted in an influx of public funding into related open source projects and the development of government clients, partially also open source.

The state of open source for space – potential?

From observation, many companies keep reinventing the wheel for many common applications. Proprietary software is dominant. Though, there is open source, commonly pointed to almost as an excuse, but it plays little role. A search on Github reveals space-related projects in the tens of thousands but looking at their use, many are hobby or niche projects. Few are serious and / or have noteworthy commercial backing.

STK is a classic example for mission-critical proprietary software. While many of its functionalities exist in open source libraries, there is no desktop application matching it even remotely.

ESA

ESA’s own Gitlab is theoretically accessible at gitlab.esa.int. There are little activities and little noteworthy software hosted. It is not really open. Its future path is unclear after several changes in policy and moves. ESA’s public Github repos show little support once they are published and funding has run out. Projects there see little use. The dominating repository and a beacon of light for many years has been the “pagmo” project with around 50 contributors and a lot of activity, a library for parallel computations of optimization tasks. ESA’s presence on public Gitlab, another platform similar to Github, is insignificant. Many separate deployments of the Gitlab software on ESA domains as well as related outreach efforts exist, with the latter efforts usually dying after funding runs out, e.g. the Space CODEV Platform.

ESA maintains lists of open source software, for instance for developing space downstream applications. ESA also has a dedicated open source policy rooted in the ESA contracts. The distribution of open source is under this document considered a risk that must be carefully weight. Depending on the use case, a release or licensing shall be restricted to entities in ESA member states and / or require approval by committees, making effective open source development hard if not practically impossible. Professional observations confirm this assertion. Further emphasis is put on exposing IP and limited export control capabilities when contributing to existing open source projects not directly controlled by ESA. Besides, ESA has developed and enforced its own set of open source licenses, making the licensing landscape even more complicated. ESA has many years of history of funding open source projects, mainly through the LibreSpace foundation. While some of those projects are interesting, for many reasons virtually none of them gained any noteworthy momentum independently of ESA funding.

NASA

A widely regarded presentation at FosDEM 2023 by Steve Crawford, the Science Data Officer for the Science Mission Directorate of NASA, provides a good and recent overview. Similarly to ESA, there is a scattered landscape. A central overview is available on a dedicated website, see here and here. Again similar to ESA, there is a presence on Github with few noteworthy projects. Countless separate deployments of Gitlab software exist. JPL is a bit more active on Github. NASA in general has long maintained open source contributions, dating back to the heydays of older platforms in the field such as SourceForge. In recent years, NASA openly awarded 1.4 million USD to 15 teams developing new technologies that advance and streamline the open sharing of scientific information through HPOSS awards. NASA’s Open-Source Science Initiative is another notable effort. While a lot of software has been developed or significantly advanced by NASA staff over the decades and made freely available, its actual availability has usually been drastically contained by export control. Software in the field of astrodynamics is a good example.

Transitioning to Open Source – Summary

Flagship projects in the space industry are needed which work independently of government subsidies.

Open source always comes with an initial investment plus maintenance cost which can be shared and offset quickly if a critical mass within the industry agrees to solve a certain use case. A corresponding dialogue is needed between industry players. People experienced in open source must be heard and listened to. An overall investment in education, for both the students of today but also for the already employed workforce and management, is critically needed.

Knowledge that is practically already out in the open does not need protection can be the foundation for noteworthy and actually useful industry-grade open source initiatives. Beyond that, a careful change of regulations should be approached. Protecting our businesses through protecting the little IP we might still have left leading in our field or, worse, protecting our business through locking us and our customers into mediocre proprietary and / or domestic solutions is not a sustainable business model.

The usual time for transitioning a selected technology to open source is about two years for both actual migration and offsetting cost. There are proven strategies in other industries which can serves as examples of how to move forward.

‹‹‹ Blog Overview