Open MPI logo

Open MPI User's Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Open MPI User's mailing list

From: Jonathan Day (imipak_at_[hidden])
Date: 2005-06-15 20:34:34

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

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

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

Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around