Date
1 - 1 of 1
3rd Party Development for the UDR56K (Was: GPL source code)
"John D. Hays" <john@...>
As Bryan stated, we will not be delivering any kernel patch or driver source code before product release. This code is under active development and test, and is often the case in such development it may make significant changes before the product is released. It would be a disservice to external developers, who do not participate in our internal development process, to provide code that may send them down a path that could suddenly take an unexpected turn.
At some point, the code base will be placed in a public repository (like SourceForge) where others can not only retrieve it but get updates as they are released. We are aware that there is always a desire when something new is coming out to get a jump on a 'cool' project that has been waiting for the product. However, as a company we need to stay focused on getting the product ready for market. The good news is things are progressing nicely and we will give updates over the next weeks and months as we get closer to release.
Our thinking is that we will have several communities of users for the product: 1. Application users. These are customers who want a specific application such as a D-STAR radio for DD or DV, an APRS terminal, an AMPRNET node, etc. and are looking for pre-built applications with easy configuration and operation, that are basically plug and play. For these users we need a very well defined offering that we are confident will be usable and reliable. These users' need for source code is generally non-existent other than for the assurance the code is available in both binary and source form.
2. Infrastructure builders. These are customers who likewise need "plug and play" solutions whether that be a RMS Gateway, APRS iGate, D-STAR Gateway, AMPRNET Gateway, or similar. Again source code is for understanding how it works and the assurance that it is there for a rebuild or modification, if needed. These folks also need integration information on how to connect their piece of infrastructure into other infrastructure. They need application notes, recipes, and examples, e.g. how do I use the UDR56K to support my current 1200 baud, 2 meter, APRS node and extend it cover higher speeds at 70cm? How do I build a large, regional packet network backbone? How do I add a UDR56K to my existing D-STAR stack? How can I make a regional Digital Voice network with many access points and repeaters that are bound together to create one large "virtual repeater"?
3. Visionaries, Experimenters, Accessory Builders, and Application writers. These are the folks that really need access to source code, because they may need to add a driver, write a new protocol handler, create a new way to integrate additional technology. There needs to be a reliable source of code, documentation, and examples for them to adopt, modify, and understand. This is probably the smallest group, and potentially the inventors of better ways to accomplish what the application user and infrastructure builder is trying to achieve. Where NW Digital Radio is different, is we want to enable these folks, for the advancement of the art of Amateur Radio. Most companies don't want you modifying their "competitive advantage" and "proprietary secrets" -- most of what will make our product work from day one is built using or building upon the work of others who have shared their talents through open source. Our goal is to extend that wonderful gift back to the community and hopefully the community will reward us for it, by buying our products and enabling others.
The question has been raised if 3rd parties will have the opportunity participate in the creation of these components? The answer to that is an enthusiastic "Yes!" We just ask that you allow us to bring our product(s) to a deliverable state and to roll out the enabling tools when the time is right.
There is very little "firmware" in the sense of a traditional embedded device, most things run under the OS, either as applications or as components in the drivers for hardware. There may be some low level "bit twiddling" that is closer to traditional firmware and we can talk about that when someone has a specific need.
We will review 3rd party components for "fit" in our standard delivery and add them if it makes sense. Individuals are always welcome to take advantage of the open platform for their own components. One of the perils of our approach is that support of the product(s) we produce grows with open access, and can be costly unless we limit our direct efforts. (Such costs would need to be reflected in product price or performed for a fee, neither of which is appealing.) We are going to have to some guiding principles.
With all of that said, we know some of you are still eager to start working on something... :)
Here's what I will offer for now. Not much you can do today that interfaces directly with the radio board, but if you have applications that run on the computer side, that only talk to peripherals (and kernel AX.25) and want to give it a go:
So have fun and we at NW Digital Radio will keep "heads down" on getting the product to market.
John D. Hays K7VE
|
|