Principles for The Open Group's "Open Source in the Enterprise" project

A) Scope

The scope of "Open Source in the Enterprise" described in Burlingame seems to match the interests of those engaged. And this is not meant to preclude expansion of the scope should additional areas of interest be proposed and attract sufficient interest to make progress.

B) Modus operandi

In keeping with the topic, participation in this project is proposed to be driven by contributions. The other underlying principle is agreement to pro-competitive and consensus-oriented conduct established in The Open Group.

So here is the proposed core modus operandi:

1. Participation in this project is subject to agreement to the The Open Group's consensus-based pro-competitive rules of operation. In case of meetings, all participants will be expected to pay normal meeting fees to cover the costs involved
2. The Open Group will provide support in form of operating an electronic work space (web-publication, email, etc.). There will also be a degree of oversight to with the goal to keep the site's content in line with The Open Group's principles. It may be possible to engage sponsors with interest in this project's topics, which could help in lowering meeting fees, publications efforts, etc.
3.  "Open Source in the Enterprise" will be a project within The Open Group, managing its own way and operating in partnership with the other Open Group activities. This means that there will be oversight by The Open Group's Governing Board and regular interaction with the other activities. This also means that the deliverables are subject to The Open Group's consensus process.
4. The project, due to the partly informative and promoting nature, should seek effective ways to reach out beyond the usual Open Group mechanisms.
5. As a result of the above, progressing deliverables is subject to volunteer contributions and subject to efforts to reconcile conflicts with other deliverables. Also, it is expected that discussions are public within the project so that contributions are flowing freely and progress is spared conflicts and set-backs coming up late in the process.

C) Near future

 Get going.

The work area for the OSE project is up on The Open Group's server and can serve as a central repository and communications vehicle (email distribution list, posting of contributions, schedules, etc). This means that contributors can contact and engage with all those who signed up in Cannes, Burlingame and in the future.

 Collect and structure inventory of proposals.

It appears to be prudent to open discussion about and proposals for possible work items to all on the OSE mailing list, and to offer all Open Group members to join the list. That way there is a maximum of input early on, both in topics and in underlying motivations. As a next step the collected items can be fleshed out with a more detailed description. The next step would be to rationalize the suggestions in discussion between activists, with the goal to align contributions rather than waste them in conflict. Conflict will appear and is healthy, but there must also be a will to move forward. Among the Open Source communities there are a good examples how this can be achieved. The collection of initial items, their refinement and rationalization should be done within a few weeks.

 Enlist contributors.

The next logical step is to go for delivering. The call for contributors will hopefully attract viable teams to get deliverables out the door soon, e.g. starting this summer. It is also necessary to get clarity about the release process. As this project is under the name of The Open Group, its well honed consensus process needs to be followed. Therefore contributors need to have a good explanation of this process. Not that it is complex, it just needs to be understood early.

 Flesh out the modus operandi.

This point is listed last, as it can turn into a bottomless pit if tackled before there is an idea what work needs to be done. The modus operandi makes only sense in context with scope and content of the planned work. There should be a fairly general agreement between members of the project at the start, like openness and reliance on contributors. There also should be a style of making constructive contributions, like producing something for adoption, rather than merely suggesting work or just criticizing. But codification of behavior should not be a primary activity.