TRAK & Open Source
TRAK has been released under various GNU open source licenses
- GNU Public License version 3 for
software
- UML profile for TRAK for any UML modelling tool
- MDG Technology for TRAK for Sparx Systems Enterprise Architect
- TRAK MooD 2010 Template for Salamander MooD
- rail symbols model elements
- GNU Free Document License (GFDL) for documents
- TRAK Viewpoints
- TRAK Metamodel
Why Open Source?
Lots of good reasons
- TRAK supports exchange of architecture models and collaboration
- interoperability
- architecture models are supposed to be a form of communication - don't want to tax this
- valuing others' experience
- other domains
- other disciplines - 'the TRAK enterprise' is a system that includes people, definition and tools!
- other applications
- increasing diversity of users / adding element of randomness = innovative environment
- supportability
- increasingly government requires increased use of open source products
What Does it Mean?
TRAK being open source means:
- it is in the open
- source
- discussions, development
- rationale and decision-making
- anyone can help improve the framework
- based on interest, need or experience - you don't need to be a major multinational - individuals are welcome!
- acknowledgement is recorded for work done
An idea of how it is proposed to manage TRAK is provided on the trak-community site.
What It Doesn't Mean
TRAK being open source does not mean:
- you have to get involved
- you only need get involved if you want to, have a need to improve it to meet yours (& others) needs
- it isn't ready
- We've been using this for over a year now on some big projects.
- it isn't under configuration control
- the source definition is under version control and managed
- it isn't possible for anyone to alter it and call it TRAK
- you can copy it and release it as you see fit
- the GFDL applies terms such as copyright and attribution to those involved in the development of TRAK and MODAF which have to be preserved
What Opportunities for Involvement Might There Be?
There are all sorts of things for which help is likely to be needed:
- adding knowledge to supporting documentation like wikis
- maintaining key documentation
- helping check for consistency across documents and with the products released
- developing / documenting applications of TRAK views and models
- different domains
- different points of process / life cycle
- developing example views
- submitting case studies, feedback
- spotting and submitting errors or requests for features
- getting involved in a TRAK Working Group and extending TRAK
- ontology? OWL?
- tool support
- user interface of TRAK and TRAK views/models
The point is that there are likely to be positions for all sorts of people of all disciplines and at all levels - not just technical or software:
Modification Date: March 3, 2018