Potential Solaris Engineering Programs and Projects Early draft
Solaris re-planning to identify core programs that we should focus on. The table below details potential programs. Our overall goal is to identify 2-3 "programs" that should be the core.
Potential Core Programs
| Program | Problem Statement | Projects | In scope | Out of Scope | User Scenarios |
|---|---|---|---|---|---|
| Compatibility | Heterogeneous environment where different systems co-exist and work together is a norm in modern day computing environment. We need to provide maximum compatibility with competing platforms to win over developers and customers to our side and be ready for folks who are coming from or connecting our platform with other platforms. To have maximum compatibility in available features and user experiences, this program will focus on how to enrich our compatibility with competing products and services, esp. Linux distros and MSFT Windows. |
1. Locale names compatibility between linuxes/opensolaris 2. iconv names compatibility between linuxes/opensolaris 3. .mo file format compatibility gnu/sun 4. pdf/doc documentation compatibility acroread/evince MS word/Openoffice |
|||
| Competitive Edge | To win in the commodity war and generate revenue, we need to supply innovations and leading edge technologies and user experiences in our area of G11N that will differentiate us from them and make customers to choose ours over theirs. |
Competitive Edge 1. # of locales in OpenSolaris/in leading Linuxes 2. # of keyboard layout support for locales in OpenSolaris/leading linuxes 3. Speed of logging into key locales 4. code conversion speed 5. improve espeak precision of Chinese Innovation 1. |
|||
| Customisation | We cannot do all the things by ourselves. We must be the best in providing user/admin customization feature so that people can freely and easily create their own customizations whether that being on locale, message translation, date and time formats, keyboard layout, and so on. |
|
|||
| Input & Keyboards | This item handles the input method and keyboard layout strategy. Clearly we need to do some catching up for keyboard support. Our strategy WRT IIIMF/SCIM/IM-BUS needs to be decided to create projects on input method area. |
|
|||
| Community collaboration | Our touch point with the community and how we are helping them to help us. We still have a long way to go in making sure that community can easily contribute fixes and translations |
|
|||
| Locales support | Supported locales need to be competitive and should cover emerging markets as well. |
|
|||
| PR | One thing that can set us apart will be to work on products that will make a real difference to customers and make up user scenarios and stories around how they can solve practical problems, and we can blog or email about things we solve. This will help in many ways, user scenarios are a good way to communicate the value add which can be understandable to everybody. Management can use these to communicate to marketing/sales. If we can make this an essential part of each projects it will help us to create complete solution to customer issues, rather than bits and pieces of the solution puzzle. Test cases can be easily created following user scenarios. | ||||
| FOSS | This is in place to measure if we are meeting our quota of # of opensource packages to be integrated to OpenSolaris | ||||
| Documentation |
Our documentation is of limited amount and for existing ones, some could use enhancement for a better and instant understanding. We need to work more on the documentations and establishing and accumulating Sun G11N knowledge-base as well. Solaris has great technology. Solaris has good documentation. However, it is not always easy for users to find a right information. This problem multiplies for non-English users. Therefore, it is important to look into increasing the information accessibility. |
OpenSolaris portal page Command Assistant, Cross-language link, Meta-data |
|||
| Usability | Our GUI and CLI interfaces that we supply from our consolidation for existing components and future should undergo necessary review from expert groups such as xDesign team to make them culturally neutral and, more importantnly, intuitive to use and be harmonious with surrounding platform environment. |
||||
| Globalization services |
As a program, it appears that we will need to allocate some of our resource as globalization services for anyone (within SMI and also outside) who requests our services. This can be a source of revenue. |
Background
There are numerous new and past projects that we can consider belong to the programs we are discussing. The following are some examples of them:
- The virtual keyboard project is based on real US government customer requirement and user scenarios and they have been inviting us and showing us their user scenarios, their own solutions created with Java, and rather recently asked us the solution for Solaris platform once again. This project has innovative features such as multiple keyboards on a single GUI desktop that users can freely choose from to input multiscript text without having to switch in and out of different virtual keyboards and also at the same time, can be considered as a compatibility feature and feature equalizer against MSFT Windows and Apple MacOS GUI-based, user-customizable virtual keyboard feature.
- We added Unicode Normalization and case conversions to Solaris because ZFS, PCFS, and IDMAP projects and other related projects needed them for compatibility with MSFT and Apple products. Simply to put, without them, our storage products cannot be sold.
- Most of the iconvs we have are based on either user requirements or were to be prepared for the new standards announced. I'm sure you have seen numerous emails to i18n-interest and such asking on do we support this or that code conversions; in most of the cases, we could say "yes, we do already support such code conversions" since we anticipated and provided the iconvs with Solaris.This can be seen as staying alive on competitive edge.
- We use antiquated X.org XKB data (from their ftp server not even in their repository) for Solaris and OpenSolaris. All Linux distros moved away to xkeyboard-config years ago since that's being maintained and enriched. It is certainly no brainer that we also should migrate to the XKB data from xkeyboard-config project. This is for compatibility and also to be on the competitive edge as a feature equalizer.
- We have people complaining about how come we don't have locales being commonly supported at Linux distros. It turned out that the problem is not because we don't support such locales but due to that their locale names are different from ours and thus when they, say, remote login to Solaris boxes, they find their locale settings cannot be blessed and thus default to the C locale. I'm sure you've seen many emails complaining about this in various forums and mailing lists. This is another no brainer case that we need to work on by supplying a locale aliasing mechanism as like we have iconv name alias support for similar reason.
-
Notes
Innovation removed as a program, instead it should be a theme. Innovation is expected to happen as part of each program/project.