This community’s purpose is to encourage creativity
in the financial industry, to create an environment where ideas are seeded and brought to ripeness to the benefit of all.
Take for example the payments industry; the processing of payments has reached a high level of maturity, payments became ubiquitous and a commodity in the financial ecosystem.
FinTP is an open source financial transactions processing application meant to be used as an open platform in a strictly regulated market. By achieving a large footprint within its target market, FinTP will push financial transactions interoperability forward – from the current message syntax standard layer towards semantic interpretation.
The rules governing this community are meant to ensure the FinTP release is managed to the benefit of all, they are not intended to constrain in any way contributions. We aim to free creativity and brains from reinventing the wheel, as it happens in a closed traditional environment, and allow them to take advantage of the benefits of an open approach.
This community is governed by the following set of principles:
Openness. Full and free access to sources and releases.
Inclusion, rather than exclusion. Everybody is welcome to share and contribute.
“Upstream first” philosophy. The primary goal is to get the upstream project to adopt most of the updates brought by contributors.
Scalability. The product is modular and the development of one feature does not affect the rest of the code.
Freedom of personal choice. Do what you like within the community. No strings attached. Just be responsible.
Tracking, history and versioning. Every contribution is acknowledged, the history of your activity under Github is within your grasp, all versions are managed using the built-in mechanism of Github.
Dynamic decision making structure. We aim to shorten the chain of command and empower people by voting and keeping projects as autonomous as possible.
A secure collaborative environment for users and contributors. Heads-up: No, we do not hold sensitive financial data!
Clear and transparent governance is a key part of any open development project. It defines the rules of engagement within the community and describes what level of influence a community member can expect to have over a project. In addition, it enables members to decide their level of involvement with that community.
The community encourages loyalty rather than legalities. Members are free to take the code and create alternative projects as long as this is for the benefit of the community, rather than for a single individual or company.
Not everyone has a binding vote, keeping the decision making authority to those who share a common vision and who are willing to work towards that shared vision.
Users who continue to engage with the project and the community can become contributors.
Community members who wish to take an active part in the community can become a contributor. All contributions are submitted as patches that are validated by committers or project maintainers.
Contributors engage with the project through forum, blog, projects, and mailing lists. There is no expectation of commitment, no specific skill requirements and no selection process.
Contributors can be nominated as committers as soon as they prove their attachment and willingness to help in reaching goals.
Committers are community members dedicated to the continuous development. Committer-ship allows contributors to easily carry on with project related activities by giving them direct access to project resources. That is, they can make changes directly to project outputs, without having to submit changes via patches.
Anyone can become a committer if they show willingness and ability to participate in the project as a team player.
Nominees may decline their appointment as a committer. This role allows people to contribute more easily.
Committership is a privilege, not a right. This is earned and can be removed in extreme circumstances. However, under normal circumstances committership exists for as long as the committer wishes to continue engaging with the project.
A committer who shows an above-average level of contribution to the project, particularly with respect to its strategic direction and long-term health, may be nominated to become project maintainer, and thus part of the Technical Committee.
The technical committee consists of all project maintainers. Its main role is to set a vision and strategy for the community, as a whole, especially from the technical and business point of view, to decide upon matters that cannot reach a consensus among the members of the community. Its members are expected to review code contributions, participate in strategic planning, approve changes to the governance model and manage the copyrights within the project outputs.
Members of the technical committee do not have significant authority over other members of the community, although they are to vote on new committers. They have access to the project’s private mailing list and its archives. This list is used for sensitive issues, such as votes for new committers and legal matters that cannot be discussed in public. It is never used for project management or planning.
The technical committee leader is voted for by its memnbers. Once someone has been appointed leader, he/ she remains in that role until choosing to retire, is removed by a majority vote. He/ she has no additional authority over other members of the technical committee: the role is one of coordinator and facilitator, but also to ensure that all governance processes are adhered to.
This is a group of decision makers with the role of a moderator: the instrumental inspirational authority, expected to draw both the development vision and the guidelines of the community.
All participants in the community are encouraged to provide support to new users. This is provided as a way of growing the community. All support activity within the project is voluntary and is therefore provided upon availability. A user requiring guaranteed response times or results should therefore seek commercial support from a community member. However, for those willing to engage with the project on its own terms, and willing to help support other users, the community support channels are ideal.
Decisions about the future of the project involve all members, from the newest user to the most experienced member. Most of these discussions take place on the forum.
In order to ensure the project is not bogged down by endless discussion and continual voting, the project operates a policy of lazy consensus. This allows the majority of decisions to be made without resorting to a formal vote.
Decision making typically involves the following steps:
Vote (if consensus is not reached through discussion)
Any community member can make a proposal for consideration by the community. In order to initiate a discussion about a new idea, they should post a proposal on available forums (built within fintp.org, https://github.com/FinTP), on the issue tracker. This will prompt a review and, if necessary, a discussion of the idea. The goal of this review and discussion is to gain approval for the contribution. Since most people in the project community have a shared vision, there is often little need for discussion in order to reach consensus.
For more details on how a proposal may reach consensus and be approved, please see Types of approval.
Issues such as those affecting the strategic direction or legal standing of the project must gain explicit approval in the form of a vote. Every member of the community is encouraged to express their opinions in all discussion and all votes. For more details please see section Voting.
Board of Directors
Dan Ion Anghelescu
The website is built over Wordpress and it uses plugins to display content as intended.
Some contents or functionalities here are not available due to your cookie preferences!