Subject: Re: [vserver] Roadmap and Future ...
From: "John A. Sullivan III" <jsullivan@opensourcedevel.com>
Date: Thu, 26 Feb 2009 22:00:19 -0500

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