How we got started on OS

From The Neuros Technology Wiki

Jump to: navigation, search

Like most manufacturers, Neuros didn’t pay a lot of attention to the open source movement initially, viewing the various activities on Linux, web servers and browsers as interesting but distant phenomenon with little obvious connection to our business. It was almost by happenstance that we realized what a profound impact on our business the open source phenomenon could have.

Our first surprise came even before we released any source code. We had simply released the communication protocol between our device and the PC. Based on that small release of information, brand new synchronization managers sprang up, as if from thin air. They were typically developed by engineers that often had no contact with the company. The software was innovative and took entirely different approaches and in many cases, was preferred by many users to the software that we had spent literally millions developing in house. Equally amazing where the tools that they were using. These independent, open source developers had complete toolkits of free software, that were, in many cases vastly superior to the proprietary ones we had been using.

I can remember the first time I saw the bug tracking software, called Bugzilla, that many of the open source developers were using. Like most companies, we had purchased proprietary software to track our software bugs and enhancements and communicate updates throughout the company. I remember being amazed when I first saw Bugzilla. Not only was it free, but it had all kinds of features that we’d long been looking for. Not only that, but its open source license meant that we could put it on a public server that anyone could access. Suddenly, we had the ability to tap directly into our most sophisticated and enthusiastic users for finding bugs and even better, making suggestions and enhancements. Not only that, but bugzilla had a voting function that meant the public could chime in on its priorities. Overnight, our consumer intimacy would jump five fold with this ability, I thought. When I asked our internal team, no one could think of a single reason that we should stick with our old proprietary closed system.

While everyone agreed that Bugzilla was a superior system for tracking bugs, there were however, plenty of concerns about exposing our internal bug tracking system to the public, particularly from the marketing department: Would users be turned off by being able to see our list of bugs? Would we be able to control a system where hundreds of unscreened users have access to input and comment on all the bugs? Would users be offended when we decided not to make an enhancement they had suggested?

In the end, we decided it was worth the risks and that since Bugzilla was capable of supporting a public based system, why not use that functionality? In the years since we made the system public, none of our fears have come true. In fact, there has been substantially less complaining by users, perhaps because we have given them a constructive outlet to report their issues. Further, our connection with our customers has increased dramatically, and we now have a systematic way to include their input into our internal plans. This level of consumer input could never be duplicated with conventional market research. To date, the concerns about an open system spiraling out of control have turned out to be unfounded as well. As quickly as duplicate or irrelevant bugs are entered, they are corrected, as the community effectively polices itself.

Perhaps not surprising to those experienced in open source development, our introduction to open source as users of the software quickly led to our embrace of open source as a development method. A method that, with heavy doses of experimentation, mis-steps and modifications, we could apply to hardware development as well as software.

Personal tools