I have no deep connections to any open source projects. I do however know quite a few engineers. Bear that in mind.
[EMAIL PROTECTED] wrote: > It seems to me that Open Source generally would be more pervasive if there > was more transparency with respect to the practices observed within the > projects. What possible harm could there be in letting the world know how > decisions to incorporate code are reached? I don't think it's a question of transparency but effort. Documenting the processes takes time which many probably feel is better spent on functional aspects of the project. And for what benefit? Are open source projects more concerned about approval or quality? Besdies, most commercial products have zero transparency in their development processes and it doesn't hinder their market acceptance. > The goal of collaborative > development is to build a body of code with many minds that is better than > the body of code that could be built by any subset of them. The same > principle could be applied to identification of best practices for > committers across projects. If those practices are identifiable and repeatable, then sure, maybe projects could be more productive following a "best practices" approach. OTOH if successful projects function more as little fiefdoms run by benevolent dictators, the reasons for success may be too idiosyncratic and happenstance to translate to other projects. Note I said more productive, as in allow the code to improve quicker. My impression is most engineers don't want to invest time on IP rules and hate when legal shenanigans impinge on their development. They're generally good at providing attribution and avoiding intentional misuses, but won't go out of their way to check sources. Nor should they, as 1) that's not their job and 2) it's a very difficult task (unless you know of some master database containing all the world's code). Hence IP verification "best practices" are likely to be summarily ignored as a foolish waste of time. Closed commercial projects fare no better, indeed they may be even worse since the risk of getting caught is lower. Google for the number of times unlicensed GPLed code turned up in some commercial product. > To me, being unable to reach an understanding > of the practices is analogous to being unable to see and run the JUnit > suites on a bunch of classes - being in the position of assuming that > there is coverage, but not being able to understand how much or how > thorough. Transparency can be valuable to an outsider, but I don't see how most projects would have the time, resources, or inclination to provide it. > I think it is obvious that if every consumer of the code who has an > interest in controlling risk has to reinvent the wheel, there will be a > lot of effort wasted on redundant work. Sure, but this task is better handled by vendors like Red Hat than by individual projects. IP verification is no easy matter to handle, and vendors have a financial incentive to perform the checks. Vendors can also offer indemnity, which individual projects can't. > Why not have the project publish a > document that says "here are the practices by which we manage our code > base - take it or leave it". Just as most licenses are variations on a few > (GPL, LGPL, CPL, etc.), it seems to me that very quickly, a set of common > management practices would evolve if most projects published, perhaps with > a few variations. I suspect part of the reason you have trouble finding answers about IP issues is that there are none to give. I doubt most projects follow anything resembling a formal process for verifying sources. It's more likely left up to individual contributors, and probably runs along the lines of "if it doesn't look obviously ripped-off, then it's ok". > With regard to the issue of trust, how can I either trust or decide not to > trust in an information vacuum? By looking at indirect sources of evidence. How much trust do others put in this project? (Google for one uses python heavily.) How do most open source projects function? How do most engineers handle IP issues? Can I hire an auditor to sample a representative portion of the code base for IP issues? Has anyone else already done so? How often are open source projects accused of IP violations? How serious are they and what are the outcomes? Do closed projects handle things any differently? What assurances do they really provide? Risk analysis means there's risk. Unknowns are inherent. Work around them the best you can. > I may be splitting hairs, but my > understanding is that belief despite absence of evidence is faith, not > trust. Trust is the result of observation, and I want to be able to > observe. Faith is a belief that something is true without evidence. Trust is relying on something/someone to perform a certain way. Blindly believing a project to be free of IP issues is faith. Expecting the committers to take the same reasonable precautions most engineers do is trust. The first is foolhardy, the second is rational, especially when you make your own safeguards against that trust being violated. Faith is binary, trust is by degree. What you're asking isn't unreasonable, but it's also not within the scope of most open source projects. Nor should it be. -- http://mail.python.org/mailman/listinfo/python-list