On 03/27/2012 03:19 AM, Peter Stuge wrote: > > Graeme did some rework of the patch, but generally did not seem to > agree with the review. The new solution included the addition of new > API calls, however without any documentation. As anyone who has > looked at the code and doxygen output, libusb is quite well > documented, so the lack of documentation was obviously a problem.
We are talking about lack of some documentation vs. a serious useability issue. Have you noticed it yet? OpenSSL comes to mind. I am not saying it is perfect, but definitely better than known buggy code. It is the most widely used crypto library despite the fact that its documentation is seriously lacking. Another story is the early days of linux. You might remember: there was the code, and not much documentation, and we were so happy with it. And some guys stepped up and started writing documentation like hell. To reach that point, they needed two things: - functionality to document - functionality they are happy with enough to lend a hand by documenting it > At the same time I expect you to understand that unless you or > someone else produces a perfect patch according to peer review > standards then you must accept that others will work for you in > their own time exclusively when they choose to do so. This is a > very important aspect to understand about open source software. > Open source only works if you take responsibility for every single > line of code that you are using. Open source only works if you understand both the technical and management issues. One question in any project is the "what is the optimal size of a work unit?". While it is certainly not a question which can be exactly answered, it can be argued that: - it is not good to have work units which do not transform working code from working code - the smaller the work unit size, the better for the one doing it The operational words being "working" and "small" here. "small" is especially important for any crowdsourced effort, because the lower the entry threshold, the more the number of participants. And this is not linear but exponential. It can be argued that a feature and its documentation are two different work units. > I recently saw a nice quote from Linus: > > I'm a big believer in "technology over politics". > > ..in response to a question about Linux patches from Microsoft. > Article: http://www.linux-mag.com/id/7439/ > > I agree with him. It's difficult to argue with perfect patches. > However, when patches are anything less than perfect, as they > often are, then the responsibility to perfect them lies with > the contributor. > While a project manager certainly have the authority to decide on what should be accepted, I would strongly suggest you to research the context of this Linus quote a bit more, and read through Cathedral and Bazaar once more a bit more thoroughly. You will find out that leading a succesfull open source project have much more to do with effectively motivate people to do the work than being a good programmer, and sometimes aiming for the perfect code is the slowest way to get good code. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
