I though that first thing that makes particular technology interesting or otherwise appealing to developers is the technology itself, i.e. is it interesting, appealing, innovative and superior, is it tomorrow today and so on. From that point, OpenVZ is pretty much interesting. From the point of openness -- well, you might be right, there's still something we could do.That reflects our internal organization: we have a core virtualization team
which comes up with a core patch (combining all the stuff), and a maintenance
team which can add some extra patches (driver updates, some bugfixes). So that
extra patches comes up as a separate patches in src.rpms, while virtualization
stuff comes up as a single patch. That way it is easier for our maintainters
group.
Sure we understand this is not convenient for developers who want to look at our
code -- and thus we provide broken-out kernel patch sets from time to time (not
for every release, as it requires some effort from Kirill, who is really buzy
anyway). So, if you want this for a specific kernel -- just ask.
I understand that this might look strange, but again, this reflects our internal
development structure.
There is something this brings up. Currently OpenVZ seems to be a
project where you guys do the work and release the source under the
GPL. Making it technically an open source project. However at the
development level it does not appear to be a community project, at
least at the developer level.
There is nothing wrong with not doing involving the larger community
in the development, but what it does mean is that largely as a
developer OpenVZ is uninteresting to me.