openArchitectureWare Charter
Preamble
openArchitectureWare is a very well‐known and established tool for model‐driven software development. Together with other tools from the Eclipse platform, it supports language definition, model authoring, model checking and transformation and code generation, as well as other modeling related tasks. This document serves as the charter of openArchitectureWare. It defines what openArchitectureWare itself, and the openArchitectureWare team is.
This Charter has been discussed and decided during an oAW team meeting in November 2008. We will work over the coming weeks and months to implement all the things defined in the charter.
openArchitectureWare tool structure
openArchitectureWare is a well‐integrated, documented and supported one‐stop toolkit for MDSD. It is comprised from several different building blocks. They are illustrated in the following diagram. They are explained below.
At its core, openArchitectureWare is comprised from various projects hosted under Eclipse Modeling (e.g. TMF, M2T Xpand) and a collection of additional projects from other sources (e.g. integrated documentation, the oAW perspective). The core is released, built and tested as one integrated tool (hence the containment diamond). In addition, there are other Eclipse projects that can be used with openArchitectureWare, and for which there might be some kind of special integration (e.g. EMF, EMF Compare, GMF). oAW also endorses a set of components which we call addons. They are not part of the oAW core, but are tested with and developed for openArchitectureWare (e.g. the visualization stuff or the PLE tools). Finally, there are 3rd party projects that use openArchitectureWare but are otherwise completely independent of oAW. The oAW team has no influence over or concern for those projects.
Let us look more closely at each of these different parts:
Core components (Eclipse‐based or not) are integrated into the oAW Build. To make this feasible, they have to provide a build infrastructure based on Eclipse standards (EPP, Update Site). The oAW test suite provides automated integration tests for these components. Their documentation is integrated into the oAW documentation, specific documentation that explains how the component is used in an oAW context should be provided. The oAW website acts as a dispatcher for the core components’s support forum/newsgroup and bugtracker. Each core component needs to nominate one contact person to the oAW team. The oAW team decides via voting the set of core components, taking into account the criteria explained here.
For core components that are themselves Eclipse projects or components, support happens through the project’s newsgroup and bugtracking is handled through the Eclipse bugzilla. The contact person is typically the project lead.
For non‐Eclipse core components are supported via the oAW forum and bugtracking is handled via the oAW bugtracker. It is expected that most Non‐Eclipse oAW components are stored in the oAW Sourceforge repository.
Addons are coupled much more loosely to oAW. They are basically independent project with their own release cycle, source code repository and support infrastructure. An oAW core release can be created without consideration for any of the addons. This makes oAW core development and release much more agile. However, addons are actively endorsed by the oAW team. Addons are encouraged to use oAW branding. Downloads for the addon packages are provided on the oAW website.
To ensure livelihood, an addon must provide a new, compatible release within 4 weeks of a minor or bugfix release of oAW core, and within 8 weeks for a major release. Addons only get the “compatible with oAW version x.y.z” after a smoke test has been done with the particular oAW version. Documentation must be available that shows how to use the addon in the context of oAW.
Each addon must provide a contact person for the oAW team, and one oAW team member acts as a mentor (the contact person and the mentor can be the same person, if the contact person is part of the oAW team).
Just as with core components, the oAW team votes what shall be declared a addon.
Packaging and Distribution
openArchitectureWare provides the following download packages:- An oAW core download, it contains all the core packages (ZIP, Update Site). The version of oAW downloaded already contains the update site references for all the addons.
- On the oAW download page, a download link for the various addons is provided (update sites and ZIPs). It is organized by oAW‐core‐version.
The oAW Team
The purpose of the oAW team is to manage the oAW tooling and further the oAW brand. More specifically, these are its duties:- All of the oAW team’s decisions should be communicated to the public to make the process transparent. A website, RSS feeds and meeting protocols will be used for this purpose.
- For internal discussions, a mailing list that is only accessible to team members is used.
- The oAW team will run a telco on every 1st Tuesday of the month, at 21:00 Central European (Daylight) time. The telco results will be published on the website.
- Once a year, the oAW team meets in person; we try to coordinate this with a conference to minimize travel overhead. Most likely, this conference will be the JAX conference.
- The oAW team consists of natural persons, not companies (for a further discussion of this topic, see below).
- The oAW team votes on the inclusion of additional core components or addons
- The team plans releases, scopes the features and coordinates the releases with Eclipse release trains. Specifically, it tries to coordinate between core and utility components teams to provide additional value through coordinated feature sets
- The oAW team designs a CI for oAW and furthers the brand by speaking at conferences and writing about oAW in suitable venues
- The team is also responsible for building, maintaining and running the oAW infrastructure (build, bugtracker, CVS, website)
- The oAW team uses a voting process to add/remove team members (see below)
- It provides mentors that coordinate with utility teams
- The oAW team provides support in the various forums and mailing lists
How to become a team member
To become a team member, a current member has to propose the candidate. In addition, the candidate or proposer has to explain in an email on the list why the new candidate should be voted into the team – for example, by explaining the role the new team member will play once he’s a member.If somebody has not been active for 6 months and, after pinging him, shows no intent to change this, the team member becomes passive. Passive members can become active again, simply by showing signs of activity. If this does not happen, the team member becomes an alumnus. Becoming active again requires another proposal and a vote.
If important reasons prevail, the team can vote out an active member. In contrast to all other votes, this requires a 75% majority.
Voting
All voting in the oAW team happens accoring to the following process:- A voting topic is typically discussed in a telco to prepare the context
- A team member starts a vote via the mailing list.
- The voting process runs for 7 days; the deadline must be explicitly mentioned in the voting request.
- A vote is successful, if more than 50% of the team members voted within the 7 days, more than 50% of the voters voted with +1 and there’s no ‐1 (veto). Only the voting out of members requires a 75% majority.
Initial Team
The initial oAW team consists of the following people:| Jan Koehnlein | itemis |
| Sven Efftinge | itemis |
| Peter Friese | itemis |
| Bernd Kolb | Independent/SAP |
| Karsten Thoms | itemis |
| Markus Voelter | Independent/itemis |
| Dennis Huebner | itemis |
| Patrick Schoenbach | itemis |
| Moritz Eysholdt | itemis |
| Michael Clay | Codeworkz |
| Ekkehard Gentz | Independent |
| Dieter Moroff | COR AG |
| Ueli Brawand | Zuehlke |
| Heiko Behrens | itemis |
| Meinte Boersma | Independent/Capgemini |
Roles
Team members have to work on the tasks outlined above. However, there are specific roles that require special attention by a dedicated team member. Here is the current list:- Release Manager (Peter): planning and coordinating releases, drive feature scoping and test
- Build Manager (Dennis): make sure we have one or more stable and effective builds running all the time
- Support Supervisor (Karsten): make sure most of the questions in the support forum(s) are responded to and the documentation is adequate
- Public Relations (Markus): keep track of oAW publications and public appearances, publish them, define the “official messaging”, collect success stories
- Webmaster (Heiko): select, install and maintain website and CMS, design, CI
- Zeremonienmeister (Dieter): facilitate discussions and make sure we follow the processes described here
The Role of Companies
In principle, the oAW team members are individuals and not companies. However, we expect that most team members act on behalf of companies and spend at least some of the work time working on oAW. Hence the relationship to companies must be defined.We distinguish two different kinds of companies: Supporters and Certified Service Providers.
- Supporters support the case of oAW by helping with publicity or otherwise furthering the cause. The get an official “friend of oAW” logo they can use for their website. They are mentioned and linked on the oAW website.
- Certified Service Providers provide professional support for oAW. While any company can do this, only Certified Service Providers are listed and linked from the “professional support” page on the oAW website. There will be a special logo “certified oAW service provider” they can use on their own website.