by Remus Decea

In the beginning…

It all started with the challenge of finding the best sharing and versioning environment that will best accommodate our needs for building a strong and creative community around the FinTP project. It would have to allow collaboration among a large number of scattered contributors.

Finally, out of the hat there came out our rabbit, GitHub! We have to say we were also influenced by the large number of open-source projects it hosts.

My new world vs. my old world

I started using Git having a Subversion background (have been a SVN user for a short while). The first impulse was to “translate” the SVN commands into Git ones. It turned out not to be such a bright idea.

In order to make the best choices it is essential to understand Git functions and what makes it different. One thing is that “committing“ no longer meant that everyone contributing to that branch will be aware of my changes within the code. Being a contributor (as opposed to a committer) I am not allowed to make direct push into the master branch, that is, the location where the FinTP source code corresponding to that project is stored. In this case, I had to fork and clone the master branch locally and just work there and commit. Once I feel like my code is ready to face the world, I get online and push my code into the initial forked branch. To announce the software maintainer that I am ready to release my code into the community, I have to initiate a pull request. The software maintainer will decide, following an interactive review session, upon merging conditions: should it be merged as such or should it be improved.

Local vs. remote repository

The main idea is to allow you to work on your own, without being forced to interact with the central remote repository. Yeah, I also wondered what the heck is the remote repository? Mainly it is the single central repository of any project that serves as a hub for contributors, who may or may not access it while coding. When you clone it on your local machine, then you get, what else?, a local repository. Be careful not to overlook the corresponding documentation, usually organized as a wiki site, which will prove to be handy. Actually, this way of working (fork→clone→code→commit→push/pull request→review→merge) is what makes Git so suitable for working in FinTP projects (this is where you can find them https://github.com/FinTP). I know it may look a bit complicated, especially if you compare it to SVN, and that over pushing, pulling and merging of the same files might become annoying at times, but I guess each of them is more or less suitable under specific working conditions (SVN is easier to manage when few developers are working on the same branch and bring changes to the same source files).

I found it useful to stage only specific parts of my code, may those be urgent issues or already perfect code. The staging area is like a buffer zone where you may add the code that will get shipped away. As FinTP is still in its early stage, it is usually about the code that is ready to be integrated in the already existing one.

You have the possibility to choose how to interact within projects.

I personally started by trying to use solely the GitHub application to push my commits, but, after some silly commits and some conflicts that could not be solved by the application; I gave up and shifted to Git bash, although I am not a CLI fan. It is a bit hard at first, but in my opinion it is totally worth it.

Branches

Another important aspect that Git provides is the possibility to make several branches both on the local and remote repository. Thus, because of our need for working in a team, we have adopted two workflows.

When a team of contributors is coding on the same project we go for a centralized workflow: all members are using the remote repository as a single entry-point for all changes brought to the project. Thus, beside the master branch on the remote repository, we use a development branch in which we push changes. The development branch is merged into the master one when the contributors agree that they have a stable release.

On the local repository I have a master branch, a development branch and several feature branches.

The main branches of the project are master and development. The master branch contains only ‘production-ready’ states of the project, while the development branch contains the latest development changes that will be included in the next release. On the development branch, nightly or merge-triggered builds (whatever comes first) are run. That means that the build will always include the latest merges. Master merges are equivalent to a new production release and actions that come with it (version increment, build label, build on some production machines) are automated.

Distributed workflows: one type of supporting branch is the ‘feature branch’. When starting developing a new feature I create a new local feature branch that will be merged into the development branch as soon as the work is complete (the code is reviewed and documented, at least by relevant comments). Currently, on the projects I contribute to, there are no remote feature branches, but I have created several local branches. One can add several other supporting branches, such as release or hot fixes branches.

Message to potential contributors

Using Git is awesome and it aims at making your work as smooth as possible. It is probably one of the best tools supporting large worldwide communities sharing the same interests in a collaborative environment. For start, just fork our project and start coding. Then push your commits. As soon as you have any doubts about the best course of action you may find useful information here https://help.github.com/. Anyway, if you are a beginner eager to contribute and feel that reading is just consuming too much of your time, we will be glad to offer our support.

by Ioana Guiman

Most of the Allevo stories these days go around FinTP. In short, this is an application built for financial institutions of any profile and size, that processes payments and other types of financial transactions, understands data and generates various reports for operations and business oriented people. What is special about it and what differentiates FinTP from other similar solutions is its licensing model because it is distributed under the GPL v3 open license.

Going open has not been an easy step for Allevo, it meant defining and adopting a new business model to accommodate this type of software. Looking into what is happening in banking software nowadays, I can say we are among the very few who have taken this approach to fully open source our core business. Some big banks like Credit Agricole have made a first step into this direction by opening up their APIs, but most of the software provider companies are still tackling the traditional proprietary approach. This places Allevo as one of the first companies that has adopted a recipe known and proven to succeed in other industries and used it in the financial services space. To not only keep pace with FinTech innovation, but to also attempt being one step ahead, more than this is needed. FinTP needs to constantly evolve and adapt to, and even anticipate, market needs. We have several ways of doing this and one of them is co-producing the Innotribe Startup Challenge with SWIFT. This keeps us right at the heart of the FinTech startup ecosystem, allowing us to see new technologies first hand, identify areas where we can collaborate, come up with ideas for new features or products to build over FinTP. We basically get to see the next PayPal before it becomes mainstream. This creates the premises for ideas to be born and nurtured in the FINkers United community and around the FinTP project.

And there’s always the feeling of pride and satisfaction when you scan the day’s news and read that startups from past competitions have raised series A financing, have been acquired by big industry players such as MasterCard or Facebook, have partnered with the likes of Microsoft and are generally doing very well. It’s like watching babies grow on one hand, and knowing you’ve met them before they had all eyes on them on the other.

The Innotribe Startup Challenge is a global competition SWIFT runs for finding the best startups in the FinTech industry, to bring them closer to banks. This is the second year we produce this program together with the Innotribe team, looking at over 280 companies that applied for the competition. Industry experts carefully selected from Innotribe’s network help review and evaluate these companies, acting as the program’s judges and coaches. The top 15 startups per region are then invited to pitch in one of the three locations – London, Singapore, New York. Each of them participates in one of the two categories, startups or innovators, the latter being growth stage companies that are founded at least three years ago or have raised sufficient investment or have sufficient revenue to become sustainable. On the Innotribe website there is a brochure where each of the semi-finalists is briefly described on one page.

The format of the competition is quite strict, each startup gets a 6 minutes sharp pitching slot and is given an extra 4 minutes to answer any audience Q&A. The pitches are available on Innotribe’s YouTube channel.

The three 2014 semi-finals are now over and the top three startups and two growth stage companies from each showcase will get to pitch this fall at the Grand Finale at Sibos, Boston. They are all listed here.

Interesting is to see where these startups position themselves. The bubble map below highlights the main areas of innovation for 2014. Most startups are built around corporate and business services (three of the finalists fit in here as well), investment management (two finalists), lending (three finalists) and so on. The big bubbles are obviously the mainstreams of 2014, but what I find more important is looking at the smaller ones, that have the potential of turning into the next big thing. There are startups that deal with digital currencies, back-office operations, messaging or securities, areas that are less fancy to look at, but highly significant to the ecosystem and more likely to experience a burst in the near future.

Most startups provide customer oriented apps or services, positioning themselves more on the front-end side, rather than going very deep into the behind the scenes systems a traditional bank has built over time. Every now and then though, one can find startups that offer technology that can enable innovation in banks, such as last year’s winner in the innovator category, Waratek. Waratek has developed a technology that makes Java enterprise applications more secure and easier to manage. The Java Application Security platform provides transparent, run-time application self-protection against business logic and network layer threats. KlickEx is the 2013 winner of the startup category, building a platform that enables authenticated Banks or Telcos to provide real-time or same day payment and settlement of cleared funds to any other connected bank, in any connected country.

With FinTP I am happy to notice we touch quite a lot of the areas of focus and I am very keen on seeing some open (not to go beyond and say open source) apps or platforms come into the spotlight as so far, not that many have shown on stage.

I am very curious to see who wins this year’s competition as the race is tight and we have a lot of good startups going into the finals at Sibos. Should you be at Sibos in Boston this year, please pin in Wednesday afternoon, October 1^st, to come see the Innotribe Startup Challenge Grand Finale, meet our startups and help us pick the two winning companies. And you can of course stick around for the Innotribe reception then after. I promise this will be time well spent and a different kind experience, especially if you have not seen a startup event before.