Mark McSpadden

The tail end of this week has been quite a frenzy. In addition to doing some rockin things behind the scenes at Banktastic, I’ve been in a pretty in depth discussion with the guys at Trabian (and the rest of the blogosphere I guess) about their tough decision to not open source their CMS and the motivations behind it.

Now, I love me some Trabian and Matt Dean is personally responsible introducing me to Rails and Ruby and much of where I’m at today is a reflection of the personal investment he has made in me.

Back to CMS. My initial reactions when I read the title we a little disappointing, but I knew this coming. However, I quickly went into “WTF” mode when I read the explanation which seemed to point to security as the main reason to keep their CMS closed. This didn’t jive well with me. Open source can work in FIs. I know it can. After a lot of thought, I commented with my concerns.

Matt followed with some insightful clarifications, and we both agreed it would be a great topic for the open Dev chat he hosts on Fridays.

A couple of great things came from this conversation. This chart (drawn by Matt on the fly) gives great clarification to the problem any company faces when looking to open source their software. (Click on image for larger view.)

For software that is running a bank or credit union’s website, I agree with Trabian that this drop off is not something anyone can afford.

This brought me to the following conclusion:

I believe that a mature open source CMS (or any FI software) can be every bit as secure (if not more secure) than a proprietary one. However, the process of opening that source, can provide a season of lessened security and increased administrative strain on the original proprietor of the code.

I am interested in discussing ways the community can help lessen the security drop off and administrative woes for companies that would consider open sourcing their code.

Moving forward

So how do we as a community and industry help companies move towards open sourcing their code in a way that maintains the level of security necessary for our content matter? It’s a great question and I would love to hear thoughts on it from anyone.

My initial thought is something like this.

The collaborative initiative

So the thought here is to invite other organizations to join the project and contribute to it. This does two things:

1. Provides a litmus test gaging the viability of this project as an open source initiative. If you can’t find any companies to jump on board with you, then the chances of snagging enough individual contributors later is pretty slim.
2. Increases the code security. Since opening the code up may represent a dip in security no matter what preparations we make, we use these new eyes to help us increase security. This way the dip doesn’t take us into super bad security land.

The invite only open source

This stage would allow individuals to contribute. I’m not sure if it’s necessary, but it would bump up security even further before the big opening.

It still hurts

The problem with adding any of these “extra” steps is that it still includes a good bit of overhead. In fact, it might even be less overhead just to be up the thing instead of adding in two steps. I’ve got nothing for this one…so anyone feel free to chime in.

Those my thoughts. I still dig Trabian. I think they still dig me. And I think we’re closer to addressing some of the real problems that the heightened level of financial software bring to developers and software projects.