As the topic has been raised on twitter, I
thought I might share a bit of insight into the funding of the Osmocom
Cellular Infrastructure Projects.
Keep in mind: Osmocom is a much larger umbrella project, and beyond
the Networks-side cellular stack is home many different community-based
projects around open source mobile communications. All of those have
started more or less as just for fun projects, nothing serious,
just a hobby
The projects implementing the network-side protocol stacks and network
elements of GSM/GPRS/EGPRS/UMTS cellular networks are somewhat the
exception to that, as they have evolved to some extent professionalized.
We call those projects collectively the Cellular Infrastructure
projects inside Osmocom. This post is about that part of Osmocom only
From late 2008 through 2009, People like Holger and I were working on
bs11-abis and later OpenBSC only in our spare time. The name Osmocom
didn't even exist back then. There was a strong technical community with
contributions from Sylvain Munaut, Andreas Eversberg, Daniel Willmann,
Jan Luebbe and a few others. None of this would have been possible if
it wasn't for all the help we got from Dieter Spaar with the BS-11 .
We all had our dayjob in other places, and OpenBSC work was really
just a hobby. People were working on it, because it was where no
FOSS hacker has gone before. It was cool. It was a big and pleasant
challenge to enter the closed telecom space as pure autodidacts.
Holger and I were doing freelance contract development work on Open
Source projects for many years before. I was mostly doing Linux related
contracting, while Holger has been active in all kinds of areas
throughout the FOSS software stack.
In 2010, Holger and I saw some first interest by companies into OpenBSC,
including Netzing AG and On-Waves ehf. So we were able to spend at
least some of our paid time on OpenBSC/Osmocom related contract work,
and were thus able to do less other work. We also continued to spend
tons of spare time in bringing Osmocom forward. Also, the amount of
contract work we did was only a fraction of the many more hours of spare
In 2011, Holger and I decided to start the company sysmocom in order to generate more funding for the
Osmocom GSM projects by means of financing software development by
product sales. So rather than doing freelance work for companies who
bought their BTS hardware from other places (and spent huge amounts of
cash on that), we decided that we wanted to be a full solution
supplier, who can offer a complete product based on all hardware and
software required to run small GSM networks.
The only problem is: We still needed an actual BTS for that. Through
some reverse engineering of existing products we figured out who one of
the ODM suppliers for the hardware + PHY layer was, and decided to
develop the OsmoBTS software to
do so. We inherited some of the early code from work done by Andreas
Eversberg on the jolly/bts branch of OsmocomBB (thanks), but much was
missing at the time.
What follows was Holger and me working several years for free , without
any salary, in order to complete the OsmoBTS software, build an embedded
Linux distribution around it based on OE/poky, write documentation, etc.
and complete the first sysmocom product: The
We did that not because we want to get rich, or because we want to run a
business. We did it simply because we saw an opportunity to generate
funding for the Osmocom projects and make them more sustainable and
successful. And because we believe there is a big, gaping, huge vacuum
in terms of absence of FOSS in the cellular telecom sphere.
Funding by means of R&D contracts
The probably best and most welcome method of funding Osmocom related
work is by means of R&D projects in which a customer funds our work to
extend the Osmocom GSM stack in one particular area where he has a
particular need that the existing code cannot fulfill yet.
This kind of project is the ideal match, as it shows where the true
strength of FOSS is: Each of those customers did not have to fund the
development of a GSM stack from scratch. Rather, they only had to fund
those bits that were missing for their particular application.
Our reference for this is and has been On-Waves, who have been funding
development of their required features (and bug fixing etc.) since 2010.
We've of course had many other projects from a variety of customers over
over the years. Last, but not least, we had a customer who willingly
co-funded (together with funds from NLnet foundation and lots of unpaid
effort by sysmocom) the 3G/3.5G support in the Osmocom stack.
The problem here is:
- we have not been able to secure anywhere nearly as many of those R&D
projects within the cellular industry, despite believing we have a
very good foundation upon which we can built. I've been writing many
exciting technical project proposals
- you almost exclusively get funding only for new features. But it's
very hard to get funding for the core maintenance work. The
bug-fixing, code review, code refactoring, testing, etc.
So as a result, the profit margin you have on selling R&D projects is
basically used to (do a bad job of) fund those bits and pieces that
nobody wants to pay for.
Funding by means of customer support
There is a way to generate funding for development by providing support
services. We've had some success with this, but primarily alongside the
actual hardware/system sales - not so much in terms of pure
Also, providing support services from a R&D company means:
- either you distract your developers by handling support inquiries.
This means they will have less time to work on actual code, and likely
get side tracked by too many issues that make it hard to focus
- or you have to hire separate support staff. This of course means that
the size of the support business has to be sufficiently large to not
only cover the cots of hiring + training support staff, but also still
generate funding for the actual software R&D.
We've tried shortly with the second option, but fallen back to the first
for now. There's simply not sufficient user/admin type support business
to rectify dedicated staff for that.
Funding by means of cross-subsizing from other business areas
sysmocom also started to do some non-Osmocom projects in order to
generate revenue that we can feed again into Osmocom projects. I'm not
at liberty to discuss them in detail, but basically we've been doing
pretty much anything from
- custom embedded Linux board designs
- M2M devices with GSM modems
- consulting gigs
- public tendered research projects
Profits from all those areas went again into Osmocom development.
Last, but not least, we also operate the sysmocom webshop. The profit we make on those products
also is again immediately re-invested into Osmocom development.
Funding by grants
We've had some success in securing funding from NLnet Foundation for specific features. While this is useful, the
size of their projects grants of up to EUR 30k is not a good fit for the
scale of the tasks we have at hand inside Osmocom. You may think that's
a considerable amount of money? Well, that translates to 2-3 man-months
of work at a bare cost-covering rate. At a team size of 6 developers,
you would theoretically have churned through that in two weeks. Also,
their focus is (understandably) on Internet and IT security, and not so
much cellular communications.
There are of course other options for grants, such as government
research grants and the like. However, they require long-term planning,
they require you to match (i.e. pay yourself) a significant portion,
and basically mandate that you hire one extra person for doing all the
required paperwork and reporting. So all in all, not a particularly
attractive option for a very small company consisting of die hard engineers.
Funding by more BTS ports
At sysmocom, we've been doing some ports of the OsmoBTS + OsmoPCU
software to other hardware, and supporting those other BTS vendors with
porting, R&D and support services.
If sysmocom was a classic BTS vendor, we would not help our
"competition". However, we are not. sysmocom exists to help Osmocom,
and we strongly believe in open systems and architectures, without a
single point of failure, a single supplier for any component or any type
of vendor lock-in.
So we happily help third parties to get Osmocom running on their
hardware, either with a proprietary PHY or with OsmoTRX.
However, we expect that those BTS vendors also understand their
responsibility to share the development and maintenance effort of the
stack. Preferably by dedicating some of their own staff to work in
the Osmocom community. Alternatively, sysmocom can perform that work as
paid service. But that's a double-edged sword: We don't want to be a
single point of failure.
State of funding
We're making some progress in securing funding from players we cannot
name during recent years. We're also making occasional progress in
convincing BTS suppliers to chip in their share. Unfortunately there
are more who don't live up to their responsibility than those who do.
I might start calling them out by name one day. The wider community and
the public actually deserves to know who plays by FOSS rules and who
doesn't. That's not shaming, it's just stating bare facts.
Which brings us to:
- sysmocom is in an office that's actually too small for the team,
equipment and stock. But we certainly cannot afford more space.
- we cannot pay our employees what they could earn working at similar
positions in other companies. So working at sysmocom requires
dedication to the cause :)
- Holger and I have invested way more time than we have ever paid us,
even more so considering the opportunity cost of what we would have
earned if we'd continued our freelance Open Source hacker path
- we're [just barely] managing to pay for 6 developers dedicated to
Osmocom development on our payroll based on the various funding
sources indicated above
Nevertheless, I doubt that any such a small team has ever implemented an
end-to-end GSM/GPRS/EGPRS network from RAN to Core at
comparative feature set. My deepest respects to everyone involved. The
big task now is to make it sustainable.
So as you can see, there's quite a bit of funding around. However, it
always falls short of what's needed to implement all parts properly, and
even not quite sufficient to keep maintaining the status quo in a proper
and tested way. That can often be frustrating (mostly to us but
sometimes also to users who run into regressions and oter bugs).
There's so much more potential. So many things we wanted to add or
clean up for a long time, but too little people interested in joining
in, helping out - financially or by writing code.
On thing that is often a challenge when dealing with traditional
customers: We are not developing a product and then selling a ready-made
product. In fact, in FOSS this would be more or less suicidal: We'd
have to invest man-years upfront, but then once it is finished, everyone
can use it without having to partake in that investment.
So instead, the FOSS model requires the customers/users to chip in
early during the R&D phase, in order to then subsequently harvest the
fruits of that.
I think the lack of a FOSS mindset across the cellular / telecom
industry is the biggest constraining factor here. I've seen that some
20-15 years ago in the Linux world. Trust me, it takes a lot of
dedication to the cause to endure this lack of comprehension so many