The start-up bank, which is testing its product with select customers, uses open source platforms for the development of nearly all of its Web and mobile applications as well as the backend systems that will power the bank when it finally throws the on switch for the 100,000 people who have signed up for its branchless services.
"Our relatively small [development] team has been able to build an enormous amount of functionality in a short time," says Alex Payne, co-founder and chief technology officer for BankSimple, of Portland, Ore.
You don't need to be a bank of the future to work with open source. Just about every large bank, whether directly or through vendors, uses open source applications and platforms today, experts say. The benefits are substantial: Banks can potentially save 80% on project costs, which they can complete more quickly, because no one vendor is developing the code.
But working in an open source environment isn't a panacea either. In fact, it brings a critical set of management issues to which banks need to pay attention. Banks have to carefully examine licenses for open source code, for example. And they must pay strict attention to upgrades, patches and security. Finding knowledgeable coders can also be an issue, and because open source is based on communities, banks have to learn how to share part or all of the code they are developing. "There is a critical mass and virtuous cycle for those contributing to an open source community, and you spread the cost of development over time to a broader audience than just your company," says Mark Driver, research analyst and vice president of open source and application development for Gartner.
Open source software is code that is available to the public to use and change, free of charge under an open license. Communities typically develop the software collaboratively. And the theory goes that because so many eyes are on the code, it is more stable and more secure, as opposed to proprietary code where only the project team gets to see it.
Companies using open source must change their way of thinking about code and coding. As opposed to the typical vendor relationship, where the customer can pay the vendor to work on fixes, work in open source communities is collaborative. When there's a problem, you have to rely on the community to provide an answer. Users of open source are also expected to contribute code, or something equivalently useful, back to the community. "There is a supplier-customer relationship that people know how to deal with in the commercial world, but in the open source world, no money exchanges hands, and when someone says, 'I need this feature,' I say, 'Why are you telling me?'" Ian Skerrett, vice president of marketing for the Eclipse Foundation, of Ottawa, says. Eclipse is an open source foundation started by IBM.
There are thousands of open source projects, and about 70 platforms licensed by the Open Source Initiative, a nonprofit group overseeing standards and licenses. However, banks only use about half a dozen of those. The most popular platforms include the Linux operating system, Apache's Hadoop MapReduce, useful for analyzing big data sets; Eclipse, which is useful for Java development; Drupal, for content management systems, and JBoss, an application server platform. Well-known consumer applications like the Android operating system for smart phones are also open source.
OPEN SOURCE IN BANKS
"Banks and financial institutions are looking at the competitive advantages [from open source] and they are not afraid of getting their fingernails dirty with the code because there is now a very sophisticated and mature development environment," says John Igoe, executive director of cloud solutions for Dell, of Round Rock, Texas. Dell created its own open source platform, called Crowbar, which it released in 2011. Crowbar is a provisioning framework for computer networks.
The biggest management issues around using open source have migrated over time, Tiggas says. Initially they were about accountability. As opposed to the traditional vendor relationship, it was hard for Wells Fargo IT staff to know where to go if something went wrong in an open source environment.
The current issues are more familiar to those using open source. Licensing, for example, has to be handled extremely carefully. Open source licenses can be distributed in one of two ways. The first is called a General Public License, or GPL, which links any code you develop to the open source and makes it available to the community, as opposed to more restrictive licenses that let you maintain more of your code by overlaying it on the open source platform.
About half of all open source code projects are GPL, says Jeffrey Hammond, a principal analyst for Forrester. That creates a competitive issue for banks who might not want their competitors to see their code. "You have to be very clear about what license the software you use is," Hammond says. And before using it, banks should consider running the licenses past internal counsel.
That resonates for Wells, which says it is very cautious about the open source technology it introduces, especially since younger developers can be more cavalier about licenses. "Some of the licenses are egregious, and we will not use that software because the licenses do not meet our requirements," Tiggas says.
Similarly, executives at Bank of America say it's critical to establish a risk policy specific to open source.
"The policy should outline the risks of using [open source], techniques for managing risk, and a method to determine whether or not the anticipated benefits of using [open source] outweigh the overall level of risk," wrote Don D'Angelo, senior vice president and open source product manager at Bank of America in an email.
Managing code updates and security fixes is also crucial, experts say. In the open source world you don't have a private company pushing updates to your machines and networks. "When you remove the vendor, you have to make sure you have the technical skills internally to do patch management and configuration, but not major surgery to the source code," Driver says.
Wells does this by cataloguing all open source platforms it uses and producing an RSS feed it sends to developers whenever updates are made to the code. It also depends on the coders who have been using open source the longest, and their connections to the open source communities, to stay on top of changes, Tiggas says.
Similarly, BankSimple says it stays on top of fixes and patches through community forums, mailing lists and social communication tools like Bithub.
There are also concrete supply and demand issues with open source. Banks often find it difficult to find enough skilled programmers knowledgeable in open source programming. And because they are scarce, they can cost more.
"It is hard to get talented people. When they are on the market, they are usually grabbed the second they put down their most recent job," says Scott Bales, chief mobile and technology officer of Movenbank, of New York.
Labor costs for open source projects, generally speaking, can be five to ten percent higher than non-open source projects, Hammond says.
So Movenbank has found a partial solution, which is to try to create more skilled programmers. It does this by pairing senior developers with junior developers, which will hopefully increase the size of the open source developer pool, Bales says.
Lack of qualified employees can discourage smaller banks in more remote places from pursuing open source projects.
First State Bank of Barboursville, W.Va., would like to use open source programming, but doesn't because of the small local talent pool. The bank also worries that if its programmers started using open source code, and then left, that would leave the bank in a bind.
"Open source code interfaces with something else, and every time the other software changes, you have to update it and the interface. You can't just develop it and let it sit, and you may not have labor availability for that," says Sam Vallandingham, the chief information officer and vice president of First State Bank. The bank has an IT staff of three people.
DECIDING WHAT TO GIVE BACK
Just as nettlesome can be deciding how to interact with the communities whose code a bank is using, and deciding what to give back. Movenbank, which plans to open its doors this summer, uses open source platforms like Ruby on Rails and Hadoop to create back-end systems. It also uses them to develop the social scoring system upon which the bank's relationship with customers will be built. That system, which it calls the CRED ecosystem, will rate customers by social standing, and potentially give them access to better pricing based on that rating.
"Banks are used to owning the IP and they protect that with a big wall and tanks and guns, but in the entrepreneurial startup world, sharing is a positive thing," Bales says.
Movenbank's developers interact regularly with open source communities, Bales says, including attending events, forums and workshops.
BankSimple's developers maintain proprietary code, but realize they must give back code and do so by contributing code libraries in ways that are not specific to its business. "We have a mix of code that is proprietary that we have no intention of sharing, and what we try to do is slice off pieces of code that are reusable, that could find use in some other system," Payne says.
Finally, depending on how deeply banks plan to involve themselves with open source, they need to ascertain that the open source project will be around years, or decades later. "In the typical purchasing process you know IBM will always be there," Skerrett says. Working with the reputable open source organization is the equivalent of having a brand seal of approval, and it increases the likelihood that the project is well-run and will be around, Skerrett says.
The more established organizations have processes in place to make sure that hosted projects are well-run and maintained and even archived when phased out, Skerrett says.
Meanwhile, BankSimple is so convinced that open source tools and development suit the purposes of the bank that they have little intention of using proprietary software.
"We have looked at proprietary business intelligence tools but have not ended up adopting any," Payne says. "We will build [business intelligence tools] ourselves and contribute a portion back to the open source community."
