Let’s see if I can address this without getting beat up too badly. 
About a year ago I decided to take most of the libraries that we had written for ExpressionEngine and put them into a open source framework. Had all these libraries not already existed, CI would not have been possible. The development time would have been too astronomic.
Once CI was released, however, I realized that it was inefficient for us to maintain two versions of our libraries; the EE version and the CI version. When I ported the EE libraries over to CI it was necessary to make some changes to them. EE handles globals and a few other things different then CI, so each library required finessing to make it work. This created two sets of libraries. In an ideal world, however, we’d have exactly the same libraries in both applications. This would make development more efficient, and it would permit libraries that were developed for CI to be used in EE.
Many of you know that we’re working on EE 2.0. It’s a big release, so it’s still some time away. One of our goals for 2.0 is to ditch the EE versions of the libraries and incorporate the CI versions. We want to end up with one set of libraries that works for both apps. In fact, we want to create generally tighter symbiosis between EE and CI. It would also be great to use all the base classes (like the Router, Input, and Output class) in both EE and CI (it may not be possible, though. We’ll see…)
We actually floated the idea of building EE on top of CI, but there are way too many daunting challenges that prevent this. But we believe we can achieve much closer integration, even if they remain separate apps. This biggest benefit to us of doing this is that it will create a much more streamlined development process for us since it blurs the line between EE and CI development. Our EE team becomes our de-facto CI team.
Here’s a concreted example of something we’re hoping to achieve for EE 2.0 that will cary over to CI. Currently, EE runs only on MySQL. We’d love, however, for EE to support other DB platforms. To do this, though, will require that the 2000+ database queries that exist in EE be ported over to a more abstracted mechanism. In essence, we need to rip the MySQL queries out of EE and replace them with an active record pattern.
CI, however, already supports multiple databases via a much nicer DB library then EE and it has an active record system, it’s just not powerful enough in its current form to meet our goals. But it’s a great starting point for our development, so as we move EE to this new database structure and rewrite the engine, it’s going to result in CI automatically getting much more kick-ass database classes.
The idea of EE development automatically driving CI development is a very exiting proposition to me. Not only will it be very efficient developmentally, but it will ensure that CI gets updated more frequently. I acknowledge that CI has stagnated a little in recent months. We have a tiny dev team that is already slammed with work (three people including me… and most of my days get sucked up running the company). By creating tighter symbiosis between CI and EE we will solve the problem.
The only downside to my above proposition is that CI development will likely never become a true community based effort like some open source initiatives are. That isn’t to say that the community will never have any input, or that feature requests and suggestions won’t be considered, but ultimately, CI will be a direct offshoot of EE. CI will be an open source effort with more closed development. Some people might not like this, even though the quality, consistency, and security of the code will be much more uniform.
Back to the original point of this thread: Roadmaps. I’ve never been a big proponent of roadmaps. I know that some developers love them, but I’ve always found that the internet changes too quickly, and development cycles tend to be too short, to accurately forecast. And in my experience, you never truly know what new feature your app will have in that release until you’re in the thick of development. I can’t tell you how many times I’ve headed down one path only to discover an even better idea. Or how many times I’ve thought a particular idea would be easy to code only to discover that it’s going to have to be put aside until a later date… and then something better comes along so the original idea never happens.
Maybe it’s my particular temperament, but I just don’t like to look very far ahead, and I never bother to look at roadmaps in other products. I could care less, really. I much prefer to deal with the reality of the application as it is now, and make my decision as a user based on that. I acknowledge that a roadmap might be deal breaker for some people, but in six years of developing three major applications we’ve never used them.
