That’s exactly the type of hurdles that I refer to in my previous post. On most of my projects, this problem has been solved by either providing build and configuration scripts with instructions or step by step instructions (including copy/paste command line incantations) that are tested to get a user from zero to a testable binary. This is also accompanied by contact information and an invitation to get in touch to get help if/when stuck.
Sometimes users need a fair bit of help to get going. I recall one time a developer tried to use an old MacBook to run the Linux build environment in a virtual machine. The build kept on crashing for him for no obvious reason. Eventually we tracked the problem down to the fact that the ancient CPU in his old Mac did not have support for some Intel CPU instructions that the toolchain was trying to use. The fix was to change the way the cross-compiler was built, which required me to update the entire SDK for several platforms. A couple of days of rebuilds and 12GB of SDK and firmware uploads later, the new developer was up and running. This was time well invested, as this developer has contributed thousands of code changes to the project over the years. His contributions have improved the products in significant ways and he enjoys a lot of respect and admiration from the entire user community. He has outlasted the paid staff from four ODM companies that worked on the projects. Companies that employed a closed source development model internally and only reluctantly obliged to my client’s request for source code releases of core components. But that’s a long story that is best told over many good beers…
The amount of effort that potential contributors will go through to get started on an Open Source project varies. Some will give up after less than half an hour, some will persist for a whole day. However, in most cases, if a developer can not get the project off the ground and start making changes in one night, they will walk away.
Managing the code contributions and developing in the open are the next two pieces of the puzzle.
A long time ago I made it a policy that all firmware releases that I manage (including first production and pre-production factory runs for new models of hardware), must be built from source code published in public repositories on GitHub/BitBucket. There are mechanisms to switch out various packages to developer’s own forks of the public repositories, but those private builds are never used for public releases. I work on the premise that if I was going to be run over by a cruise ship tonight, then tomorrow someone should be able to fork the code repositories, rebuild the firmware and keep going. (Or as it happened on a previous project, the company had liquidators appointed and all staff were locked out at 10am on a Friday morning and all services were shut down. By Sunday night, customers had alternate firmware images and new software feeds available thanks to the Open Source community. If it was not set up this way, customers would have bricked devices, because the liquidator would not spend any money on keeping the existing customer base operational as it was not bringing in additional revenue. Again, ) The current firmware images I maintain have over 10,000 packages, including full Linux kernel builds, third party device drivers and online repositories of optional plugins. Most of the product related contributions that I receive from the community are actually only affecting about four or five packages/repositories. Most of the other updates tend to be pulling patches and security fixes from upstream feeds.
Anyway, long story, but the crux is that Open Source development can provide great value, however it needs support from the top level management of the company. It is a long term commitment and it is challenging to quantify/justify doing so if the management takes a narrow minded traditional approach that only focuses on balance sheets and stock price using the models that have been entrenched for so long. The tide is slowly turning. Open Source, social responsibility and the scrutiny of social media that leads to public perception all affect the value of a company and it’s ability to attract and keep customers. Companies are now realising that to do well, they need to pay attention to these aspect too. My perception is that Singular Sound are very likely to have the right philosophy at the core. Managing Open Source engagement may not be their forte just yet, but if they commit some resources to it and bring in someone experienced they could do really well. If nothing else, it would improve their internal processes and make it easier to be agile and bring in extra talent as required.