Gianluca Turconi wrote: > What I mean is this: before using personal or "niche" assumptions (per > languages or per users group's perceptions, ...) in public texts that > have a great resounding impact around the web, let's do thing in a > professional way:
I think these lists are for more or less "informal" discussions, get in touch and share ideas and impressions. Once we agree to a minimum we can start more organized actions. I think we basically agree a lot, and have a common objetive. I'm going to reshape a bit the post, to get some order to arguments. > I have found Mr. Brown's article structure made as > if he wanted to demonstrate the opening assumption "The OpenOffice > project vividly illustrates the limitations of open source as a way of > producing software". [ ... ] > However, I'm still waiting an evidence that OOo 2.0 bugs are in some > way related to the open source development method's failure. > OK, you are right. I am _not_ saying that OpenOffice.org is buggy because it is opensource, not at all. In fact my criticism to OpenOffice.org bugfixing/developing model is, basically, that it is too similar to closed source model. There is a team of core programmers quite isolated from the users community. Just an anecdote: it is very uncommon to see a hands-on programmer posting in OOo user or questions lists. I think I am not the only one with the impression that OOo project has its own inertia, and is less responsive to external partners than other very big FOSS projects. No blaming here. OOo is very big, not something one can download SDK and produce a patch in spare time after lunch. And this for professional programmers. End users don't even care about inspecting source code. This is only realizing that there is a barrier for access to OOo source code that may impede the application of open-source development model to OOo. Currently, my impression is that the only channel to OOo developers is isuezilla reporting and votes. And that this channel is not an optimal one because users and programers speak very different languages, even have different mindsets. This is not a problem specific to OOo, even to FOSS. This is a general problem in software engineering. As other have pointed out, I do think that the clear success of FOSS model in producing very high quality pieces of software (linux kernel, GNU utils) is due mainly to the fact that end-users were the software architects: ask the carpenter how he uses the hammer, not to the materials engineer. OOo needs a way to connect non-programmer end-users with dedicated programmers that do no _use_ OOo themselves. My hope is that applying the full open source model to OOo would help to correct what I see as a problem. > > 1) organize a real and large marketing analysis among users about QA > and user needs. > 2) prepare an action plan from the analysis' results > 3) annoy 'till death the Council's members with that action plan > 4) support your action plan with a coordinate lobbying group that > includes resources (manpower and/or money) > OK. Let's be pragmatic. I do agree that just complaining and crying without an objetive is a waste. My proposal in the earlier message has been to add an organized layer between end-users and core programmers. Perhaps to make the QA-team more professional (this is not to say they are not working hard now). I would see as an improvement to hire people to perform the "large marketing analysis" you suggest. I do not see it managed in volunteer time. My proposal is that, in addition to an stable and permanent team of programers engaged full-time to OOo development, QA-team should have a powerful and stable structure too, with full-time payed people, even if that implies less programmers. I think the QA team should include experts in the _use_ of OOo for real, practical works, not just programmers or part-time volunteers. People knowing OOo beyond an specifications sheet (as a user I do not mind if a function works as specified if the objetive is not fulfilled. It is a frustration to see an issue closed as "not-a-bug" but without any gain in end-user functionality. This is not about open/closed, but about good engineering practices). And people with a working knowledge of OOo internals as to translate user demands into real specifications to pass to programmers. This concept, translation, is probably the key. > Development skills and engineering decisions comes well before the > distribution/development method used for a software and influence the > result, of course. In a project like OOo you must act on that level too. Exactly, and I would like those engineering decisions to be discussed more openly. I would like to see QA-team, and end-users, more involved and with a heavier weight into those decisions. There is a big step between the Q document and OOo 2.0 final. I must confess that I have been surprised by the implications (in term of loss of existing funtions) of some of the statements written there. Again, problems of translation, from plans to implementation. In less words: I am proposing to reform Issuezilla and issue-management protocols (please read these proposals in the understanding I have no real knowledge of the internals of OpenOffice.org Community Council or engineering policies at the programmer's core) Enrique --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
