I bet few people would be eager to develop banking software on their free time for instance.
I bet few people would be eager to develop banking software on their free time for instance.
This of course would have to have banks be more open about how they operate, so it probably won't happen.
This is to say, it's not really the type of software that is the issue, but rather lack of openness about the problem domain.
AMQP (messaging) came out of JPMC and other financial institutions
Financial institutions are also involved in blockchain projects
Another random example: https://developer.capitalone.com/open-source/
As someone for whom the day job involves working on projects for investment banks and other regulated industries, I'd say this is not the first problem that needs to be solved.
> if banks were to describe their problems in a sufficiently well defined way
THIS is often the problem. They often don't know exactly what they want. Well, many people in the company think know what is needed/wanted but most of them don't agree with each other (and if they do they probably don't agree on priorities) beyond the rules set by the regulators (which are usually deliberately "non prescriptive", which is to say "vague"). They often have long lists of what they don't want, but no proper specification of what they do want.
The larger organisations are often so siloed that the left hand doesn't know which foot the right hand is pointing a gun at and no one really knows which elbow they are collectivly sat on. When a project to clean things up starts it is usually populated by people seconded from elsewhere who either still have that job to do so can't commit themselves to the matter in the concentrated way required to deal with it properly, or are not close enough to the problem to have a full understanding of the nitty-gritty details and the interactions between those details. And sometimes those details are very difficult to find until they bite you due to the amount of legacy systems these groups have dotted around, especially in cases where organisations have formed from many mergers & acquisitions over the years.
They don't want to openly share this state because it would be a public embarrassment. Of course, it is hardly a well-kept secret: they all know what state each other are in, as do those of us slowly trying to fix it and the consultants (internal and external to the organisations) making piles out of part-way fixing it (often by reinventing the problem space in new and expensively interesting ways!). But still they don't want it to be any more an open secret than can be avoided.
I assume large organisations in other industries are similarly afflicted. It is human nature (we often don't individually know exactly what we want) magnified by scale.
"It can't be that hard, can it?" you would be forgiven for asking.
"Oh, but it can", I assure you!
As others have pointed out elsewhere in the thread: things are improving, particularly in specific areas where new ideas are forcing, or at least allowing, more radical rethinks. But overall it'll be a complete mess for some time to come.
There are very good open source databases, content management systems, web servers, full text corpus search systems, operating systems, and 100s of other "kind of boring" things that a 20 year old version of me would assume people would need to be paid to create. (Some of those are a crossover where a substantial portion of the development was originally paid, of course, but many others are not.)
If a bank found someone who was eager to develop its software for free, it would have a pretty good reason to question their motives.
In that case, banking software would be very useful for the community and people will help.
The fact that something is boring has nothing to do with it. There are few things as boring as developing operating systems like Hurd or developing Wayland and dealing all day with bugs and bugs and more bugs.
Of course, people is not going to create banking software if the only ones who benefit are private companies that give nothing in return.
There must be a good reason. Something that provides the sense of deep meaning for your work. Working for free so a private company could profit out of your work does not.