Yesterday, I read a blog talking about open source project(http://blog.ometer.com/2012/03/15/a-few-thoughts-on-open-projects-with-mention-of-scala/), in the " Project direction and priorities " section, which makes sense to me:
"An open project and its community are the sum of individual people doing what they care about. It's flat-out wrong to think that any healthy open project is a pool of developers who can be assigned priorities that "make sense" globally. There's no product manager. The community priorities are simply the union of all community-member priorities." Take OVM as an example, apparently, it's not in the Citrix's CloudPlatform team's highest priority. If other people want this feature, the idea situation is to pick it up by yourself. I think Marcus set a great example about how to work with community under this situation. We, the community, are open to bug fix, feature enhancement etc. I like to hear the voice from OVM user or developer. How many users are caring about OVM? Is there any other developer, other than people coming from Citrix, can or want fix OVM issues? Is it acceptable to move OVM to 4.0.x release? > -----Original Message----- > From: Marcus Sorensen [mailto:shadow...@gmail.com] > Sent: Thursday, October 18, 2012 12:54 PM > To: cloudstack-dev@incubator.apache.org > Subject: Re: Drop OVM in 4.0? > > Is there anyone actually using OVM that is involved here on the dev > list? The reason I ask is because I initially got involved with > cloudstack development because CLVM was being dropped, and I needed > it. If there are resources among Citrix or elsewhere to work on OVM > that's great, then perhaps we can commit to having it ready for the > first point release, and current OVM customers can wait. But to some > extent it seems like development of features should be driven or > helped along by a portion of those who use them. Even if it's just an > admin watching the dev list and saying "hey, we use and need this". If > there isn't a lot of that, then support for those features are at the > mercy of whomever cares to take it up. > > I'm not really familiar with the new/old OVM versions, however if I > were an OVM user I wouldn't be horribly upset if I simply had to wait > for a point release. Now dropping it altogether is a different story. > I would think at the very least the old version of OVM should be > supported, with a notice in the 4.0 notes that it's legacy and will > not be updated in future releases. The cloudstack sort of owes them > that much for taking on support in the first place, IMO. Supporting > the new version is a renewal of future commitment, whereas legacy > supprt is just a gesture to those with existing deployments. > > > On Thu, Oct 18, 2012 at 1:37 PM, Joe Brockmeier <j...@zonker.net> wrote: > > On Thu, Oct 18, 2012 at 11:10:35AM -0700, Kevin Kluge wrote: > >> There's nothing in CloudStack to track that so we cannot be > definitive. > >> But, it can't be many. We have seen few questions about its usage > >> and integration. And OVM's share of the server virtualization > market > >> is quite low. Given limited user impact, if this is really the > only > >> problem I'd defer the fix. > > > > The thing is, even if it's a small percentage of users that have > > deployed CloudStack + OVM, we'd be disappointing the shops that have > > deployed CloudStack + OVM 100%. > > > > If we were discussing why we should phase out support for OVM, it'd > be > > one thing - but what seems to be on the table right now is letting > > 4.0.0-incubating out the door with no guarantee that we'll address > OVM > > support in a timely fashion after, if at all. > > > > If the project is going to phase something out, we need to say so > > clearly and loudly ahead of time so interested parties have the > > opportunity to get involved and take over the feature. If nobody does, > > that's fine - but right now I'm concerned we're going to be letting > down > > the users who have adopted CloudStack with OVM who had a reasonable > > expectation that the 4.0.0-incubating release would include OVM > support. > > > > Best, > > > > Joe > > -- > > Joe Brockmeier > > Twitter: @jzb > > http://dissociatedpress.net/