TechHub hosted on October 23rd the Linux Open Alternative Days (LOAD), an already traditional event dedicated to Linux and open source technologies, which has reached its 9th edition this year.
As LOAD is meant to create a strong community among supporters of the open source philosophy, there was no better place to present our FINkers United open source community and the project it is built around, FinTP.
Therefore, we delegated Denisa Agatie, co-founder of FINkers United and member in its board, to talk to the audience about this project and the challenges of creating and maintaining an open source community in the FinTech space.
The presentation was received with interest and we were happy to see people reading the FINkers United for Dummnies Brochure during the event.
For more information on how you can contribute click here.
Here’s the recipe for creating an open source community in the financial world.
Denisa Agatie of FINkers United will fill you in on the details tomorrow at the LOAD (Linux Open Alternative Days) event.
http://bucharest.techhub.com/events/load-2014-linux-open-alternative-days
Join us at the event tomorrow!
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.
As you might have seen, we organized at Sibos the first FinTP Idea Contest.
There were interesting ideas submitted in the competition and I just wanted to share with you some of the most appreciated ones:
Send USDs and EURs between banks using the Ripple protocol. Cryptocurrencies!!
Automate payments and B2B platform using FinTP in a local project.
Have a long structured remittance info
Push EBICS to Eastern Europe
Mobile money across global business currencies
Invent a standard
What about a “movable” account number – no matter what bank – and with “names” like websites?
There were even things we did not think of, so this contest was a very good idea in itself. But all ideas will be taken in front of the FINkers United board for further consideration. The board will select those fit to be planned for future releases of the FinTP Project.
Out of so many good ideas, one was ranked highest: Push EBICS to Eastern Europe. It belongs to Joachim Berg, EFiS, who now has to figure out how to use the techie watch we gave as an award.
Thank you all for participating and congrats to the winner!