Phew! I'd no idea my questions would create nearly that kind of level of response on the list. I should post more often! :)
Anyways, here are a few suggestions that might - just might - work around some of the problems that have been mentioned: 1. Publish the stable header files early, or fragments thereof People don't need the finished code to start developing against your API, all they really need is a list of prototypes. After all, we were all taught to design first and then implement, right? :) So long as people know what the function names are, what sorts of parameters are desired, and what constants are declared. They don't even need the values of constants, if the code is correctly written, just the names would be sufficient. This gives developers a head-start on coding, but would not imperil the publishing value, and would not give the inevitable idiots code that may not work as expected. 2. Parallel Trees What I am thinking of here is something akin to Andrew Morton's or Alan Cox' patch series for Linux. You have the "official" Open-MPI, and then you have something that contains all kinds of bits and bobs that aren't stable, aren't validated, and may never be included in the official release, but which would still be of interest to researchers. What would this require? Probably nothing, on your part, as something like this can be done perfectly well by independent volunteers, but could just as well be done by someone you designate. All they would do is take suggested patches and assemble a workable mega-patch, which developers can then choose to patch the official source tree with or not as they desire. What's in it for you? Well, it means that suggestions you're not sure about but look intriguing can be "tested" without being officially live. If the idea works, it'll be obvious enough, soon enough, and you can port it across. This means you don't have to be absolutely rigid on accepting or rejecting patches, because you then have a pile you can decide on later, but which (in the meantime) are subject to scrutiny and testing. 3. Own Your Code It is hard to prove ownership, in a digital age, but not completely impossible. For each function, you want to generate a SHA-1 hash of the source and of the binary (using default compiler options). You then do likewise for each source file and object file and then for each compiled program and library. Most pirates and plagarists are lazy. It is very unlikely they would go through every single function, even to make the trivial change needed to alter the hash values. What you have, though, is a comprehensive, multi-dimensional fingerprint of the entire project. But a fingerprint that, if ANY component matches with the original, is a strong indicator of theft. You could do something like this with a relatively simple script, you publish the hash values, and let the community not only contribute to your work but also contribute to policing against theft. (There have been plenty of incidents of theft of GPLed code, where this was discovered by users and reported, where the FSF might never have known about the problem otherwise.) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
