On Sun, 2009-05-03 at 11:39 -0500, Dick Hollenbeck wrote: > >> I have never seen a project that needs to be forked as badly as this > >> one. You sit around and nit pick about about which dinner glasses to > >> pour the water into. Somebody shows up with a firetruck wanting to fill > >> the swimming pool and you can't handle it. > >> > >> This firetruck ain't waiting. > >> > > > > Okay, Mr. Firetruck. Put up or shut up. What is so wrong with this > > community that it needs to be forked? Give us your manifesto. The > > soapbox is ready for you to shout it out to the masses. > > > > I will then try to address each issue that you have in turn. I have > > been where you are standing, and I am sure that I can withstand any > > flame you bring at me or this community. > > > > That goes for anyone else that is thinking the same thoughts. Vent it. > > It will feel good, and maybe we can move forward. Forks should be the > > last resort of the exiled or oppressed. You are not the former, and you > > need to make a solid case for the later. > > > > > >> BTW, the reason this patch was submitted as one is that it cannot be > >> separated. The system won't work with the reduced tms_seq clocks. When > >> does trust enter into this? > >> > > > > Yes, it could be separated. I could do it myself, but I have my own > > list of tasks. My response was based on community standards with which > > you apparently do not agree. That is fine. I was not imposing them, > > rather providing my opinion. A strong opinion to be sure, so what? > > > > Again, I did not deny the patch; I deferring it to others guidance, > > because it touches key elements of the system. I am trusting other > > maintainers that have more experience to judge its correctness, because > > it is bigger than I can get my head around. They can chose to ignore or > > accept my opinion about it. > > > > Zach, > > You are not, at least not yet, a poster boy for what is wrong with this > project. So I apologize to you personally that I was not precisely > clear that my anger and frustration is with the project and not with > you. You were doing your job as you have seen it done before, and as > you understand it. > > You asked to try and understand my point of view. I thank you for that.
No worries. I did not take it personally; likewise, I hope that you understand that I am trying to play a role of diplomat here. So please consider that most of my arguments here will be focused on finding resolution that is satisfactory to everyone. As such, I will be playing devil's advocate frequently in the following; I simply pose arguments that I see as potentially valid. Still, you do win some points. :) But before I start, I do want to stop and pointedly thank you for the contributions that you have made to OpenOCD. I appreciate the donation of time and effort by skilled developers like yourself, and I am motivated in these matters because I see only mutual loss if you chose to leave the OpenOCD community. > In a nutshell, the project policies make it too expensive for me to > continue to contribute. It is about money, which comes from the > expenditure of wasted time. > > It is that simple. I understand that, and I can tell you that forking is more expensive. Despite their costs, collaboration and consensus are better. With this in mind, are you willing to work with the community to develop policies that would be satisfactory? This will require give and take; you cannot expect that all of your expectations will be satisfied. > More elaboration on my points of view: > > > 1) Qualified development expertise is expensive. It is not free. Yes. As a professional software developer, I expect to be paid for most of my time, and I value the time that I donate to open source projects equally. Something to take from this: you are not the only qualified developer in this community. > 2) Not all development contribution sources, i.e. individuals, are > equally qualified. No qualifications are truly unique or irreplaceable. That said, I value your contributions and character; every person brings something unique to a project, and it is always a loss to see those skills depart. > 3) Any use of the linux kernel project as a role model for this project > is frought with self peril because the linux kernel project is a funded > project where developers get salaries and can afford to erect safety > barriers to progress. It is about money. They can afford procedures > and policies, which if adopted by this project, would needlessly impede > progress. You may want to impede progress, I do not. Perhaps someday > there will be an openocd foundation with a corporate financial payroll, > and this may be the only part of the linux kernel project that should be > aspired to until there is funding. Until then it is prudent to realize > that beggars cannot be so choosy. The first problem that I see with this argument is that it fails to see the benefits of the processes. It is not about money. It is about managing the complexity of a large user base and high rate of change. The second problem relates to your conclusions about cause and effect. I believe Linux attracted money because it is a high quality kernel. Period. Money did not build the kernel; passionate hackers did. If anything, the cost of participating in the development of the Linux kernel has remained a constant over the years, thanks to improved processes and tools that I have been described. Of course, the costs will be exorbitant unless you have learned to abide by the practices, but that can hardly be claimed to the fault of the processes. The final problem goes back to your first point; you are not the only qualified developer, so I do not see why you deserve exceptions when others can follow these practices without requiring enforcement. > 4) The software being developed by this project is no where near > satisfactory. The stuff barely works. It is no where near what it > could and might be someday. The driver I spent a week on was basically > garbage before I started. If this project was where it could be, there > would literally be NO commercial alternatives. e.g. Samba basically > put Novell out of the networking business. Openocd is not putting folks > out of business. To be perfectly blunt, I believe the present quality of the code is a direct reflection of the architectural-level management in the project, or, rather, the apparent lack thereof. In other words, I agree with you completely on this point; worse, I know it is an endemic problem caused by the shortage of strong leaders that are also serious developers, as these are the only people that can rise to management in open source. There is a load of room for progress for improving OpenOCD policies, but I do not expect the policies that I described to be implemented immediately. Still, some policies do need to be put into place, as this type of conflict will arise on a periodic basis. Presently, I see this as a lack of social contract, contributor and maintainer policies, and disciplined architectural oversight. Without such processes, there will be ongoing SNAFUs, not unlike those I have already experienced here. I would love to help lead this project to exact the goal you describe: being the #1 OCD software package. With proper oversight, I do not think it would take more than a year to get from here to there; however, I also believe such would only be possible with the development of clear management and community policies that prevent these kinds of flame wars from being a distraction. We simply refer to our policy and repeat the standard phrase, "RTFM and STFU." Talk about saving costs! > *************************** > > Finally, back to the metaphor, because it will also help clarify: I think it actually muddied the water, but it was entertaining. :) If I understand correctly, your main point was that you see the processes that I suggested as being too costly. Unfortunately, I have repeatedly try to point out that those processes should be something to strive toward; they are not a barrier today, just my personal recommendations. Second, splitting patches provides high-quality review by others, and this will be required to scale up. It will reduce the cost for everyone, at a slight personal expense of learning a different process and new tools. [snip] > *************************** > > > In the next few weeks I would like to prepare a roadmap document for > where I think a project like this one should go. I will make that > available to this group. That will basically be done to determine who > and how many other folks would see my vision as an attractive > destination. From that reaction I will then decide whether to make my > fork public or not. But the idea that any such development could be > done by pouring it through some tiny dinner glasses is silly, and > economic suicide. Here are the questions that come to mind after reading this paragraph: 1) Will you take the community's input into consideration as you formulate this plan, or do you expect us to accept or reject it like your last patch (i.e. "take it or leave it")? 2) Why should the community trust your vision, when you are threatening to fork us if you do not like its reaction? Personally, that option needs to be put away and locked up again for me to take you seriously. As it is, I think that you are too obsessed with your own vision to see the needs of the community and come to a reasonable consensus. Sorry. I think your language here is threatening, though I hope that I have misinterpreted that sentiment. > So I do not see any way for me to continue contributing to this > project, financially. Let me just summarize what I have brought to > the project. Because the patches are not earmarked, there is often a > short memory on who contributed what. (There's probably lingering > doubt about the firetruck claim.) [snip] > All in a several weeks, with my hands tied. Again, thank you for your contributions; however, I must remind you that yours are not the only contributions. Moreover, your past merits can only get you so far. At the moment, your threat to fork somewhat trumps anything that you may want to contribute, since it will slow us down if we have to understand the changes you made after you leave. > The only other open source project that I contribute to might have > tainted my understanding of what can be done. It is not uncommon for > me to contribute 4000 line patches at a time. For the second time, I want to remind you that my original reply was not a reject of your patch. I deferred it to others. At this stage in the game, there is nothing wrong with big patches that will move us forward, but I repeat: I do not presently feel qualified to judge your patch. This still does not invalidate my point: you used an inferior process. You could have split it up; I simply see this as a common courtesy. If you have only ever contributed to two open source projects (and considering all of the other facts that you have given us), you are probably not qualified to lead this project -- but I could be wrong. Open source management requires a completely different approach than proprietary products. Heck, I have contributed to dozens over a decade (and led more than a few), and I still barely feel qualified to be in this kind of position. [[I mean, just look at what it entails. ;)]] You can never stand to have enough humility in these circles. I assure you there is a better developer than either of one us lurking here. > They actually thank me over there. Because they understand that if I > am doing it, it represents an improvement, and improvements are what > they want. This again demonstrates a need for more humility: just because you think something is an improvement does not mean that everyone else in the OpenOCD community will share your opinion. There appear to be at least a half-dozen different FTDI devices; are you really so sure that all of them think your changes are unequivocal improvements? I am not so sure, so I passed on the patch. Simple as that. We want improvements too, just not from cantankerous forkers. That is not consensus building talk; it is mutinous. Some projects simply ban individuals that make hostile threats like this. I do not believe in such practices as I have come to believe there are ways to reconcile, if only to come to terms for a peaceful fork. Keep this last point in mind. If you find forking to be necessary, you will find yourself with many more followers and general open source community support if you show a good faith effort to reconcile your differences with the original project. In fact, I myself support the idea of a C++ "fork", though I maintain "rewrite" would be more apropos. However, I am not interested in dividing the community to do it. Cheers, Zach _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
