file_column_on_steroids - Rails Plugin

I've been a huge fan of the rails file column plugin by Sebastian Kanthak. It owes it's popularity to it's being amongst the first file upload plugins in the Rails world. It's simple and easy to use, but what I loved most about it was it's relative un-obtrusiveness. It didn't require it's own model and table cos it didn't try to be too intelligent.

However, since quite sometime, it seems to be dropping in popularity to other plugins offerring more features. It looks like it's not bee updated since quite some time.

I had just 2 major gripes with file_column:

1. It stored all files under a single folder. As the number of files increased, you'd run into problems of having too many sub-directories directly within one directory.
2. It didn't play well with S3 which a lot of their other plugins did.

We, at Contests2Win, were using this plugin extensively and didn't want to look at moving to another plugin. Over time, we've addressed the 2 issues mentioned above.

We have made some modifications to file_column and have been using it to manage more than a million images and videos. User uploaded images are processed (resized, encoded, etc) and uploaded onto S3.

In our bid to give back to the open source community, we have released our modifications under the MIT license. Check out our version of file_column_on_steroids on github.

The cost of Change

Decision Time:

1. Continue working the way we were, using the tools we know and their limitations OR
2. Learn the new tool/technology, invest time and effort in migrating to it and train the team to use the new tool

I'm sure many development managers have faced such a question. More often than not, we choose to go with option #1. The usual justification is -

It's tried and tested and WE DON"T HAVE THE TIME TO JERK-AROUND with the new stuff. We need to build the new features and focus on our backlogs!

The only problem with the above is that while you are considering the Cost of Changing, you are usually completely disregarding the Cost of NOT Changing. You'll never know what you are missing out on unless you try it out.

We've be considering switching from subversion to git since quite some time. Evey time I've been delaying it thinking that is it really important? Doesn't subversion mostly cut-it? It's not really hurting is it? Nah... let's stick with it, there's too much on our plate as it is.

Last month, we finally switched and I've been cursing myself for not doing it earlier. It's a truly liberating experience when you can work on a new feature having full confidence of being able switch back to your main code base if you needed to. The ease of merging other developers' branches into the main code has helped me to delegate even more.

What I take away from this is that always realize that there is a cost of not changing. This can't really be determined. The only way to decide is to use your gut feeling.