FIWARE Community Governance Model
The FIWARE Foundation, the legal entity which will drive and govern the sustainability of the FIWARE Community, is going to be established soon, expected in September 2016. In this context, the FIWARE Community Governance Model may be subject to further tuning and eventual modifications in order it to be compliant with the requirements coming from the FIWARE Foundation. Such changes will be incorporated in the Governance Model as soon as they are consolidated and approved by the Technical Steering Committee. Such updates are expected to be minimum and anyway not changing the basic philosophy and governing principles of the FIWARE Community Governance Model as made public in the following.
- 1. Definitions
- 2. FIWARE Community Mission
- 3. Membership of the FIWARE Community
- 4. FIWARE Community structure and procedures
- 5. Code of Conduct
- 5.1. Compliance
- 5.2. Acting in the (sole) interest of the FIWARE Community
- 5.3. Information
- 5.4. Confidentiality – Discretion
- 5.5. Integrity – professionalism and respect
- 5.6. Independence
- 5.7. Commitment of governance bodies members
- 5.8. Corruption – bribery – fraud
- 5.9. Human dignity – discrimination – inter-relationships
- 6. Bootstrapping the FIWARE Community
FIWARE is a rich suite of platform components, called FIWARE Generic Enablers (GEs), which can be picked and integrated together to build software platforms easing the creation, provision and exploitation of Smart Applications. Some FIWARE GEs can be used to build a Cloud Hosting Service with advanced capabilities where smart applications can be provisioned, others can be used to build a Marketplace Service enabling the commercialization of smart applications and data, while the rest of FIWARE GEs implement general-purpose functions that ease the development of Smart Applications. These latter FIWARE GEs export open standard APIs, typically offered “as a Service” from dedicated servers or from public/private Clouds (compliant with the FIWARE Cloud reference architecture or not).
FIWARE GE specifications (including API specifications) are public and royalty-free. Besides, an open source reference implementation of each FIWARE GE is available, accelerating the appearance of multiple commercial FIWARE-compliant platform providers as well as ensuring the interoperability and portability of Smart Applications. This leaves users the ability to decide who will operate the environment where applications and, even more importantly, data will be hosted. As a result, FIWARE becomes an open alternative to existing proprietary incumbent Internet platforms.
FIWARE Reference Architecture
FIWARE GEs have been designed so they can work stand alone while, at the same time, can be integrated to build certain Cloud Services following a given Reference Architecture or, taking the most out of their capability of integration, build a rather powerful and comprehensive Platform Reference Architecture for Cloud-based Smart Applications.
Under this assumption there is not just a single FIWARE Reference Architecture but various Reference Architectures depending on what the platform to build and deploy will serve for.
Thus, the FIWARE Cloud Reference Architecture describes how FIWARE GEs in the Cloud chapter can be integrated together to build the architecture of an advanced Cloud Hosting Service. Similarly, the FIWARE Business Framework Reference Architecture describes how certain FIWARE GEs can be integrated together in order to build the architecture of a marketplace service enabling the commercialization of apps and data.
All the FIWARE GEs except those belonging to Cloud and the Business Framework can be integrated together to build the Reference Architecture of platforms particularly suited to support the development of Smart Applications, i.e., applications that rely on the capability to gather context information and then be able to process and analyze this information to implement an intelligent behaviour combined with an enhanced user experience. This Reference Architecture is referred as the FIWARE Smart Reference Architecture.
Finally, the FIWARE GEs altogether complete the FIWARE Reference Architecture that integrates the FIWARE Cloud, Business Framework and Smart Reference Architectures.
FIWARE Generic Enabler (GE)
A FIWARE Generic Enabler refers to a building block of the FIWARE Reference Architecture, supporting reusable and commonly shared functions serving a multiplicity of use cases across various application domains.
The specifications of a FIWARE Generic Enabler refer to the set of specifications establishing requirements to be fulfilled by compliant implementations of the given FIWARE Generic Enabler, particularly with respect to Application Programming Interfaces (APIs) and interoperable protocol that are required in order to work with other compliant implementations of other FIWARE Generic Enablers of the FIWARE Platform.
The specifications of any FIWARE GE are public and royalty-free. The approach taken in the definition of FIWARE GE specifications is an implementation-driven approach, meaning that there is always an open source product working as the reference implementation for each FIWARE GE.
FIWARE Generic Enabler Reference Implementation (GEri)
A FIWARE GE reference implementation (GEri) is an open source software product offered as reference implementation of a given FIWARE GE specification. It serves as a definitive interpretation of the specifications.
There is one and only one GEri per GE. A GEri may not necessarily implement the whole set of specifications of a given FIWARE GE at a given point in time, but there should be plans to implement the complete set of specifications in the near future.
A FIWARE GEri must satisfy the following conditions:
- 1. The source code of the GEri is available under well-known Open Source Software license listed in http://opensource.org/licenses/category and it should not force software using the GEri to be released as open source nor prevent that the GEri can be offered as a Service.
- 2. Development of the GEri should follow the common practices defined for the development of all FIWARE GEris in the FIWARE Community.
- 3. There is a well identified set of GEri Owners and Active Contributors.
- 4. The GEri is accompanied by Installation, Administration, and Developers’ Guides following the recommended practices (currently under finalisation) adopted in the FIWARE Community. The Installation Guide includes also the related Sanity Check procedures which help to test when an executing GEri instance is working properly.
- 5. The GEri is accompanied by Training Material suitable to be published in the FIWARE Academia.
Incubated Generic Enabler (iGE)
An Incubated Generic Enabler (iGE) is an open source software product whose owner has proposed for adoption as reference implementation of a new FIWARE GE to be integrated as part of the FIWARE Reference Architecture because:
- 1. it provides functionality that is generic and independent with respect to application domains;
- 2. the corresponding GE would cover a gap in the FIWARE Reference Architecture so the product can fit/integrate well with existing FIWARE GEris;
- 3. the specifications are open and royalty-free; and
- 4. it adheres to requirements defined for FIWARE GEris (see definition of GEri).
Incubated Generic Enablers will be advertised and their traction among the wider community of developers as well as the opportunity to integrate them within FIWARE will be assessed so a decision can be taken about whether they should become FIWARE GEs/GEris or not.
The process that will be followed to determine how an incubated GE/GEri can become a FIWARE GE/GEri is transparent and neutral as described in a following section of this document.
FIWARE Generic Enabler Implementation (GEi)
A FIWARE GEi is a product that implements a set of FIWARE GE specifications, which can work as alternative product to existing FIWARE GEris. This means that multiple implementations of the same FIWARE GE specifications can exist.
In general, a FIWARE GEi is a product whose owner claims that it is compliant with the currently supported release of the specifications of a given FIWARE GE and can be published in the FIWARE Catalogue for such reason. However, this does not mean that the FIWARE community will necessarily endorse it nor will verify its FIWARE compliance.
A GEi which, complying with all the rules of being a GEri, is proved to be more suitable than the corresponding existing GEri (e.g. better designed and coded, exhibiting better performance, or better ensuring the sustainability) can be considered by the FIWARE Technical Steering Committee (ref. to the relevant section) for promotion as GEri replacing the current GEri.
The FIWARE Catalogue (http://catalogue.fiware.org) is the central web site where the entire FIWARE technology offering is publicly available. Each entry in the Catalogue provides information about a product which corresponds to a FIWARE GE implementation (GEi) or to a FIWARE GE Reference Implementation (GEri). For each FIWARE GEi/GEri, there is a set of structured pages providing access to the product software and documentation, information about existing public instances as well as how to create an instance, and the terms and conditions for its usage.
Besides FIWARE GEris and GEis, the FIWARE Catalogue also provides access to Incubated GEris.
The FIWARE Academy (https://edu.fiware.org) is the eLearning system dedicated to manage the education and training contents for the FIWARE technology. Users, anytime and anywhere, can chose from a public list of lessons in order to get useful information to improve the knowledge on how to use FIWARE enablers.
A FIWARE instance is a runtime environment where a number of FIWARE GEris/GEis, bound to a given FIWARE Reference Architecture, are deployed and offered “as a Service”. Therefore the following types of FIWARE instances currently exist:
- – FIWARE Cloud instance, which implements the FIWARE Cloud Reference Architecture.
- – FIWARE Marketplace instance, which implements the FIWARE Business Framework Reference Architecture.
- – FIWARE Smart instance, which implements the backend part of the FIWARE Smart Reference Architecture. Note that there are GEris that are designed to run on the client side or closer to devices. They are not intended to be part of a FIWARE Smart instance.
- – FIWARE Full instance, which integrates a FIWARE Cloud instance, a FIWARE Marketplace instance and a FIWARE Smart instance altogether.
FIWARE Lab (http://lab.fiware.org) is a FIWARE Full instance which works as a non-commercial sandbox environment where innovation and experimentation based on FIWARE technologies can take place. Entrepreneurs and individuals can test FIWARE technologies as well as their applications on FIWARE Lab, exploiting Open Data published by cities and other organizations. FIWARE Lab is deployed over a geographically distributed network of federated FIWARE Lab nodes.
FIWARE Lab Node
A network of datacenters on top of which a FIWARE Lab Cloud region has been deployed and is operated by a concrete organization.
FIWARE Ops is a collection of tools that eases the deployment, setup and operation of FIWARE instances by platform providers. It is designed to help expand the infrastructure associated to a given FIWARE instance by means of federating additional nodes (datacenters) over time and allowing cooperation of multiple Platform Providers. FIWARE Ops comprises the suite of tools used to build, operate and expand the FIWARE Lab.
FIWARE App Developer
A FIWARE App Developer is a developer who, taking advantage of FIWARE Generic Enablers, designs and builds new innovative applications/services bringing a radical optimization of processes, exhibiting a smart, context-aware, behaviour.
This is the document which describes the foreseen evolution of the various FIWARE GEs/GEris. It is produced by the the FIWARE Chapters (ref. to the relevant section) based on internal and external inputs. It is approved by the FIWARE Technical Steering Committee which coordinates its publication. The FIWARE Roadmap is publicly available in:
Enablers that complement FIWARE GEs/GEris to ease the development of applications or solutions in specific domains (e.g., eHealth, Smart Agrifood, Smart Cities, etc) are referred as Specific Enablers(SEs). It is recommended that
- – Specific Enabler specifications are public and royalty-free;
- – Specific Enabler specifications are accompanied by an open source reference implementation (SEri);
- – Specific Enablers are designed with no or very minimal overlap with FIWARE GEs/GEris, avoiding to wrap those. In case they are built as specialisation of FIWARE GEs/GEris they can show also the APIs from the specialised FIWARE GE/GEri but without renaming them.
SEris would be published in a specific section of the FIWARE Catalogue.
Domain-specific FIWARE-based Platform
It is a platform, developed based on the combination of a set of FIWARE GEs/GEris and Specific Enablers.
2. FIWARE Community MissionThe FIWARE Community is an independent open community whose members are committed to materialise the FIWARE mission, that is: “to build an open sustainable ecosystem around public, royalty-free and implementation-driven software platform standards that will ease the development of Smart Applications in multiple sectors”.
A key goal of the FIWARE Community is to maintain and further develop FIWARE technologies. There is vibrant community rapidly growing around FIWARE where hundred of developers are contributing to releases of the FIWARE GEs. One of the aims of the FIWARE Community is to organise such community of developers in a way to make it open and efficient, and recognised worldwide due to the adoption of best practices.
However, the FIWARE Community is not only formed by contributors to the FIWARE platform but also those who contribute in building the FIWARE ecosystem and making it sustainable over time. As such, individuals and organizations committing relevant resources in FIWARE Lab activities or activities of the FIWARE Accelerator, FIWARE mundus or FIWARE iHubs programmes are also considered members of the FIWARE community.
Independence in decision making, transparency and openness are the cornerstone and founding principles of the FIWARE Community and should be maintained in the future.
The FIWARE Community aims at preserving and improve the FIWARE culture in terms of:
- – letting technical people make technical decisions
- – marketing the success and contributions of community members
- – organising a strong ecosystem of companies and academia who can succeed and contribute to further progress
- – encouraging and rewarding contribution in all forms, such as testing, documenting, translating, integrating, extending, educating, financing, training, supporting, facilitating, evangelizing, designing, operating at scale or art making
An important part of the “FIWARE Culture” is the proper balance between the individuals who invest their time and effort, the companies that build businesses on FIWARE and the application developers who build and deploy new applications based on FIWARE technologies. The structure of the the FIWARE Community encourages all forms of contributions and provides safeguards against losing the balance between the various members of the community.
The work in the FIWARE Community is organised in dedicated teams: FIWARE Chapters, Technical Committees and Ecosystem Support Committees. FIWARE Chapters and Technical Committees deal with coordination of activities that are of technical nature, while FIWARE Ecosystem Support Committees are focused in non-technical relevant activities such as those linked to the FIWARE Accelerator, the FIWARE Mundus or the FIWARE iHubs programmes.
3. Membership of the FIWARE CommunityThe FIWARE Community is a community made of members who are investing in the success of FIWARE. The FIWARE Community has three types of membership: Individual, Core, and Regular.
Membership registration is a continuous process. Requests for Regular and Core membership are managed by the Board of Directors (BoD) which discusses and, eventually, approves them during its meetings. the FIWARE Community Membership is thus a fixed item in the BoD meeting agendas.
“Individual Members” are persons who participate on their own or as part of their paid employment, actively contributing to activities of the FIWARE Community. Individual Members do not pay any fee. Any person who is actively contributing to activities of the FIWARE Community as part of his/her work for a company or organization that is Regular or Core Member will qualify as Individual Member.
Individual Members have to register as such in order to exercise their right to run for, and vote for, a number of leadership positions. Requirements to be fulfilled to register as an Individual Member are:
- – Actively contribute to activities of FIWARE chapters (see specific section below) or Ecosystem Support Committees.
- – Expected to be constructive and courteous, adhering to the FIWARE Community Code of Conduct.
- – Wear the FIWARE hat and always act with integrity.
Individual Members elect representatives to the FIWARE Technical Steering Committee and FIWARE Chapter Leader positions if they are Chapter Active Contributors (see below the specific sections).
“Core Members” are companies which make a significant strategic commitment to FIWARE resulting in a significant level of investment.
Requirements for eligibility as Core Member are:
- – Corporate strategy aligned with FIWARE Mission.
- – Appoint a member to the Board of Directors, who must adhere to the FIWARE Community Code of Conduct.
- – Provide substantial investment to support ongoing activities: direct funding, in kind (e.g. individuals acting as developers, testers, trainers) or in resources (e.g., legal resources, marketing resources, ICT resources) or both.
- – Pay a FIWARE Core Member fee.
“Regular Members” are companies and other organizations (e.g., research organizations) which provide a significant investment, but at a lower level than Core Members. Requirements for Regular Members are:
- Corporate strategy aligned with FIWARE Mission.
- Elect representatives to the Board of Directors, who must adhere to the FIWARE Community Code of Conduct.
- Provide resources for ongoing activities (e.g. developers in chapter activities or people with relevant skills in Ecosystem Support Committees).
- Pay a FIWARE Regular Member fee. This fee is based on company size to make it accessible to different companies and organizations.
- Regular Members elect, as a class, their representatives to the Board of Directors.
[under finalisation, it will cover concrete steps for an organization/person to become member]
4. FIWARE Community structure and procedures
BoD members are expected to advocate for the FIWARE Community in its entirety.
Core Members appoint half of the seats in the BoD while Regular Members elect representatives for the other half of the seats, thus the number of Regular Member seats always matches the number of Core Member seats. The several Officers, if not already BoD members, the FIWARE Foundation’s Executive Director and the FIWARE/Domain Technical Steering Committee Chairs are permanently invited to BoD meetings. The Chief Executive Officer chairs the BoD meetings.
Key policies require a 70% supermajority for changes (e.g. Trademark Policy, Governance Structure). Changes to the Bylaws, including member rights, would require approval by a vote of the whole set of Members of the FIWARE Community.
The owners of a FIWARE (or Incubated) GE are a set of persons and/or organisations responsible for the creation and/or maintenance either corrective and evolutive of:
- – the GE specifications, or
- – the GEri implementing the GE specifications, including documentation, or
- – both
Intellectual Property (IP) on an individual FIWARE/Incubated GE/GEri is hold by the corresponding GE/GEri owners. The IP of FIWARE GE/GEris will be shared with the FIWARE Foundation once it is created.
FIWARE/Incubated GE Active Contributors
GE owners, together with people voluntarily playing a relevant role contributing to the maintenance/evolution of a given GE specifications or reference implementation source code, or to the support, dissemination or training activities associated to a given GE/GEri, are considered Active Contributors of the GE/GEri.
Becoming a GE Active Contributor shall be open to any FIWARE Community individual member, who, being properly skilled, is willing to contribute. An individual will be recognized as Active Contributor of a GE/GEri by the decision of already recognized Active Contributors of the GE/GEri.
FIWARE GE Leaders
A GE Leader (“GEL”) coordinates the day-by-day work of the GE Active Contributors of a GE. He/she drives the specification, implementation, evolution, maintenance, testing and release of the GE and resolves technical disputes within the team.
Similarly as chapters, each GE community, eventually formed by a cooperative set of people belonging to different organisations, should be self-managing by the contributors, and all disputes should be resolved through active debate and discussion by the community itself. However if a given debate cannot be clearly resolved, the GEL can decide the outcome.
There are two types of Chapters: Architecture and Mission Support chapters.
- – Architecture Chapters: these chapters are those responsible for the development of FIWARE/Incubated Generic Enabler (GE) specifications and their open source reference implementations. Activities with regard to a particular GE are carried out by the Active Contributors of that GE.
- – Mission Support Chapters: these chapters are those dealing with technical activities not specifically related to specification and open source reference implementation of GEs. The FIWARE Ops and FIWARE Lab chapters, coordinating the development of the FIWARE Ops suite of tools and the operations of the FIWARE Lab, respectively, are examples of FIWARE Mission Support Chapters.
Both kind of chapters hold their own repository where all the chapter achievements are kept (in the case of Architecture Chapters, these repositories integrate references to the repositories of the individual GEs). Achievements can be in the form of: code, documentation in various forms, web page updates (including press releases, presentations, etc.). The various chapter repositories represent the FIWARE asset and are of critical importance.
Technical work within the FIWARE Chapters is intended to advance ICT technologies. Such advancement can be in the form of implementing brand new technologies, but also evolving/adapting existing technologies eventually starting from good available technologies even if produced from the outside of the FIWARE Community. In this respects good and mutual beneficial relationships with other relevant communities (e.g. OpenStack, Apache) are in scope of the FIWARE Mission.
FIWARE Chapter Active Contributor (CAC)
Individual members that perform updates in the contents of a Chapter repository are referred as Chapter Active Contributors. The repository should also store the meeting minutes and work progress assessment documents; however such documents does not represent sources for a person being accounted as a Chapter Active Contributor.
FIWARE Chapter Leaders
A main and deputy Chapter Leader (“CL”) are elected per each FIWARE Chapter by that Chapter Active Contributors. They manage the overall operations of a chapter, drive the chapter goals keeping the chapter consistency, and resolve technical disputes within their chapter. In this respect the main CL, or when needed his/her deputy, is the ultimate responsible for the good and timely progress of work within the chapter.
Architecture Chapter Leaders specifically have to ensure that GEs within the chapter can integrate well together and with GEs from other chapters, overall building a coherent and comprehensive FIWARE Reference Architecture.
Each chapter community should be self-managing by the contributors, and all disputes should be resolved through active debate and discussion by the community itself. However if a given debate cannot be clearly resolved, the CLs can decide the outcome.
Although the CLs (main and deputy) are generally not involved in decisions at GE level, they still has oversight over GE-specific decisions, especially when they affect other GEs in the chapter, other chapters, or might negatively affect to the general FIWARE Reference Architecture.
Each main CL is the ultimate responsible for the good shape of his/her chapter repository.
The FIWARE Technical Steering Committee (TSC) is tasked with providing the coordination of technical activities in the FIWARE Community, i.e., all FIWARE Chapters, as defined above. It decides on issues affecting multiple chapters, forms an ultimate appeals board for technical decisions, and generally has oversight over all the FIWARE technical tasks.
Although the FIWARE TSC is generally not involved in chapter-internal decisions, it still has oversight over chapter-specific decisions, especially when they affect other chapters or might negatively affect to the general FIWARE Reference Architecture. Given their relevance, overall rules for the management of FIWARE Chapter repositories are defined by the FIWARE TSC, while their actual implementation can be Chapter specific.
Current efforts or teams which want to be recognized as a Chapter should file a motion to the FIWARE TSC. The FIWARE TSC has ultimate authority over which chapters are accepted or declined.
The FIWARE Technical Steering Committee is independent and elected, with the ability to change its own structure and processes. Working with the Chapter Leaders (CL), the technical committee sets technical policies that apply cross GEs and determines incubation and incorporation of new FIWARE GEs with their corresponding open source reference implementation (GEri). They also decide on the deprecation of existing FIWARE GEs/GEris.
Technical Committee members are:
- – two representatives of each FIWARE Chapter, which are the corresponding main and deputy CLs.
- – the FIWARE Community individual members voted by the FIWARE Chapter Active Contributors, up to one third of the number of chapter representatives.
- – a representative of each Core/Platinum Member of the FIWARE Foundation.
The following clarifications holds:
- – Even if the organisation of a Core/Platinum Member is the same of the organisation of any other TSC members this does not give any specific rights of the Core/Platinum member over the others of the same organisation being roles different (ref to the Code of Conduct).
- – the representatives of Core/Platinum members in the TSC cannot exceed in number to the total number of the members of the other two categories. If this occurs the TSC shall define specific contingency rules (e.g. increase the number of FIWARE Chapter representatives).
A representative for each Domain Technical Steering Committee is invited as observer. Such representative guarantees proper flow of information between the FIWARE TSC and the DTSCs.
All TSC members must be FIWARE Foundation Individual Members. It is possible to cumulate any other role, including the FIWARE Foundation BoD Chairman or FIWARE Chief Executive Officer, with a TSC seat.
On a yearly-base, the TSC proposes one of its members to act as the TSC Chair. In case of multiple candidates, it may use a single-winner election method to decide the result. The TSC Chair is responsible for making sure meetings of the TSC are held according to the rules described below, and for communicating the decisions taken during those meetings to the BoD and the FIWARE community at large. It may be revoked under the conditions described in the the FIWARE Community bylaws.
TSC meetings happen publicly, weekly using the meeting tool agreed among TSC members. The meeting time should be decided among TSC members in principle to kept stable on yearly-base. The TSC maintains an open agenda on the FIWARE wiki or some other publicly available collaboration tool (e.g., Google docs). A TSC meeting is automatically called if anything is posted in the open agenda by one of its members at least one week before the meeting time. For a meeting to be actually held, at least half of the members, rounded up in case of odd numbers, need to be present. Non-members affected by a given discussion are strongly encouraged to participate to the meeting and voice their opinion, though only TSC members can ultimately cast a vote.
Decision making process
Before being put to a vote, motions presented before the TSC should be discussed publicly on the general FIWARE mailing-list for a minimum of 4 business days to give a chance to the wider community to express their opinion. At a given TSC meeting, TSC members can vote positively, negatively, or abstain.
Decisions need more positive votes than negative votes (ties mean the motion is rejected), and a minimum of positive votes of at least one third of the total number of TSC members, rounded-up in case of odd numbers of chapters.
When a TSC member is unable to make a meeting he/she is then encouraged to nominate a proxy that will represent his/her opinion and vote on his/her behalf during the meeting. Only members really present at the meeting (directly or proxied) can vote. A TSC member may proxy only another TSC member, as nobody should ever represent more than two votes.
Election for TSC seats
TSC seats are completely renewed every 12 months. A separate election is run for each chapter seats and for the additional seats. These elections are collectively held 5 weeks prior to each FIWARE Summit meeting to take place every 12 months, with nominations due 6 weeks prior to the FIWARE General Assembly and elections held open for no less than five business days.
The system used to run elections will be decided by the TSC.
Voters of CLs and TSC representatives
Voters for the election of CLs in a given chapter are the CACs of that chapter. Voters of TSC seats are the whole set of CACs.
If a person is CAC for more than a chapter he/she is an active elector of CLs for each concerned chapter. However, he/she shall have only one vote for electing the individual additional seats of the FIWARE TSC.
Candidates for CLs and TSC representatives
Any CAC can propose his/her candidacy for the corresponding chapter CLs (main and deputy) election. CL seats are eligible to run for re-election each cycle, provided they continue to meet the criteria.
Since each chapter must have representatives in the TSC, if no candidates show, the GELs of the two most used GEris in the chapter are nominated by default.
Candidates for additional TSC seats
Any CAC can propose his/her candidacy for one of the independent seats in the TSC, those not linked to CLs. These seats are eligible to run for re-election each cycle, provided they continue to meet the criteria.
Amendments to this Technical Committee charter shall be proposed in a special motion, which needs to be approved by the affirmative vote of at least two-thirds of the total number of TSC members (rounded up in case of odd numbers of members).
A Domain Technical Steering Committee (DTSC) is a FIWARE Community committee where decisions are taken, similarly as the FIWARE TSC, about the Specific Enablers and Domain Specific Frameworks of a singular application domain or market sector. To this extent several DTSCs can exists in the FIWARE Community one per each domain.
DTSCs are created upon approval of the BoD, based on requests they may receive from organizations willing to create and actively support them.
Domain Technical Steering Committee members are all the Active Domain Contributors (ADC) as it is not expected that a DTSC to be further subdivided in chapters. Of course if this applies or if the number of ADCs is too high for effective and efficient discussions the DTSC can autonomously decide for a different membership and structure.
The DTSC governance model is the same of that of the FIWARE TSC. However, each DTSC can autonomously amend based on specific local factors including number of SEs, number of members.
A DTSC shall have a DTSC Chair and, possibly, a DTSC Architect which are elected within the ADCs of that domain. Each DTSC nominates the representative to the FIWARE TSC which can be the DTSC Chair him/herself or the DTSC Architect.
DTSCs have to comply with recommendations given from the FIWARE TSC regarding usage of FIWARE.
ESCs perform their day-by-day work overseen by the FIWARE Community BoD or its appointed deputies.
However, associations linked to a given open source product have never involved in government of the corresponding project/community as open source projects and communities use to be governed by their active contributors, therefore based on meritocracy. This is the case of the FIWARE Community where the CACs are key. Of course, one given entity (or individual) may be at the same time a the FIWARE Community CAC and a member of an association linked to FIWARE.
Similarly, open source project/communities have never governed associations created around the products they develop. Those association simply flourish, each defining their own governance rules and mission, some of them showing sustainability over time, others not. In some cases, the open source project/communities have established some rules that associations have to comply with in order to have the right to use the brand of the open source project/community. The FIWARE Community will not be involved in the governance of any FIWARE related associations. However, it may define rules that associations may need to comply if considered necessary.
The following figure depicts the GE Incubation and Incorporation in the FIWARE Catalogue.
The process is as follows:
- 1. A team either belonging to a FIWARE Chapter or from outside the FIWARE Community proposes a new GE, eventually already equipped with its GEri, to the TSC. This proposal may or may not address a particular element in the FIWARE Roadmap.
- 2. If the proposal comes from outside the FIWARE Community, the TSC asks an opinion to the relevant FIWARE Chapter which shall come with an answer within 15 days. Although important the answer is not binding the decision of the TSC.
- 3. Depending on the completeness level of the proposal this step can be skipped. If the proposal is not equipped with the corresponding GEri or if the GEri is not complete or not judged to be complete, if the TSC decides to go further, the proposing team is now empowered to provide the complete GEri which must reach the TSC within the agreed time.
- 4. Based on the final proposal the TSC decides to promote the GE to be an Incubated GE or to discard it. If it becomes an Incubated GE the team has 15 days to upload the GE in the FIWARE Catalogue. In this step an incubated GEri expert (usually, but not limited to the incubated GE owner him/herself) will be appointed for the period of one month at the end of every incubation cycle, in order to support the FIWARE Technical Steering Committee (ref. the relevant section below) in gathering the answer to questions, or results of tests, notably security and performance tests, that will support their decisions.
- 5. As a continuous quality assessment process measures for the following indicators are collected from the FIWARE users:
- a. number of downloads of the GEri source code
- b. number of applications experimenting and/or using the GEri from FIWARE Lab
- c. number of positive feedback
- d. number of negative feedback
- e. number of feedback requesting modifications and/or extensions
- f. total number of feedback
- g. feedback trend
- h. number of bugs identified
- i. ratio of bugs fixed over bugs identified
- j. trend of bugs identification
- k. …
- 6. After a period of 3 months the TSC shall make the assessment of the Incubated GE/GEri based on the objective metrics listed above. The outcome of the assessment can be:
- a. the incubated GE is promoted as a regular GE. The FIWARE Catalogue shall be updated and a proper announcement made
- b. the incubated GE is judged by the TSC not mature enough, but still holding some potential to be promoted regular GE. This case the GE stays for another assessment period of 3 months in the incubation state (step 5 above) during which the GE team is called to make actions in order to improve the marketability of the GE (e.g. bug fixing, adding new functionalities, adding new documentation and training material, promoting the GE)
- c. the incubated GE is deprecated. This case a proper communication shall be issued.
Under certain special conditions identified and explicitly approved by the Technical Committee the incubation process can be fast-tracked and as such over-passed provided that:
- – the proposed GE/GEri complies with the rules described in the “Definition” section of this Governance Model document
- – A GEri expert (usually, but not limited to the GE owner him/herself) is available for a period of one month to support the Technical Committee to perform all the tests, notably security and performance, the Technical Committee intends to make.
The following figure depicts the GE deprecation process.
The process is as follows:
- 1. As a continuous quality assessment process measures for the following metrics are collected from the FIWARE users on top of each GE published as regular GE in the FIWARE Catalogue:
- a. number of downloads of the GEri source code
- b. number of applications experimenting and/or using the GEri from FIWARE Lab
- c. number of positive feedback
- d. number of negative feedback
- e. number of feedback requesting modifications and/or extensions
- f. total number of feedback
- g. feedback trend
- h. number of bugs identified
- i. ratio of bugs fixed over bugs identified
- j. trend of bugs identification
- k. …
- 2. Every 3 months the TSC shall make the assessment of each GE based on the objective metrics listed above. The outcome of the assessment for each GE can be:
- a. the assessment is fully satisfactory and the GE is kept as a regular GE.
- b. the GE is judged by the TSC not satisfactory enough, but still holding some potential to be kept as regular GE if certain recommendations issued by the TSC, eventually based on FIWARE users feedback, will be satisfied. In this case, the GE becomes quarantined. During this period the GE owner team is called to make actions in order to improve the GE starting from the TSC recommendations, but also including other actions such as bug fixing, adding new functionalities, adding new documentation and training material, promotion of the GE. This case the process goes back to step 1
- c. the incubated GE is deprecated and it will be unpublished from the FIWARE Catalogue. This case a proper communication shall be issued.
5. Code of ConductThe FIWARE Community’s policy is to conduct its business affairs honestly and in an ethical manner. This Code of Conduct provides a general statement of the expectations of the FIWARE Community concerning the ethical standards that each the FIWARE Community member should adhere to while acting on behalf of the FIWARE Community under the assumption that the FIWARE Community pride itself on building a productive, happy and agile community that can welcome new ideas in a complex field, and foster collaboration between groups with very different needs, interests and goals.
This Code of Conduct does not cover every issue that may arise, but it sets out basic principles to guide all the FIWARE Community members. All of the FIWARE Community members must conduct themselves accordingly and seek to avoid even the appearance of improper behavior. This Code of Conduct applies to all the FIWARE Community members regardless their role in the FIWARE Community itself. Conduct in violation of this policy is unacceptable in the workplace and in any work-related setting outside the workplace. Any member who violates this Code of Conduct will be subject to disciplinary action, up to and including termination of his/her FIWARE Community membership.
This Code of Conduct covers also individuals behavior as members of the FIWARE Community, in any forum, mailing list, wiki, web site, IRC channel, public meeting or private correspondence. the FIWARE Community Members and governance bodies are ultimately accountable to the FIWARE Community Board of Directors.
This Code of Conduct should be interpreted in light of the purpose of the FIWARE Community, and composition of its membership. This Code of Conduct should not be read to restrict any individual covered by this Code of Conduct from performing his or her fiduciary duties to a FIWARE Community Core or Regular Member.
They shall proactively promote ethical behaviour as a responsible member among peers, in the framework of the FIWARE Community and in the community.
The BoD members and the TSC members must base their decisions on a proper consideration of the overall good of the FIWARE Community, and act in a neutral way must not act in the interest of individual stakeholders or groups of stakeholders over the interest of the FIWARE Community as a whole.
The work carried out in the FIWARE Community is aimed to be used by other people, and the FIWARE Community work in turn will depend on the work of others. Any decision taken will affect users and colleagues, so they should be taken having all those consequences into account when making decisions. the FIWARE Community has a global base of users and of contributors. Even if it is not obvious at the time, contributions to the FIWARE Community activities will impact the work of others.
The FIWARE Community is a community based on transparency and openness, however there are situations, defined by the BoD, in which the BoD members, the TSC members and any other persons who are acting in their capacity as members of bodies or committees of the FIWARE Community should maintain maximum discretion regarding any fact and information that comes to their attention when performing their duties and they should maintain confidentiality of deliberations, discussions and decisions within the various FIWARE Community bodies. This case they should not (i) communicate, in whatever form, to any non-authorised person any document or information that has not been made available to the general public, and not (ii) use document or information obtained in the performance of their duties for any other purpose than the performance of their duties. They remain committed to this obligation even after termination of their duties with the FIWARE Community. For the avoidance of doubt, the confidentiality of deliberations, discussions and decisions within the BoD or the TSC that are not confidential has to be preserved within the respective body.
Each Individual Member within the FIWARE Community shall at all times act honestly, in good faith and in a professional manner. Following are the cornerstone principles:
- The FIWARE Community members treat one another with respect. Everyone can make a valuable contribution to the FIWARE Community: not necessarily everybody always agree, but disagreement is no excuse for poor behavior and poor manners. Some frustration now and then may arise, but it is not acceptable to allow such frustration to turn into a personal attack. It’s important to remember that a community where people feel uncomfortable or threatened is not a productive one. It is a must for the FIWARE Community members to be respectful when dealing with other contributors as well as with people outside the FIWARE Community and with users of FIWARE technologies.
- Collaboration is central to the FIWARE Community as a well established principle in the whole free software community. This collaboration involves individuals working with others in teams within the FIWARE Community, teams working with each other within the FIWARE Community, and individuals and teams within the FIWARE Community working with other projects outside. Wherever possible, it is important to work closely with upstream and downstream projects and others in the free software community to coordinate FIWARE technical, advocacy, documentation, and other work.
- The FIWARE Community work should be done transparently and should involve as many interested parties as early as possible. If a different approach is decided, early information through the FIWARE Community dedicated channels should be made, together with regularly information on work progress providing as much as possible always complete information.
- Disagreements, both social and technical, happen all the time and the FIWARE Community is no exception. It is important that to resolve disagreements and differing views constructively and with the help of the FIWARE Community and the FIWARE Community processes as appropriate. Governance bodies at all levels are there to help to decide the right and best course for the FIWARE Community. When a member’s goals differ dramatically from those of the others, it is encouraged and appreciated the creation of alternative implementations, so that the community can test new ideas and contribute to the discussion.
- Nobody knows everything, and nobody is expected to be perfect in the FIWARE Community. Asking questions avoids many problems down the road, and so questions are encouraged. Those who are asked questions should be responsive and helpful. However, when asking a question, care must be taken to do so in an appropriate forum.
The FIWARE Community BoD members and the TSC members must always use independent judgment in the exercise of their mandate and they cannot receive voting instructions, except for instructions provided by a member to another member as his/her proxy holder.
If a member of the BoD or the TSC votes against a resolution of the BoD or the TSC, he/she must nevertheless publicly support that resolution if it has been adopted by the FIWARE Community. If a BoD or TSC member cannot reconcile this duty of obedience with his/her conscience, he/she must resign from the relevant body.
The BoD members and the TSC members of the FIWARE Community should be familiar with the FIWARE Community’s activities, organisation, financial situation, culture and legal framework.
The BoD members and the TSC members of the FIWARE Community should have the necessary time and expertise to perform their duties. In case this is no longer the case, they should resign.
The BoD members and the TSC members of the FIWARE Community should be present at each meeting of the BoD or the TSC respectively, unless there is a good justification, and they should well prepare each meeting.
The BoD members and the TSC members of the FIWARE Community shall not offer to actual or potential business relationships nor solicit or accept from them any benefits that do not fall within the customary practices for business gifts.
The BoD members and the TSC members of the FIWARE Community shall achieve responsible use of and control over all assets and resources employed or entrusted and shall not use any assets belonging to the FIWARE Community for their personal benefit or for any benefit other than that of the FIWARE Community.
The BoD members and the TSC members of the FIWARE Community shall not commit or participate in any fraudulent acts and shall immediately report any fraudulent acts committed by others.
Mailing lists and web forums are an important part of the FIWARE Community collaboration platform. This Code of Conduct applies to members behavior in those forums too. In addition to what set before in this Code of Conduct, the following principles also apply when using such tools:
- valid email addresses to which direct responses can be made shall be used;
- flamewars, trolling, personal attacks, and repetitive arguments are elements of misbehaviour and should be avoided.
6. Bootstrapping the FIWARE Community
- Technical Chapters
- Cloud Hosting
- Data/Media and Context Management
- IoT Services Enablement
- Web-based User Interfaces
- Apps/Service and Data Delivery
- Advanced Middleware, Interfaces to Networks and Robotics
- Mission Support Chapters
- FIWARE Global Reference Architecture
- FIWARE Ops
- FIWARE Lab
- FIWARE Quality Assurance
- FIWARE Support Tools
Other expected ESCs to operate since the beginning are those linked to the FIWARE Academy programme, the FIWARE Accelerator programme and the FIWARE Mundus programme.