On 23 Apr 2014, at 08:38, Nick <[email protected]> wrote: > I took the liberty of changing the subject line to something that > hopefully somewhat summarises your email. > > Quoth Arnaud Legout: >> As polemical as it can be, deeply-held belief such as "I will always >> go for open source code because its security will >> be much higher than any closed source counter parts" should be >> seriously reconsidered >> when there is not a strong community of developers working on code >> maintenance. > > There is a lot of shitty code around. That has always been the case, > and will always be so. Anyone who has used the OpenSSL codebase or > looked at it even briefly has seen that it's shitty years ago, and > probably won't have been too surprised by the recent heartbleed bug. > Strong code can and does come out of small teams, including those of > one or two people. I would recommend rather than judging a the > quality of a project by whether there is a "strong community of > developers" or how the project is financially backed, you take a few > minutes to look at the state of the source code. That isn't a deep > audit, of course, but can give you a sense for the tastes and cares > of the people behind the code. Needless to say proprietary code > which forbids such examination should be avoided, for this and other > good reasons.
When I was "leading" OpenOffice.org I proposed that students, mentored by employed experts and who would probably be project committers (and who might be in fact instructors at colleges and universities), learn about open source collaboration and also programming by working on outstanding bugs and other issues brought to their attention by their teachers and relevant project members. Other large open source projects had people with similar ideas and some, as we did, acted on it. The idea is not to exploit student labour; and I am aware that a lot of important work actually demands the attention of experts, not students. I am also aware that many professors and teachers are indeed moving to use open source projects' code for their classes. But more could probably be done both to uncover and even fix flawed and hoary code and also teach students open source collaboration techniques. (I also would mean for this to be a global effort, not particular to any one country or region.) Thus, one element of a solution could well be the promotion of known or suspected problem code and architecture for student investigation. Any proposed bug fixes would have to go through the usual (or even more than usual) protocols before inclusion into the accepted codebases. I don't think this would change the comment above, by Arnaud, about evaluating any project by the state of its code, though I suspect that for those (or some, anyway) lingering projects whose code is stale yet persistently ubiquitous, a classroom effort that would a) identify the code, its state and value, and b) examine it for its functional worthiness, could help. (I.e., is this code that's used everywhere for really important things actually so flawed as to be irreparable and it would be better to concede as much and devise something superior to replace it?) The process for doing all this could be fairly low-key, and even as a feature of well-known and used code repositories, or those that are used by and cater to education institutions. And I think this kind of effort would work best as a global effort, as there is no "one" open source methodology nor single way of learning or collaborating. -louis > -- > Liberationtech is public & archives are searchable on Google. Violations of > list guidelines will get you moderated: > https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, > change to digest, or change password by emailing moderator at > [email protected]. -- Liberationtech is public & archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at [email protected].
