In December last year I wrote a post about VESNA and how it will be open sourced soon. However now, almost 8 months later, I can't say that promise has been fulfilled. Hardware design still isn't public and, apart from some of my isolated experiments, there isn't currently much to show on the software side either. Considering the amount of feedback I got about that blog post I feel I need to give a follow-up on the status of open sourcing VESNA.
During this whole endeavor I've learned a lot regarding the process of releasing to the public a non-trivial piece of work that has been developed behind closed doors for a significant amount of time in a large organization. On the web you constantly see discussions on how this or that company should release some piece of software under an open source license (famous Nvidia drivers come to mind). Once you actually attempt to do something like that, even on a much smaller scale, it becomes obvious just how naive such calls are.
First of all, there are strictly legal issues. For software that you develop for in-house use and only share with some partners you simply don't need to be that careful about what foreign code you incorporate into your product. This is especially problematic in embedded programming, where a lot of hardware manufacturers will give you documentation, libraries or examples to built upon that are attached to scary looking non-disclosure agreements, re-distribution licenses and so on. Even if in my opinion many of these are not actually enforceable, you can't ignore them without a through review and (expensive) legal help.
More specifically, almost all of existing software for VESNA is based on the proprietary STM32 firmware library that has a scary enough license to motivate people to make a free replacement for it. And no, I can't imagine moving everything to libopencm3 with limited resources we have. I'm personally guilty of committing code to the same repository that said "Under no circumstances is this software to be exposed to or placed under an Open Source License of any type" in the header. When you have project deadlines looming, clean room design isn't something that you want to mention at a meeting. While I took good care of adding warnings about it in appropriate places, I can't help myself wondering how many similar gems we have in the code that we don't even know about.
Hardware designs themselves can have similar issues. Chip manufacturers sometimes won't let you release a schematic of a circuit that uses their products, as silly as that sounds. Even though to my knowledge only one part of VESNA might potentially have that problem (my UHF spectrum sensing receiver of all things), these are even harder to track. The fact that Open hardware licenses themselves are in their infancy makes it even harder to make any solid decision regarding hardware designs without dedicating unreasonable amounts of time to it.
Then there are also cultural problems. Some of the projects here at the Institute have built upon open-source software, like Contiki. But that was done in isolation from the up-stream project. This means that after years of separate development the upstream has moved on and the private fork has accumulated a large number of changes. This is a nightmare if you want to contribute changes back to the community. While I may argue that it's reasonable to expect small drive-by contributions to be accepted upstream, I certainly can't recommend stopping by a mailing list and dropping a 50.000 line patch at the unsuspecting developers.
So, while starting off an open-source project from zero might be relatively effortless, open-sourcing something requires a lot of dedication and time from everyone working on the project. Unfortunately these are hard to justify when you have ongoing projects with their own deadlines and demands for attention. You need a well thought-out strategy and at least some solid ideas on what benefits an open development process will actually bring. Unfortunately the latter is not as straightforward as it might seem in the case of VESNA and SensorLab's academic setting.
While all of the above doesn't mean that I have given up on a free and open source VESNA I hope it does explain why I have been overly optimistic in my initial writings. I still invite you to cautiously stop by SensorLab's GitHub account and web site every now and then in case we manage another step in that direction.