On Fri, 2009-02-27 at 01:35 +0100, Herbert Poetzl wrote: > On Thu, Feb 26, 2009 at 05:07:06PM -0500, John A. Sullivan III wrote: > > On Thu, 2009-02-26 at 20:07 +0000, Ed W wrote: > > > Herbert Poetzl wrote: > <snip> > > > I believe Ed is giving some excellent guidance here. > > > We are very impressed with the technology of the VServer project but > > it does not project a very professional ethos, sometimes comes across > > as a tad bit arrogant, and it's very hard to pick up the project from > > scratch. > > okay, I would like to get into details here, especially > the following points: > > - does not project a very professional ethos > - comes across as a tad bit arrogant > - very hard to pick up from scratch > > could you (all) please elaborate on them, as I do not > fully understand why that would be so ... Ah, you mean I actually have to remember the history that led me to the perception :) The last point is the easiest. We had planned on using Xen for our large new project. On a lark, I took a look at alternatives and stumbled across OpenVZ. That led me to this strange but not very publicized beast named VServer. Under the gun on a major deadline for a huge project already running behind schedule and with funding delayed to hire the needed resources so the team was stretched beyond productivity (sound familiar - at least the last part!), we decided to make a major technology change and pursue VServer because of its remarkably efficient use of resources. The challenge was where to start. Coming from a very different virtualization perspective, I had to learn a new way with new tools. There was a nice overview but how do I dive into the internals and figure out how to adapt it to my environment. Much of the documentation reflects being lost in your own context, i.e., it makes perfect sense to you but not necessarily to someone who isn't already very familiar with either VServer or kernel hacking - i.e., thinking like a developer and not an end user. Imagine someone who is brand new to VServer and knows very little about kernel internals trying to install on RedHat by going to the RedHat howto: http://linux-vserver.org/Installation_on_Redhat or the Ubuntu howto: http://linux-vserver.org/Installation_on_Ubuntu with statements like: This is NOT COMPLETE -- remove this message when you get it to work! The flower page is great for those who understand kernel internals but how does one know how to use it if one doesn't. It takes a lot of research on other sites to learn enough to be able to read the VServer documentation. Then there is the matter of where to find the documentation. Frequently, I stumbled across priceless pages in Google searches that were not directly available from the documentation page - my bookmarks are full of them just so I could find them again since there was no obvious way into them. The professional ethos is a little harder to quantify but is not an uncommon problem in the open source world. I suppose it comes from hearing a number of helpful suggestions that make perfect sense as a developer but would just never be done in a production environment where engineer induced outages must be kept to a minimum. The arrogance comes from statements that lead one to believe that you believe things are already being done as well as they can be done. For example, rpm.hozac.com has been down at several critical times for our project. We and others have offered to provide space to house the repositories in a more stable environment but that was seen as unnecessary. Someone just had to get around to taking a look at the power supply on the failed server! This is when I start thinking to myself, "What sort of organization am I relying upon to run my enterprise systems when their repository goes down for days and weeks because of a bad power supply." Definitely not professional and probably a great drain on your very precious time (precious to both you and us - we certainly would rather spend our time providing good infrastructure so you can spend your time coding rather than turning screws). > > > All of that can be a sign of overload on a small core of developers > > so I quite understand. > > well, currently (not counting the distribution maintainers) > we are basically down to two here, so definitely a lot of > work for a very small group of people This makes all of the above understandable. I didn't realize the team was so small. I can quite understand. I have a very ambitious open source project of my own but have not even had the time to manage those who have volunteered to help -- deeply frustrating but after working a 60 to 80 hour work week, there's not a lot of time left over. So I really do understand and hope I am not coming across as harsh or unappreciative. > > > On the other hand, I have found the developers unbelievably > > supportive - I can't say enough good in that area. > > > However, appearance and ease of entry are important to attract > > new users and contributors. > > again, what _is_ the ease of entry issue? > > > If it were not for the outstanding technology, I certainly would > > have gone elsewhere and never known about the great support. > > I'm not sure it is the best idea to put something like > "Oh, and by the way, we have good coffee in the IRC channel" > on the main page, I think good support should be communicated > (and actually is communicated) by the user/adminstrator <grin> Yes, frankly, sometimes I've felt guilty about the time I have taken on your IRC. I keep thinking, these guys are saving my bacon but don't they have more important things to do than help me with my ignorant questions. (embarrassed and red faced) > > > We are planning to build a large part of our new business on > > VServer and would be very happy to contribute as soon as we > > build our revenue stream. > > and here is it down to the point (the real chicken egg > problem, IMHO), without constant contributions, there > are two ways to go (for the developers), work on something > which actually gets payed or focus on selling a product. How well I know. That was the whole idea of the Open Source Development Corporation but it has not yet found any traction. > > In any case, you, the 'customer' will not get the high > quality, high performance technology you are using (or > planning to use) right now ... > > > This is far too great a project to let die! Thanks for all > > you've done, all you VServites! > > you're welcome! <snip> -- John A. Sullivan III Open Source Development Corporation +1 207-985-7880 jsullivan@opensourcedevel.com http://www.spiritualoutreach.com Making Christianity intelligible to secular society