Thoughts on Abandoning Proprietary Framework for A Larger Open Source Project

We have been going back and forth a lot around our office lately about abandoning a proprietary framework that was developed here a couple of years ago and move to something that is larger and community supported.

Our current solution was built to include only the things we need and is very flexible, by flexible i mean that it is loose and the developers that have built sites with it over the years have take liberty in that, so a lot of sites we manage and have built and not to any standard at all. Here at the office I use the framework somewhat but prefer to use other tools. Over the years I have used a lot of PHP frameworks ranging from Code Igniter to CakePHP and have been a big fan of Zend Framework for all my personal projects so I am heavily biased and that is why i am asking here for开发者_运维问答 advice from people who may be able to give me a more objective opinion. In the office a lot of work has been done on our framework so I can understand why some people might be hesitant to abandon it but the way i see it is this:

• We don't currently spend a lot of time keeping our framework current and checking it over and over for bugs, we fix them as we find them. Which we should be doing
• Any work done to improve our framework is directly put into our overhead column
• We have a application built on top of our framework that is subscription based and closed source that we sell and I feel could be better if built to a better standard using a popular, community driven, framework that would require or encourage these things.

I searched and found this thread, Why do I need to use a popular framework?, that was similar to what I am asking but not quite. What i am asking for are opinions on as to why you would do one thing or the other, i don't really want to start a conversation about which framework is better, that will be the next step for us if we chose to switch.

Here are some of the reasons i see switching to a supported, open source framework as helping us in the long run:

• As PHP puts out new versions the core of the framework will be updated to take advantage of those things without us having to do the work.
• Security concerns with the libraries will be found by the community and patched without our involvement other than updating our code base with the current version.
• Lots of information on the internet and exisitng code that can be used as reference
• Ability to hire outside programmers that know the framework already, instead of hiring people and expecting them to have to learn how to use our proprietary one.
• Ability to give back to the community through patches, plugins, helpers, and support.

Here are the negatives that I have come up with:

• We will have to port all the existing code we have in our custom application to the new system
• Our employees will have to be allowed a certain amount of time to learn a new framework and it's ins and outs
• Our current framework is very flexible and loose which allows us to build things how ever we want and this keep our developers from having to follow and obey and conventions, which some developers seem to hate. I personally like conventions

Again it is probably obvious that I am biased and this is the reason I am asking here, I am open minded to what anyone might have to say.

Your question is really devilishly biased, because all pro's are long-term and all con's short-term development pains. :) But if the situation is even half as much as you describe, switching is the right thing and will save a lot of money in the long run.

My company is in the same sort of situation. We have a custom developed framework in Perl that never seems to get quite as much attention paid to developing new features and fixing bugs as the open source frameworks do. I and most other developers would love to switch to something open source for the benefits you mention, but nobody has the budget to spend the time porting code over. Our current plan is to use an open source framework if we have any small, new projects come up, and if that's successful consider moving older apps over.

I've mostly worked with Perl and Ruby, but a trend I'm seeing more of these days is frameworks allowing you to mix and match framework core components. For example, we're considering integrating parts of our custom framework into Catalyst. That way we can still use some of our custom developed code components (our own DBI class and some Mason templates) and porting our applications won't be as difficult. Ruby on Rails is also moving in the direction of being more modular.

Perhaps there's a PHP framework that might allow you to use some of your code, or at least make it easier to shoehorn some of your code into the framework instead of starting from scratch. Googling I see most of the PHP frameworks claim to be modular, but some appear to just allow you to develop add-ons, not swap out core components.

Sounds like you're doing some good analysis and I wish you luck in your search.

I think the most important points you highlighted here. The decision now, should be based, on numbers. Technically your analysis is perfect. What i would ask now is: How much it would cost for your company,to:

* keep your app to take advantage of new php improvements without break your old code (it means: architecture analysis, development and test, test, test).

* Do you have any developer/analyst focused in security development? (it means: security development life cycle, test, test, test).

* Do you have a development methodology? Normally those frameworks are kept under a good distributed development methodology.

I had the same question than you sometime ago, and my company decided to choose a framework, migrate our code, allocate 2 developers 1 day per week to work on the framework. To put our team to work with the framework development team was good, because we learned more about the framework, we helped the community (demagogy :-)) and we could add some business requirements in the framework features road map ;-)

I and my team are nearing completion of porting an existing application across to run on Zend Framework and it's gone quite well.

The old application had a lot of issues that were going to be big problems to fix and we decided to take the plunge and rebuilt it in ZF.

It has however taken a long time to port, I would estimate for our application it's taken us a good 4-5 months of dev to port everything across (we have taken the opportunity to rejigg the database and other areas of the system).

If you do go for it then be prepared to explain to your bosses why you need to spend a good chunk of time porting rather than working on income generating work. We were lucky to be able to use a new project as the impetus to carrying out all this work.

I see a couple of cons of switching over.

First, of course, there's:

We will have to port all the existing code we have in our custom application to the new system

Followed by:

We will have to port all the existing code we have in our custom application to the new system

and, last, but, not least:

We will have to port all the existing code we have in our custom application to the new system

You were talking about "money in the overhead column", and rewriting working tested code in to new working tested code doesn't add a whole lot of value.

If you're talking about introducing a new framework for a brand new, unrelated project, or one that uses little of the existing code base, then, sure, knock yourself out. That's a fine opportunity to switch frameworks, platforms, languages, etc.

But an existing, shipping, mature code base with existing knowledgeable folks working on it?

That's a hard pill to swallow, personally.

If you want folks to follow standards and conventions, then ... follow standards and conventions. Since you have a system that allows folks the "freedom to what they want", make "following standards and conventions" something they want to do.

It's always better to transition a system incrementally that throw the whole baby, bathwater, soap, basin and towels out the window just to go back and redo the exact same thing again.

Everyone wants to rewrite code, I want to do it. Our framework needs a "do over" here. But then we go "yea, but..." and what do we get in the end? N Months of effort to get back to where we are now. That doesn't do much in a world where time to market matters.