[Openbts-discuss] Any plan to fork OpenBTS and/or merge with Osmocom code?

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

David A. Burgess dburgess at jcis.net
Sun Apr 10 05:33:20 UTC 2011


Fabio -

On Apr 8, 2011, at 11:37 PM, Fabio Pietrosanti (naif) wrote:

> Hi all,
> 
> this email don't want to be a provocative email but just an opinion
> related to the creation of value for GSM TLC stack into the opensource
> environment.
> 
> As we know currently there are several different projects growing into
> the GSM (then tetra and in future 3G?) opensource ecosystem.
> 
> The first "pratical" base has been OpenBTS as a simplified GSM um
> interface for VoIP.
> 
> The second major implementations was around the osmocom project that
> build-up a complete and well designed GSM stack with all the modular
> interfaces and protocols for communications between BTS and BSC, with
> MSC, HLR, GGSN, SGSN and major GSM network components.

I think OpenBTS and openbsc were released at very nearly the same time, although neither was aware of the other at the time.

> 
> Additionally, if i understood correctly osmocom is much more advanced
> with broad scope and better design than OpenBTS.

That depends a great deal on what you are trying to achieve.  The two projects are very different in their goals and their implementation approaches.  For many applications, the removal of the GSM core network is a great advantage.  Also, the OpenBTS approach has more in common with 4G IMS than with 2G legacy networks, so I'm not sure what you mean by "more advanced".

> 
> It seems to me that OpenBTS it's almost stalled due to the "commercial
> fork" of the OpenSource project and only fairwaves is contributing to
> the opensource branch.
> 
> I personally really dislike the "Commercial fork" approach where the
> community is used only in the early phase of the project to improve it
> and from a certain point the community doesn't get almost any added value.
> I like much more the dual-licensed approach like AGPL/Commercial (like
> http://pjsip.org) where all the value of the code is publicly released.

We created a commercial fork because we've found that a pure dual-license/non-forked approach is not commercially viable in many of the markets where OpenBTS is being used. (In fact nearly all of the current public GSM code was written or paid for by just two people.  We have since replaced or relicensed any previous GPL components in the SDR and GSM stack, allowing us to fork and license OpenBTS however we wish.)  

There are several reasons for the decision to fork, including government indemnifications for copyright violations by government contractors, suspected violations by commercial interests in inaccessible jurisdictions and specific contractual requirements from project funders to not make a public release of their features.  I still personally fully support the GPL and would have preferred a pure dual-license approach, however it simply was not working for the project.  The pure public release model was not generating enough income to justify our work and we've found that it was incompatible with our long-term business plan, which is to sell complete GSM/VoIP networks, hardware and software, to commercial customers.  Our goal is to provide GSM capabilities with carrier-grade quality to as many people as possible.  The amount of our time and money we've invested into the project would surprise most of you and the risks associated with it, professional, personal and financial, have been significant.

All that said, we are committed to continue to support the public release of OpenBTS.  I would also like to see it become more of a true "community" effort, rather than a small set of people giving their work away to everyone else for free.  I realize that will require more active leadership than what has been typical so far.  We are committed to organizing the public side of the project and we will are happy to answer any questions clarifying the relationship between the public and commercial releases.


> 
> However, my post was related to a question:
> 
> - How complex would be, leveraging existing public OpenBTS code, to
> integrate into the Osmocom project?
> 
> I mean, having a sort of lightweight BTS component speaking A-Bis over
> IP to OpenBSC like the cheap nano ip.access BTS does.

It would not be difficult to replace most of the OpenBTS control layer with an Abis interface.  As Harald Welte described in his own response to this message, we have considered this before, Harald and I have discussed it, and Harald has even done some work in that direction. 

> For what i read now Osmocom have 2 software BTS (Osmo-BTS and Soft-BTS),
> communicating with the A-BIS over IP interface to OpenBSC:
> http://lists.gnumonks.org/pipermail/openbsc/2011-March/002529.html
> http://lists.gnumonks.org/pipermail/openbsc/2010-April/001508.html
> 
> I've read that only a lot of time ago (2009) there was a discussion
> about OpenBTS to OpenBSC integration:
> http://lists.gnumonks.org/pipermail/openbsc/2009-October/000955.html

> 
> At the current stage of development (2011), with Osmocom finally getting
> a Software-BTS part communicating to the Software-BSC side, how really
> complex it would be to integrate the GSM-um related part of OpenBTS into
> the project?
> 


From the OpenBTS point of view, Abis is interesting only as a mechanism to integrate OpenBTS units into a "legacy" GSM network, and even then only in odd circumstances where other integration methods are not applicable.  It is not a preferred mode of operation and thus we  do not see the current lack of Abis as a serious shortcoming or design flaw.  (In fact, the lack of Abis was a deliberate design decision.  Part of the point of OpenBTS was to eliminate many of the things that openbsc is building.)

> With that approach the 'GSM-um' interface would be a very simplified
> module of the overall system and osmocom would completely replace
> OpenBTS all-in-one project.

I don't know how well these projects would merge together.  The implementation styles are very different.  It would also be difficult to find someone to manage such a thing, especially since none of the lead developers on either project seems to have interest in doing that.

> 
> Am i right?
> 
> -naif
> 
> p.s. Sorry for the cross-posting, i just wanted to explain the idea and
> get the communities feedbacks to understand 'at which point' we are in
> order to think 'what would be required to be done' to achieve that goal.


Well, I just cross-posted my reply.  So there. :P

-- David



More information about the OpenBSC mailing list