Standardising software lifecycle tools: OSLC and Eclipse Lyo
We speak to the project leads for Lyo, which aims to bring open standards to the Eclipse communitys lifecycle tools.
Open Services for
Lifecycle Collaboration, or OSLC for short, is a cross-industry
group aiming to define standards for compatibility of software
lifecycle tools. Its aim is to make it “easy and practical” to
integrate software used for development, deployment, and monitoring
Spearheading the efforts to bring OSLC specs to the
Eclipse community’s tools is Eclipse Lyo, which provides an
SDK, test suite and reference implementations. We spoke to Eclipse
Lyo project leads and OSLC members Michael
Fiedler (below left) and Steve
Speicher (below right) to learn more about both
JAX: What arguments would you use (or do you
use) to convince a company to join the OSLC?
Reasons for participating in OSLC differ based on what
role the tool user or organization has in lifecycle
For a tool developer or vendor, an open integration
approaches like OSLC allows them to focus on their core
competencies by enabling them to create software using reusable and
open assets like Lyo which will interoperate with other tools both
inside and outside of their influence, providing time and cost
For a tool user, open integrations reduce the
complexity and risk of increasingly complex software
infrastructures, and improve the value of software across a broader
set of internal and external stakeholders.
System integrators can focus their energy and
resources on higher-value customizations, deliver more business
value to their clients, and increase client satisfaction.
The European CESAR project has produced an
video describing tool integration issues in the systems
engineering space and the benefits of addressing them with a linked
data approach such as OSLC.
Overall, simple and flexible integrations with OSLC
make tools more useful and more valuable for almost everyone.
What makes the integration of lifecycle tools
Past approaches to integration have quite a few
shortcomings. They have relied on each individual tool providing an
API (often private and not supported) which allows its data to be
accessed, often tied to a specified technology: programming
language or platform. When trying to integrate multiple tools from
different vendors, the result is a web of fragile point-to-point
integrations. It becomes difficult to replace existing tools with
new ones. Even trying to upgrade or migrate a subset of the tools
can be impossible due to dependencies on specific versions of an
There is a need to rethink the way tools interoperate.
OSLC proposes an approach similar to the way the internet works –
an approach based on uniform resource access using URLs, common
minimal data formats (while remaining extensible) and the use of
RESTful protocols which are not dependent on any particular
programming technology. Instead of copying or synchronizing data
between tools, OSLC uses linking to create a web of lifecycle data.
OSLC also defines some simple protocols for sharing Web UI
components for scenarios such as resource preview, creation and
The OSLC approach is to provide the minimal about of
specifications required to address integration scenarios developed
by the workgroups. This helps us sidestep another problem
encountered by previous interoperability efforts: over specifying
and making it burdensome to implement and support.
A year ago, we did a first interview for
Eclipse Magazin with you, Steve. Back then, you had a pretty clear
roadmap for Lyo in 2012: “an SDK for Java (and other technologies
depending on contributor interest); reference implementations of
select OSLC specifications; a test suite for OSLC implementations,
including compliance reporting; examples of enabling existing
applications for OSLC integrations (adapters for Bugzilla, Excel
and more)”. Looking back, did everything go according to plan on
your way to the 1.0 release in October?
Lyo 1.0 was able to deliver on all of those goals. We
are seeing good adoption of the Java SDK and several organizations
are using the OSLC test suite to assess their implementations. The
samples have provided a good starting point for developers new to
OSLC who are looking for some assistance in getting started.
The Bugzilla OSLC adapter has been particularly
successful as a demonstration of both the 1.0 and 1.1 features of
OSLC4J. It has been incorporated into a workshop and is the basis
What have been major challenges in trying to
enable the adoption of OSLC specifications in the Eclipse
One challenge is the perception of many or even most in the tool
development community that the Eclipse community is only about tool
integration on the desktop around an IDE. We spend a good bit of
time explaining that Lyo is not an Eclipse IDE plugin – Lyo
provides tools for creating integrations compatible with many
different Eclipse technologies. Tool development is much more than
writing Java code and debugging it in the Eclipse desktop. Tool
development is moving to the web and the cloud and Orion, Hudson
and Lyo are great examples of Eclipse projects addressing those
How has the OSLC community changed over the past year?
Were there any significant structural changes or did it simply
There have been some significant new
developments in the OSLC community over the past year.
The first is a change to the OSLC governance model
that rolled out in June 2012. The goals of this change were to
encourage community growth, enable the community to control its own
rules of operation and make it possible to take OSLC specifications
to standards bodies in the future. To these ends, several changes
were implemented. The first was the establishment of the OSLC
Steering Committee, an executive body consisting of representatives
member organizations. The Steering Committee is responsible for
operational decisions such as workgroup creation and specification
finalization approvals as well as business decisions around
marketing and community recruitment. Other governance changes
include new members agreements and workgroup participation
agreements with clearer flows for how intellectual property is
The OSLC Steering Committee has also recently
communicated a strategy for pursuing specification development and
standardization at OASIS. The feeling is that this is a natural
next step for OSLC and its specifications as they continue to
Finally, several OSLC workgroup members have been
active in the W3C Linked Data
Platform working group. Concepts from the Linked Data Platform
specification will be incorporated in the next revision of the OSLC
Have any particularly important companies or individuals
joined the community?
In the OSLC community, we don’t consider any members
or participants to be any more or less important than others. The
full list of member organizations can be found at open-services.net/organizations
and the current list of implementers is at open-services.net/software.
In terms of Lyo, one piece of news your readers might find
interesting is that Lyo contributors have started collaborating
with the Eclipse Hudson team on implementing an OSLC Automation
provider for Hudson. Bug
398226 is tracking this work.
What features were added in the Lyo 1.1 release and
Lyo 1.1 is a continuation of the work we started in 1.0. The
OSLC SDK for Java (OSLC4J) continues to evolve, and of course there
are always fixes for bugs. The most important enhancements are:
A new client API for developers of OSLC integrations.
This was our most requested enhancement. The core of the API
simplifies interactions with common OSLC resources such as Service
Provider Catalogs and Service Providers. It also provides Java
representations of other popular OSLC resources such as
ChangeRequests, TestPlans and Requirements along with methods to
serialize and de-serialize the objects to RDF.
A set of libraries and a web application for adding
OAuth support to OSLC implementations. OAuth is a popular
authentication protocol but is not always easy to implement
correctly. The new Lyo libraries simplify the task. The provided
web application includes some pre-built tools to help with
delegated logins and administration of OAuth tokens.
An OSLC query library. This was another popular
enhancement request. The library provides APIs for parsing and
processing the OSLC query syntax and includes samples.
Test suite improvements. The OSLC test suite has been
updated to include tests for the new OSLC Automation specification.
Improvements also include expanded Requirements Management and
Asset Management tests and several smaller enhancements and bug
In the project plan it says you want to provide SDKs for
technologies “other than Java”. Which ones in particular? You
mention Perl, and I think I read something about Python and
technologies that we feel are important, particularly from an OSLC
consumer point of view. Scripting languages are a popular way to
the growing popularity of Node.js for server side scripting. We are
trying to gauge the interest in having libraries and samples for
developing OSLC providers and consumers in Node.js. There are
certainly possibilities for other technologies as well (PHP, Ruby,
etc.) depending on community interest and participation.
The OSLC community recently announced the creation of the
OSLC4Net project at Microsoft Codeplex. Would you say that
developers of lifecycle tools have to think & work in larger –
or even global – contexts to broaden tool interoperability, beyond
the borders of software communities and ecosystems?
Absolutely. By their natures, tool integration and tool
interoperability require that developers broaden the contexts they
are working in, often forcing them out of their comfort zones. No
single ecosystem, whether commercial or open source can solve all
of these problems. Efforts such as OSLC provide technology neutral
approaches to these issues, but there is also important work going
on in communities like the W3C and OASIS. The same is true for open
source. There are linked lifecycle data projects coming out of the
open source communities at Eclipse, Apache, Codeplex, GitHub and
more. Each community has its own style of collaboration and
specific problems they are trying to address.
Another point in the project plan is “building a
community”. Can you elaborate?
Building a community means more than just increasing the raw
number of contributors and users of Eclipse Lyo. It means
increasing the diversity of the community and the quality of the
contributions and feedback. We want to see lots of downloads, new
bug reports and enhancement requests.
There are many organizations creating tools and
working towards integrations and interoperability – tool vendors,
internal development groups, universities, individuals and open
source projects to name a few. OSLC is a broader community focused
on lifecycle integrations and we see the Lyo project as the key
open-source sub-community. A project like Lyo can provide a natural
place for these groups to collaborate. Having the expertise,
experience and technical skills of a diverse set of contributors
and users benefits everyone.
A translated version of this interview was previously
published in the German-language Eclipse Magazin. Lion photo by