Citrix XenServer is undergoing a transition to an open and transparent development model. This model will enable users, customers, partners, vendors, consultants and pretty much anyone with an interest in the future and direction of XenServer become active participants. The transition from a closed development model to an open one doesn't take place overnight, and it doesn't come without its share of challenges. As we work towards completing this transition and fulfilling the promise of a vibrant open source project, this page will contain the current status of our efforts, and the next major milestones.
In traditional product management there is always discussion about "roadmaps". Since we're transitioning from closed development practices there will undoubtedly be those who wish to see a roadmap for XenServer. I hate to disappoint, but we don't have one. Instead we have a development and project plan. The plan shows the current prioritization of feature development, and the current development status. Work is actively underway to make that public, but it will take a bit more time. Of course, that then leads people to conclude that an underlying roadmap with specific feature deliveries forms part of the plan. While true in theory, in open source development things are just a little bit different. With an open source project, it's not the features that matter but rather support of those features.
Long time users of XenServer will be very familiar with the "Supported", "Experimental" and "Unsupported" labels given to features, and that model will continue as we move forward. In fact what distinguishes a release is the date of supportability and the support labels given to features. For those unfamiliar with these labels, and to refresh for those who are, here is how we define them for those people who have software maintenance with Citrix:
- Supported – Customers will receive support from Citrix for their implementation of the feature
- Experimental – This label tends to be applied to implementations of a feature which function within a narrow scope. We've used it multiple times over the years and in practice this means that Citrix will provide support on a "best effort basis", but that at the end of the day the code is experimental and it might not be possible to do what the customer expected.
- Unsupported – Customers are on their own if they have made modifications to the system which are outside the expected configuration parameters. This was and remains an important item as we have a general purpose Linux distribution (dom0) as part of the shipping product and as such Linux experts can and do install packages or make changes which could render the system inoperable. Often customers enter into this territory with the best of intentions and our escalation engineers do try to provide some level of support as part of goodwill. I would expect that anyone building their own XenServer from source would be 100% unsupportable as we'd have no way to know what they've done.
In practice this means that until something has official support, the support burden will be borne by the community. Once a release occurs, then certain features will potentially become supported. So what community members can expect is that when we release we will clearly state which features are Supported or Experimental and anything which has no specification can be assumed Unsupported with the support burden remaining with the community itself. Further with each release will also come a date when support or maintenance won't be available. As with all shipping and supported Citrix products, this is listed in the product lifecycle matrix.
So with that as the backdrop, here are the next items on our agenda:
Major project activity: Publish project plan through next release cycle
Next release cycle: Q1 2014
No comments:
Post a Comment