3 ms·

I really can't stand the "Oh yeah? Where are your patches?" attitude that is so prevalent in the OSS community. If hackers want to describe their code as art o

I really can't stand the "Oh yeah? Where are your patches?" attitude that is so prevalent in the OSS community. If hackers want to describe their code as art or poetry; like artists, they damn well better be able to stand up to the critiques.

jerf 17y ago
While it can be taken too far, there are reasons for that attitude, too. I think the most important one is that until you sit down and try to write a patch that actually meets all the relevant needs, you don't have good odds of making a really strong engineering criticism. Any idiot can sit on the sidelines and throw stones. For instance, Zed says he wrote an options parser and it sounds like he wants it to ship with Python. Well, has he made the API reverse compatible? If not, is his really so much better that it's worth breaking reverse compatibility? Should we now ship two option parsers? These are questions that are easy to elide over in a blog post, but must be solved in the process of building a real patch, and criticisms that come from a true, honest attempt to build a real patch are much more valuable. (Also, note the distinction I draw between simply replacing the option parser Python ships with because you have something better, vs. balancing the desire to not break old code against the better choice. Presumably Zed doesn't have years of code written against the options parsing module that Python ships with; those who do will have rather different priorities when it comes to deciding whether to ship a new one, if it breaks their code.) At work, I frequently come across old code, go "This is stupid!", and replace it. Somewhat less frequently, I come across old code, say "This is stupid!", but discover in the process of replacing it why it was done that way. (No comments, of course.) It would be easy for me to go yell "It's stupid!" in both cases, but until I actually spend some time fixing it, my criticism is objectively less valuable. There are other reasons too, this is just what I think is the best. Let me repeat my first point so it is both my first last: This attitude can be taken too far. But the seed of the attitude is there for good reason. See also: http://www.userland.com/whatIsStopEnergy http://www.userland.com/whatIsStopEnergy (Note I don't think Zed has "stop energy"; he has code and he is pushing for things to be done. But I think this is related to the "show me the patches" issue, because in the general open source case it is one of the easiest ways to throw stop energy at somebody.)
- diN0bot 17y ago
  you made so many good (written) points, yet accrued so few (karma) points. i know my own vacuous comment will be down-voted, but it's worth it to say Good work.
- 10ren 17y ago
  Just regarding "stop energy", the thing I love about software and startups is you can just do something. You don't to convince a corporate manager, nor an academic panel, nor the board of developers. All you need do is make something useful, and let the people know about it who need it. Yes, you still have to convince people - but they aren't gateway guardians whose good opinion you must seek, but people who have the problem that you are trying to solve. Your interests are aligned.
zby 17y ago
Just one point - the 'Where are your patches' attitude takes for granted that the implementation is more important than the design. This might be good approach at the beginning to bootstrap a library or language - but after it gains momentum then it becomes clear that API design is at least as important as the implementation of those APIs. And if design is important - then we need to accept that design critique is an important part of the Open Source development process. Lately I have been searching for online API design guidelines - and the results were really rather dissapointing - there aren't many good online resources on that subject (or at least they are not easy to find). But all that I found were stressing how important it is to write use cases and example code using the API before wrtiting the implementation. I wonder what OS projects would accept use cases and example code as patches. Two links for the interested in API design: my reddit question: http://www.reddit.com/r/programming/comments/8n4ov/api_design_guidelines/?sort=old http://www.reddit.com/r/programming/comments/8n4ov/api_desig... and my blog post about the findings: http://perlalchemy.blogspot.com/2009/05/api-design.html http://perlalchemy.blogspot.com/2009/05/api-design.html
- abrahamsen 17y ago
  Implementation is a lot less forgiving than design. Therefore, requiring a working implementation is a way to sort out a large amount of (unworkable) design ideas.
  - zby 17y ago
    True - that's a very good point explaining why the loose coordination of Open Source works so good. But it also has limits - so to reach a next level we need to think how to incorporate design into that view. Maybe if we are more strict with our methods we can make the design also easier to objectively evaluate and sort out those that don't meet the standards.
grandalf 17y ago
there are constructive critiques and destructive ones. Writing an egotistical blog post that rips on someone is destructive.

jerf 17y ago

While it can be taken too far, there are reasons for that attitude, too. I think the most important one is that until you sit down and try to write a patch that actually meets all the relevant needs, you don't have good odds of making a really strong engineering criticism. Any idiot can sit on the sidelines and throw stones. For instance, Zed says he wrote an options parser and it sounds like he wants it to ship with Python. Well, has he made the API reverse compatible? If not, is his really so much better that it's worth breaking reverse compatibility? Should we now ship two option parsers? These are questions that are easy to elide over in a blog post, but must be solved in the process of building a real patch, and criticisms that come from a true, honest attempt to build a real patch are much more valuable. (Also, note the distinction I draw between simply replacing the option parser Python ships with because you have something better, vs. balancing the desire to not break old code against the better choice. Presumably Zed doesn't have years of code written against the options parsing module that Python ships with; those who do will have rather different priorities when it comes to deciding whether to ship a new one, if it breaks their code.) At work, I frequently come across old code, go "This is stupid!", and replace it. Somewhat less frequently, I come across old code, say "This is stupid!", but discover in the process of replacing it why it was done that way. (No comments, of course.) It would be easy for me to go yell "It's stupid!" in both cases, but until I actually spend some time fixing it, my criticism is objectively less valuable. There are other reasons too, this is just what I think is the best. Let me repeat my first point so it is both my first last: This attitude can be taken too far. But the seed of the attitude is there for good reason. See also: http://www.userland.com/whatIsStopEnergy http://www.userland.com/whatIsStopEnergy (Note I don't think Zed has "stop energy"; he has code and he is pushing for things to be done. But I think this is related to the "show me the patches" issue, because in the general open source case it is one of the easiest ways to throw stop energy at somebody.)

diN0bot 17y ago
you made so many good (written) points, yet accrued so few (karma) points. i know my own vacuous comment will be down-voted, but it's worth it to say Good work.
10ren 17y ago
Just regarding "stop energy", the thing I love about software and startups is you can just do something. You don't to convince a corporate manager, nor an academic panel, nor the board of developers. All you need do is make something useful, and let the people know about it who need it. Yes, you still have to convince people - but they aren't gateway guardians whose good opinion you must seek, but people who have the problem that you are trying to solve. Your interests are aligned.

zby 17y ago

Just one point - the 'Where are your patches' attitude takes for granted that the implementation is more important than the design. This might be good approach at the beginning to bootstrap a library or language - but after it gains momentum then it becomes clear that API design is at least as important as the implementation of those APIs. And if design is important - then we need to accept that design critique is an important part of the Open Source development process. Lately I have been searching for online API design guidelines - and the results were really rather dissapointing - there aren't many good online resources on that subject (or at least they are not easy to find). But all that I found were stressing how important it is to write use cases and example code using the API before wrtiting the implementation. I wonder what OS projects would accept use cases and example code as patches. Two links for the interested in API design: my reddit question: http://www.reddit.com/r/programming/comments/8n4ov/api_design_guidelines/?sort=old http://www.reddit.com/r/programming/comments/8n4ov/api_desig... and my blog post about the findings: http://perlalchemy.blogspot.com/2009/05/api-design.html http://perlalchemy.blogspot.com/2009/05/api-design.html

abrahamsen 17y ago
Implementation is a lot less forgiving than design. Therefore, requiring a working implementation is a way to sort out a large amount of (unworkable) design ideas.
- zby 17y ago
  True - that's a very good point explaining why the loose coordination of Open Source works so good. But it also has limits - so to reach a next level we need to think how to incorporate design into that view. Maybe if we are more strict with our methods we can make the design also easier to objectively evaluate and sort out those that don't meet the standards.

grandalf 17y ago

there are constructive critiques and destructive ones. Writing an egotistical blog post that rips on someone is destructive.