What is the etiquette for releasing module & mainboard firmware variants?
Would it be GTM.Seeed.OledDisplay.SkewworksVariant or something like that?
Interesting question. Would it be better to submit it to Seeed to be checked-in into main branch?
Well I’m not just talking the OLED but Hydra’s firmware as well.
I plan to mod both to give a bit more power to the game engine and Pyxis/Gadgetos/Etc type applications. Not sure if they’d want to include that in a main branch or not.
To me, this depends on what you are doing. It is especially important if you are trying to offer something publicly. You do not want confusion to end users between what is provided by you and what comes from the original manufacture.
Also, you have to pay attention to the company name. The name has to be taken out or left in appropriately. Basically, being clear that this is your product (your responsibility) not Seeed’s but at the same time you provide proper attributions to Seeed for their original work. (Seeed is just an example here)
If they don’t want to include it into the main branch, then I guess you have to maintain it. Same applies for hydra. Since it is open source I don’t see why you can’t have your own flavor as long as all the requirements of an open source license are met.
Ok that’s about what I was thinking. Years ago I did the same thig with LiquidWare’s LCD; maintaining my own branch for about a year before the ended up incoporating my changes into the main branch.
This might be a question better asked at the netmf.com Gadgeteer forum to get feedback from Microsoft. Although Kerry does frequent here… It would still be useful info for the broader Gadgeteer community.
It’s an interesting question. For modules, I wonder if you could somehow give the company that built the module credit through the GUI designer and keep the namespace for your driver clean and just use a top-level Gadgeteer.Modules.Skewworks.OledDisplay or Skewworks.Gadgeteer.Hydra. If you look at other open source projects (ex. Linux) there’s not really a history of giving credit to the company/person that started the project other than through comments in the code and the product name (ex. Red Hat Linux, Ubunto Linux, Knoppix Linux, SUSE Linux, etc.). I vote for not have the namespaces getting any longer. I already have problems trying to unpack the Gadgeteer source due to the file paths going too deep.
Of course, where this may get interesting is when a module you’re overriding isn’t really open source. What comes to mind is when the community built their own Kinect drivers last year and MS had a hissy fit.
I was searching for some guidelines on namespace naming and found this thread.
Would something like Gadgeteer.Modules.MischaBoender.GHIMusic be OK for GHI?
It is not bad but will your DLL do?
Hi Mischa,
The naming pattern for Gadgeteer modules is “Gadgeteer.Modules..”. General .NET naming convention is to use only your own name/trademark in namespaces. This avoids confusion between versions and potential trademark issues. If you’re writing a driver for existing hardware, though, you’ll need some way to convey the hardware compatibility requirements.
I’m curious what the community finds intuitive and what hardware makers are comfortable with. Gus, what are your thoughts about people using GHI’s name in the namespace of drivers they write for GHI modules? Would you prefer people to do that or to use the module description & documentation to indicate compatibility?
BTW, if you release your own driver for a module, please consider building an installer package so that it integrates into the Visual Studio designer. More info on that is located here: http://gadgeteer.codeplex.com/releases/view/72208#DownloadId=273356
This is why I asked what will the DLL have. No one should use the GHI name obviously but sometimes this is a software improvement for the GHI module so the GHI name makes sense. Maybe we can take the improvements and drop them in the official driver. I think it is better if work together manufactures/developer/community on making better modules, better drivers…etc. After all, this is the point from open source 
Yes, if it is also your own module. We’ve yet to run across a case where someone released their own separate driver for someone else’s (company or individual) module. Would this ever happen? Probably not, as we hopefully will go with a more collaborative approach as Gus suggests. That does leave the original question, though, which is how best to actually collaborate.
Please don’t take offense but I think it’s naive to think that people will not want to create their own drivers for modules made by others or to think that everyone will always want to contribute to the original driver vs writing their own. Yes, that is the intent of OSS but it’s somewhat contradictory to OSH. Take for example the XBee module driver just getting started. Suppose that by time it’s over we have built a driver that can do everything imagined and it has a nice bloated size. Then someone has a very specific XBee implementation and end up needing to save memory and to do so they decide they can write a driver for the XBee module that only has the few features they need. What would the response be if they suggested to the core module driver team that they rip out 75% of the code that he didn’t need?
Personally, I don’t think the namespace needs to reference the module manufacturer at all. The driver developer should, however, keep the module name the same as that of the module it is built for except in the case of when the developer may find a totally different implementation for the module than was originally intended (ex. Gadgeteer.Modules.SeedStudio.MoistureSensor could become Gadgeteer.Modules.PeteBrown.UrineSensor) 
If we suppose there are some very specific functions that should be included in that case. The author of the new driver should absolutely document publicly and within the driver the original manufacturer and module for the hardware that the driver supports. He should also use the original manufacturers image for the GUI designer except have something on it that indicates a different driver is to be used.
My point in all of this is that we should plan for this situation and Microsoft should publish publicly guidance. This is the third time this has come up in as many weeks…
The xbee driver you guys are working on is not really a module driver. It can have any proper namespace you like. This driver will interface to the serial port provided by the gadgeteer driver.
What if want to use your xbee drivers outside gadgeteer?
I guess I’m confused then. I thought that was the point of the project. There is already a good XBee lib out there for NETMF (MFToolkit).
Good them we nee dot take the lib from toolkit and make it into, either a gadgeteer driver and replace the GHI one or a driver that works on top of the GHI one.
@ Gus
I don’t think I’ll be releasing DLL’s any time soon. Only some code on the code share or maybe a blog in the future.
@ Kerry
Thanks for the clear answer.