There has been a good response to the OSLC 2012 Community Survey, so far. For fun, we'll take a look at some of the written responses in the survey, but before that: there are only ten days left to complete the survey - don't miss your chance to influence the future (check out the developerWorks article on that theme too).
Sure the responses are cherry-picked, but not to make everything seem rosy, just to give a flavor of the responses without burying you in all the details. Remember, the complete survey results will be made available once the survey is complete.
Regarding specification development, workgroup participants shared some good reflections:
- The most successful specs are based on existing products. It's hard to define specs for new domains.
- Would like to make sure we do a better job explaining how the scenarios are solved by the final specs
Workgroups may want to consider that second point as they work through the finalization phase for the next standards. Maybe some community members would be interested in writing a short document connecting the scenarios final specifications were to solve with how the final specification does solve them ...
A specification implementer had this to say:
We can access only basic information using the current specifications. There are few scenarios and each scenario expose few atributes. There are a lot of work to do.
This is from someone who hasn't participated in a workgroup, but might in the future. Hopefully he or she will start a discussion around what other scenarios are important for his or her work, at the very least.
End-users are a very talkative bunch:
- From the Configuration Management perspective we have to access the revisions / history. Not only the last information of the artifact.
- Still tricky in a compliance scenario to make sure the link is pointing not only to the right object but also the right version of an object. Unsure how to quickly find and fix dangling references or suspect links.
- Linking is only half of my problem. I want to be aware of the life cycle changes to the things I have linked to. Our tools provide a way to experience notifications and I would like to aggregate these life cycle notifications in the same spot.
- Having used products integrated by OSLC (the Jazz CLM suite) I would never choose to go back to previous tools. With the integration, it feels like I'm using a single product instead of multiple integrated products.
Some more suggestions that might lead to new scenarios (1-3), and a bit of praise (4). The forums are a great way for end-users to start discussions about scenarios they'd like to see addressed.
Nearly 20% of all respondents took time to add some final thoughts:
- Great Idea! The community is more important than the technology! We need more tool vendor buy in into OSLC. OSLC must be extended from software domain to systems (embedded systems) domain.
- OSLC community should pay attention to semantic aspects: they are really important for end users. Semantic specifications from other initiatives should be considered in oredr to speed up the evolution of the specification and its acceptance from the users community.
- In general, it is the best tool integration architecture I've ever seen. We need to improve some things: 1. vastly increase adoption by lowering the bar for implementation: e.g. a "OSLC-enabler" code generator to wrap existing services and expose the data model as resouces 2. support more automation/"process" - e.g. how to implement "suspect link" notification/flagging on a testcase after requirements change? currently, links are quite "dumb" 3. make a more user-friendly and nice web-site - the current wiki is too hard to digest!
- The rate of positive change is great, the quality improvements at each step are great, the community is great. Now if only all open source tool providers would pick up on OSLC... Apparently some tools can do without an architecture but I say no tool can do without OSLC.
- The open community aspect is key. The technology basis on Linked Data is essential. The combination is extremely valuable, I would like to see these essential core values remain and reinforced as the community grows.
- More guidance / education materials for implementers. More focus on scenario definition. Specs should be structured around scenarios, and not around domains. The domains pigeon-holes what resources are supported, and the MUST requirements that individual providers may not be able to support. At a minimum, the MUST, SHOULD, and MAY guidance should be around scenarios to allow implementers to focus on supporting scenarios, rather than a specification.
There is a nice mixture of praise, validation of direction and philosophy, and suggestions for improvement. An extra special thanks to everyone who took the time to provide written responses in the survey, not only have you provided a lot of excellent info to the community, you've written most of this blog post!