On Sat, Nov 12, 2005 at 03:39:27PM +1100, Peter Flodin wrote: > I would like to raise the subject of openSUSE governance. > > At the moment openSUSE is governed by the openSUSE core team > http://www.opensuse.org/Core_Team > > I have a few questions. How are decisions made? By some democratic > informal voting or agreement? Or is it ruled by Andreas or Adrian? :-) > or whoever actually takes on a particular responsibility makes the > final decision for that area? > > The page http://www.opensuse.org/Core_Team_Issues shows that the team > is trying to be more transparent. I would like to know what the view > of the team is towards the inclusion of one or more Community members > (or representatives) on the Core Team. I would see that this would be > more symbolic than anything else, but would show the commitment that > SUSE has towards the community. I would see the person being involved > in discussions, planning, and putting the view of the community > across, unhindered by being an employee.
You are raising an interesting question. I will not give an answer to this question because I think this is not the question that has the highest priority to be solved now. I will try to explain why I think so. The current situation is not yet that you have an open development platform with openSUSE but up to now openSUSE is a platform that is useful to do product marketing and to organize public tests of the software. For an _open_ development platform (like Debian) you need the following three things: 1. Access to the product and its source itself. You already have this with openSUSE but you already had this before when you purchased the SUSE Linux product or downloaded it when it appeared on the FTP server. 2. Have the opportunity to change anything you like. Obviously you have this as well with open source software thus no problem here. 3. You need an infrastructure that enables you to build the full product in a straight forward way _independent_ of any vendor (in this case Novell). With what openSUSE currently provides you can build single packages in a straight forward way but not the full distribution. And even when building the packages as documented on the openSUSE site does sometimes have different results than what you get from the "official" build. I will now explain why you currently don't have (3) with the openSUSE project and why this point is important. The source of all these problems is not that people like Andreas or Adrian are not willing to cooperate (actually they are quite cooperative in most cases) but the fact that the tools they use internally are different than the tools that are available in the public. This is not a problem by principle because if you have public tools that can do the required work, you are fine and don't need to care about how they do it internally. But actually this scenario is utopian because if the SUSE staff uses other tools internally _every_ change to their internal tools is likely to break the tool set that is in the public. In theory someone can always fix the public tools for this case but to do this you must _notice_ the problem. Someone from the SUSE staff will not notice the problem because he or she is using the internal tool set. Someone that does not work for them might notice it but due to the fact that he is not aware of the internal change he has to reengineer that change with the same problems as if he was reengineering the behavior of some proprietary closed source tool (because the internal tool set _is_ actually a proprietary closed source tool set). Because of all this it is currently more productive to do a complete fork of the whole tree than to continuously reengineer SUSE internal changes. If someone does a complete fork this is obviously not useful for the openSUSE project. So to fix this problem it is required that the SUSE staff is using the _same_ tool set as every other developer can use. I know that there are plans to implement such a change in the development process but currently you don't have this. And now to the reason why this is important: If you want to govern something you need some power to enforce your opinion. If you are able to do something on your own (build a variant) if you don't find an agreement with others you have the chance to prove the superiority of your opinion. If you are not able to do it on your own you can only enforce opinions that are perfectly compatible with the opinion of those people that have the tools to implement your idea. Novell or the SUSE staff obviously cannot and would be stupid to implement every idea of everybody involved in some way. This is definitely _not_ what I would call governance then. So before you want some external governance about the project you need better information flow between SUSE staff and non-SUSE people but Pascal said almost everything about that already that comes to my mind and I don't intend to repeat this now. For those people that continuously mix up governance about the project with governance about the Novell products: Be aware that Novell like every other company would be plain stupid to outsource their product management for commercial products. Now you are free to start flaming at me. ;-) Robert -- Robert Schiele Tel.: +49-621-181-2214 Dipl.-Wirtsch.informatiker mailto:[EMAIL PROTECTED]
pgp6tsW1zmtrw.pgp
Description: PGP signature
