A few days ago I attended to the first Open Source Cubesat Workshop at the European Space Operations Center. It was a great event -I'm sure it will be the first of many- where I got a chance to meet a lot of interesting people working on great projects.

During these two days, I noticed that quite a few of the discussions were related to some extent to standardization. Many people were using open source as a means of standardizing different parts of a cubesat mission.

It makes sense. The reason why the cubesat market is growing so fast is because they allow us to reach space faster and cheaper. For instance, if someone wants to launch a nanosatellite designing the deployer and integrating with the launcher is usually out of the equation.

In my opinion, the reason why everyone is worried about this topic is because having any industry relying on some common interfaces and protocols can reduce a lot development costs and the time to market. This is particularly true for the space industry, in which no matter how small the project is,huge investments are usually involved.

Reducing cost to space

After some thinking on this topic, I've come to the conclusion that the questions we should be asking ourselves are: How can cubesat projects reach the space faster and cheaper? How can these and other spacecrafts generate revenue or valuable data while reducing the required investment?

During the workshop we've had some interesting discussions around this and I've realized that there are some things we can do to spend less money on space projects without increasing the risk of failure.

First of all, I think that the bus of a cubesat has to become a commodity. When we want to build a website we don't write our own web server and the whole stack under it, there are solutions for that in the market (the most extended ones are open source). If we compare space projects with the OSI model, most of the them are focused on the application layer (payload). The goal of the other layers (bus) is just to serve the application.

The best way to achieve this, is to have reliable open source buses. This would reduce the price while allowing anyone to easily improve it and adapt it to specific mission requirements. This doesn't mean innovation will stop on the platform subsystems, but let's be honest, I'm sure that nowadays, most of the projects are reinventing the wheel developing EPSs, TT&Cs… We shouldn't forget that the payload is what pays for the satellite.

"The bus of a cubesat has to become a commodity"

An open bus would reduce development time, but yet some missions might need to validate certain subsystems under highly realistic conditions. Does this mean the subsystems have to be sent into space? For instance, would it be possible to test how to land on Mars without having spent hundreds of millions of Euros on it? What has ESA learnt from Schiaparelli? What would they do differently?

This is where simulation comes in. Clearly this is a rapidly evolving field. Someone said an interesting sentence: up until now, CAD (Computer Aided Design) tools should have been called CAV (Computer Aided Visualization). However, we are starting to see solutions in the market to really help us design and predict how machines will work in real environments.

Despite of this evolution, simulation tools are in my opinion mainly useful when the requirements are clear, but what if a company is just looking for market fit and it really needs to have something orbiting around? In this case, the answer is in the methodologies.

More agile methodologies are highly demanded by the industry. A private company can't afford spending months writing documents just to start a project. That means no revenue during that stage. Also, in some missions the documents are inherited from previous similar missions which may lead to inconsistencies and errors. This is a problem that ESA is starting to be aware of. Space has evolved and so need the methodologies.

To sum up: there are at least three things we can do to reduce the cost of reaching the space:

1. Think of cubesats' platforms as a commodity.
2. Rely on simulation tools.
3. Use more agile methodologies.

I would love to hear what do you think about this. As a hardware guy, I'm really interested on this topic. Is there something else we can do to generate revenue faster and taking less risks?

Thanks to Artur Scholz, Red Boumghar and the Libre Space Foundation for making this workshop possible. Also big thanks to all the sponsors, specially to ESA. I hope this event has inspired someone inside the Agency to realize that the Open Community is growing fast and as a public agency it's important to irrigate it. I wish to see open.esa.int full of useful information soon. See you next year!