Should we post our MDSDK source code on the community web site

I can see why we might want to consider this: we're giving the MDSDK away for free anyway so why not just give out the source code too?

I think this is an interesting idea too, but one thing to consider is that, I believe, the MDSDK uses platform specific headers (ie source code we'd want to keep proprietary) as well as a low level understanding of the behaviour of our platforms in order to provide the function that we provide (ie our developers know the idiosyncrasies of the Ikon, 7535, Neo, etc, for example, and have optimized the code to work on the specific platforms)

Perhaps one of the SDK developers could add more to this but I would think that if we simply released the MDSDK code as-is we'd end up opening up a lot more of our source code than we anticipated just to get it to compile.

One interesting idea I've heard from some developers on this topic is something along the lines of standardize and _publish_ our IOCTL interface layer as well as all the header information you'd need (constants and what not) along with some documentation on how to make use of it all.

Once that's done then our MDSDK becomes just one of any number of possible implementations that makes use of the IOCTL layer.  At which point we could then make the MDSDK open source too.

Peter you asked a great question here and got some good feedback from Adam. We will create many such tricky issues. What I want us to be doing is 'testing' openness. The more open we are, the easier to do business with. Of course, get too open too quickly and we'd be 'easy to compete with' aswell...not so good. So we have to consider the boundaries and how we can push them, and be ready to pull back slightly if we go too far. Sometimes, we'll get it wrong. Well, so be it. .

And what I meant to finish with is: please keep this discussion going I'm as interested in other views as Peter is.

Lets put some boundaries around what we are talking about.  In this context Open Source means some people will be allowed to read our source code.  They will not be given everything that is required to recompile our SDK, as they do not have access to the required private OS files.

What people can do is read the source code in order to better understand what it is doing.  A couple examples may help clarify what I mean:

Example 1.  A parameter out of range error is being returned by our API.  A customer can look at the source code and determine what range checking we are doing and why we consider the given value to be wrong.  This means one less call to the help desk.

Example 2.  A customer wants to turn off the sd card slot, but they don't want to include our entire SDK.  They can see what IOCTL we call to perform that operation and the MAY be able to copy/paste that code into their application/driver/service.  We have just make the lives easier for third party hardware developers.

In essence our SDK becomes a big repository of sample code.

I also believe that the source code should not be opened to everyone.  We have some kind of financially beneficial arrangement with partners and access to our source code could be one of the incentives to being our partner.

How would this effect our responsibility in supporting customers with their issues? If a customer has a problem with a specific SDK API, it's a question of "I'm calling X API with Y parameters, why is not working?". On the other hand, if a customer uses the SDK as documentation and builds in functionality in to their app it now becomes "I used your SDK code as a sample and integrated its functionality in our proprietary app. I can't share our app source code and the relevant code pieces are tied in to our business logic so it would be difficult to provide useful code snippets. I'm having problems with X component but it works with the SDK. Help?" In essence, how can we make doing business with customers that are not as open as us easier?

I'm not sure our support obligations change much in this case.  I would think our responsibility would be to support our published interface. Currently it's the SDK. If we publish our source code, even to a limited audience per Ron's suggestion, then our published interface becomes our IOCTL layer (a good amount of it does anyway) actually I guess it's both, as we'll still need to support the SDK.

If a customer is having problems with proprietary (to them) code then I don't think it matters much if they're using our SDK or our IOCTLs to interface with our device. It might be more difficult to debug if they're using the latter, but they (the customer(s)) are still going to have to provide us with examples of broken code etc, same as they would if they're using the SDK.  

It think that a significant point here is that we'd essentially be publishing our IOCTLs.  It adds a level of scrutiny to an area of our core code that we've never had to worry about before - which isn't necessarily a bad thing but there will likely be a bit of tidying up to do before we let the public in.  It also has implications for software test as well as documentation (even if we're limiting the audience we'll still need to test and document the behaviour of the IOCTLs if we're expecting people to make use of them directly).

As a developer the SDK source code would be ”manna from heaven” as it could helping resolving a particle issues regarding to our devices, and you can be less depending on what sdk library version now and then is on the device, but your applications could easily be tied up with on platform, and require some work to make it work on new platforms/devices.

So by using the official sdk library your application properly will work out of the box on new devices.

If the main sdk is going to be open, does customers require that other sdk’s is going to be open?

We have different sdk’s for different rfid modules and we have mdk’s. I’ll guess that some of those are more or less bound by some sort of agreements.