Governance and Management of the Archi® Project

Principles

The following describes the guiding principles used by the Archi® project:

  • Open - We believe in “open”, in open standards and in open source. We believe in sharing. Archi is open to all; everyone participates with the same rules; there are no rules to exclude any potential contributors
  • Transparent - project discussions, plans for new features and other artifacts are open, public, and accessible
  • Meritocracy - Archi development is a meritocracy. Roles are merit-based and earned by peer acclaim.
  • Liberal licensing - Archi’s code has a liberal open source licence, the MIT licence. It means that anyone can take the code and build a commercial product based on it.
  • Freely available - There will always be a free and open source version of Archi
  • Elegance - We believe in elegant and simple design. Archi is agile, intelligent and lightweight.

Who runs and manages the Archi Project?

Archi project management and development is led by Phil Beauvoir together with Jean-Baptiste Sarrodie. There is no committee or governing body.

Who does the work?

Phil Beauvoir manages the Archi project and development. This includes the majority of coding, continuous integration management, build cycle, documentation, website, forum, support, and maintenance.

Jean-Baptiste Sarrodie is the Archi and ArchiMate evangelist. He is the lead on gathering user requirements, ArchiMate expertise, and Archi's feature set.

All work is unpaid and voluntary. There are no formal affiliations between any person and any organization or between any person and their employer that affect the development of the project.

Where can one download Archi?

Archi for Windows, Mac and Linux can be downloaded here.

Where is the source code?

The source code to Archi is maintained and developed on GitHub, the open source software development community:

https://github.com/archimatetool/archi

How can contributions be made to the project?

Contributors are able to clone the Archi repository and submit Pull Requests (PRs). There is an open and active issues list to discuss problems and feature requests.

The source code licence for contributions has to be the MIT licence, and source code copyright can held by the contributor if required. There is no requirement for a Contributor License Agreement.

Where is the Continuous Integration build?

At Travis, the hosted, distributed continuous integration service used to build and test software projects hosted on GitHub - https://travis-ci.org/archimatetool/archi

Who are the main committers?

Phil Beauvoir and Jean-Baptiste Sarrodie are currently the designated committers.

How is Archi licensed?

Archi is licensed under an MIT type license.

See https://opensource.org/licenses/MIT

Who decides what features are added to Archi?

Dependent on governing factors:

  • Users
  • Phil Beauvoir
  • Jean-Baptiste Sarrodie

Any valid feature proposal is considered. Phil Beauvoir is the technical design authority who, guided by users and Jean-Baptiste Sarrodie, makes the decision on whether a feature is valid and should be incorporated into the Archi product.

The development process is:

  • Open
  • User driven
  • Dependent on resources

What is the process for feature development?

All changes to Archi are reviewed and have to be approved. The process revolves around the project presence at GitHub. Approval is subject to developer resources, and whether the feature is implementable and maintainable.

Bugs and feature requests are reported here:

https://github.com/archimatetool/archi/issues

If a feature is a user request, or it is a bug report, the code has to be implemented by Phil Beauvoir or Jean-Baptiste Sarrodie. This means the feature/bug may or may not be implemented depending on time, resources and developer inclination.

User Pull Requests (PR) can be made via the Git mechanism available on GitHub:

https://github.com/archimatetool/archi/pulls

Non-trivial features and patches should be developed in a Git branch. PRs must be developed in a fork of the main code and in a branch.

If a PR is non-breaking, contains Unit Tests (where necessary), and is maintainable then it may be approved subject to the requirements above.

A short summary of the process for getting a PR or patch approved is as follows:

  • Create a GitHub Issue
  • Discuss the Issue with Phil Beauvoir and Jean-Baptiste Sarrodie on GitHub
  • Issue a PR via GitHub, together with appropriate Unit Tests
  • Await review