Надо сказать, что не смотря на то, что все GPL-проекты равны, некоторые из них ровнее. Иначе говоря, GPL-проекты могут быть более открытыми и менее открытыми. И OpenBTS является как раз менее открытым проектом. Как же так, ведь в лицензии написано, что все исходные коды должны быть доступны? Да, доступны, но только когда вы начинаете распространять продукт на основе этих исходны кодов. Т.е. пока вы ведёте разработку, вы можете держать свои изменения при себе и никому не показывать. Или показывать, но ограниченно. И это будет в рамках лицензии. Такие условия логичны, но иногда могут приводить к странным последствиям.
Если вы заглянете на страницу закачек OpenBTS, то найдёте там версию 1.6 (New Iberia) — это версия, которую Kestrel SP выпустили в апреле этого года, то есть почти полгода назад. Из официального блога проекта можно узнать, что на Burning Man 2009 они использовали версию 2.5, которая у них хорошо работала и которую они за время фестиваля хорошенько отладили. Более того, на официальной вики проекта приводится список совместимости с телефонами для версии 2.4.
Где же эти версии 2.4 и 2.5? А они доступны только «активным разработчикам» из сообщества и коммерческим клиентам Kestrel SP. Почему так? Дэвид объясняет — компании требуются средства на существование и клиенты готовы платить за то, чтобы первыми получить доступ к той или иной функциональности. Активные разработчики же могут быть приравнены к клиентам, потому что экономят время и деньги компании. Кроме того, — Дэвид об этом не говорит, но это очевидно, — таким образом несколько затрудняется жизнь тем, кто хочет взять софт на халяву и продать под своим брендом. В принципе, всё выглядит достаточно логично, если бы не несколько «но». Допустим, человек начинает осваиваться в проекте, делает первые тесты и тут же находит и первые баги в проекте. У него есть варианты — (1) игнорировать баг, если он не сильно мешает, (2) сообщить о нём в рассылку или в трекер проекта и (3) исправить его и отправить в проект патч. Для проекта наиболее полезен вариант (3) — проект совершенно бесплатно получает исправление, до которого у основных разработчиков не дошли руки или который редко встречается. От вариантов (1) и (2) проекту по большому счёту ни холодно, ни жарко. Но вспомним, что человек работает со старой версией и знает об этом. И в этом случае у него очень слабая мотивация исправлять найденный баг — раз разработчики пишут, что у них всё прекрасно работает, значит они, наверное, его уже исправили и можно просто подождать, пока они не выложат в общий доступ новую версию. Не делать же, действительно, двойную работу, которая будет потом никому не нужна — разработчики наверняка предпочтут своё исправление бага, чем какое-то стороннее. В итоге, многие ошибки, которые могли бы быть исправлены силами сообщества, разработчики вынуждены исправлять сами, тратя своё время (и деньги).
Есть ещё и другая сторона проблемы. Получается, что сообществу дают версию, в которая заведомо хуже работает, и при этом говорят, что всё работает отлично (но в новой версии!). Люди ставят эту версию, пытаются заставить её работать, и у них это не очень получается, они тратят на это большое количество времени и сил, в попытках понять, что же не так — ведь писали, что всё работает. Потом им говорят: «Вот вам версия поновее, мы её скоро выложим в открытый доступ, она может будет лучше работать». Они пробуют — и всё действительно начинает лучше работать. Как после этого чувствуют себя эти люди? Так, как будто их кинули. Не самое полезное ощущение, когда работаешь с open-source проектом.
PS Да, мы получили от Дэвида на тестирование версии 2.4 и 2.5. Первые результаты обнадёживают — теперь все наши тестовые Siemens'ы спокойно подключаются и работают. Более подробно о новых результатах тестирования — в следующих постах.
Вот именно поэтому мне перестала быть интересна разработка OpenBTS. И я сконцентрировался на спектроанализаторе... Помню как начинал фиксить баги в 1.2 версии... Половину пофиксил — оно стало работать. Написал Дэвиду — он меня поздравил и сказал, что они уже все эти баги пофиксили и вручил мне версию 1.6 (в мае было дело). Отлично, зачем я старался?
Я тестил OpenBTS с кучей мобилок (как американских, так и европейских). У меня работали все старые Ericsson/SE (новые плохо работали — срывали разговор — им дрифт частоты не нравился). Nokia S40 работали без проблем. S60 приходилось натравливать на ARFCN. iPhone работали без проблем. Моторола вообще ни одна не завелась.
А вообще, openbts — конечно штука интересная, но рыночные перспективы туманны (слишком много закрытых патентов, слишком много проблем). Пока не будет нормальной авторизации — её нельзя продавать... Да и есть проблема с легализацией установки...
В мае они ещё были под запретом распространения и их можно было понять. Но теперь, когда с них сняли запрет, я его не очень понимаю. О чём и напоминаю ему при каждой возможности. Может через некоторое время может подействует...
Про дрифт частоты. А какой источник часов использовался — родной USRP'ный? С нашим новым источником часов обрывов связи мы не наблюдали вроде бы.
Про рыночные перспективы согласен. Но так же не могу не отметить, что все эти проблемы решаемы. А если получится довести разработку до реального применения — её эффект будет значительным. Просто в социальном плане и в плане изменения отношения к системам связи как к чему-то, что доступно только когорте избранных.
PS А что за спектроанализатор — вdvanced версия usrp_fft.py?
Да, родной. Вы, кстати, одну из моих плат купили.
Да, анализатор именно на базе этого скрипта... может даже продать местному опсосу получится).
А в качестве фемтосот и вообще новой концепции построения сети сотовой связи (на базе IP), захвата рынка «another billion» — мне нравятся разработки PicoChip.
Я помню ))
Потому и спросил, что она немодифицированая была.
Open-source версия будет? После продажи опсосу, конечно ;)
Кстати, AirProbe — тоже забавная игрушка. Особенно в качестве утилиты для отладки OpenBTS :)
PicoChip — это замечательно, но они работают только с очень крупными заказчиками. Кроме того, для GSM совершенно не обязательна такая бешеная производительность, как для 4G, для которых они и создавались. Да и фемтосоты — это не «another billion», а всё тот же, что в офисах сидит и в смартфоны играет. Не думаю, что в ближайшие лет десять 4G телефоны будут дешевле старых добрых GSM.
I apologize for not posting in Russian.
Another reason that we allow the public distribution to lag the private one by a few months is that some of the clients who pay for this work request that it not be released publicly until after a certain time has passed. There are some specific cases of that in 2.4. (BTW, we *will* release 2.4 onto GNU Radio as soon as we have had a chance to test the merged code.) There's no real business case for telling a commercial customer, \You pay for the code so I can give it away for free, even to your competitors, before it's even finished.\ So you offer delayed public release: \You pay for the code and I promise not to give it away for free until your business plan is more mature.\
I realize that this policy annoys many potential open source developers, but this is how a lot of work got funded and how a lot of it is likely to be funded in the future. I also realize that we may need to find a better way to manage this policy now that the lawsuit is over. I am open to suggestions.
Also, anyone who is serious about becoming an active OpenBTS developer is encouraged to contact me for more recent code, or even for direct access to our SVN server. There are few such active developers at this time and I am glad to accommodate them.
Glad to see you here, David! No problems with English posting.
You've posted that John Gilmore sponsoured SMS implementation which is the main new feature of 2.x releases. Was it he who denied to open the codes immediately? I don't believe he did this.
My strong belief is that main development branch (i.e. trunk) *must* be in free access. It's ok to develop some features in a «delayed open» manner, but they should be worked on in a separate (private) branch. Then, all bug-fixes should land trunk first and then regularly merged to feature-branch regularly. And when client is satisfied and is going to deliver his product, you merge feature-branch back to main. Even svn provides means for regular merging, not to say about DCVSs (like Mercurial/hg or awkward git). Yes, it will add some work on merging, but I do believe that long-term outcome of this openness is far more valuable.
Интересно, мне одному по этому поводу вспоминается методика, по которой Том Сойер красил забор? =)
Если на то пошло, то весь FOSS — один большой забор.
Да, но FOSS — это таки забор колхозный =)