BlueWater ETA

In some cases that is true, but the benefits far outweight the small decrease in performance, and I’m told with the proper performance tuning, InnoDB can be both safer (e.g. transactions, row-locking vs. table locking, etc.) and quicker than MyISAM. In particular, turning off InnoDB’s DB logging will make it scream. It’s a matter of what you expect, 100% data integrity or less than 100% data integrity (i.e. risk potential issues in favor of performance).

In any case, that is easily definable in the schema and could be controlled at install time, as it is in many popular YAPS...

Well some users will not be able to tune there ISP’s MySQL servers.

This is better set at install time for MySQL installations. Meaning the table type would then be just a variable. Example: {Engine}

At some point soon, make that now, we need to really agree what we’re trying to be. I think and sense a real serious disconnect here. We do not have consensus. I think we should focus on the next 2-month window and get something significant done. Three months at the most. We should get all ideas out on the table, throw sample code out, whether or not it’s finished and polished, optimized or slow, communicate openly and frequently, and collaborate as a team.

We have an opportunity to make a significant mark in the GPL software space by creating a tool that possesses a real unique combination of the comparitively easy to use and do cool things with for most common sites (from the our current code), but to put it on top of a truly modern and grown up platform that’s even more robust. The kind of thing that would make people stop long and hard before they dive into a Ruby on Rails solution. A near-equal amount of robustness and power with virtually ubiquitous ability to deploy.

That might mean we loose a few folks running on $3/month shared servers with 2500 other sites. The are the same types of folks that are looking for YAPS and ask where the polls are and how to install templates. Being brutally honest, these are the types of people that in the next 18 months will never help me support my family. Wonderful people and I enjoy them being here, but I’m selfishly more concerned today about how I can put food on the table and provide for my family.

Besides, we have the current version that honestly serves that market better than anything out there (well, as soon as we get a snippet repository up that’s done right... a topic for another conversation though)! And I think we should continue to improve it by cleaning up the API, adding a better manager skin, and throwing in the recursive parser. It will probably still be the apropriate solution for many people for the next 18-24 months, anyway. It’s a great place to back port things into when possible.

However, my vision is much larger for our project than something that’s all things to all people. It can surely become that way again in the future, but for now, we’re too early in the curve to not adopt a more proactive and progressive stance, that serves a more sophisticated market. In a year or so, we can "dumb it down" and make it universally accessible.

The things that Jason has shared (and that look like they’ll be out within the next few days) sound pretty much mind boggling, especially given the he undertook the effort a couple of weeks ago. If it does what I think it does, it would give us a truly enterprise capable platform that’s "grown up". That’s a market that should we so choose to do so, we could all support our families by developing and maintaining solutions and providing support services.

It opens the very real opporutnity to provide solutions that generate five-figures per engagement vs four, for relatively little additionaly effort. It would allow us to deploy truly mission critical, enterprise-grade solutions that stand up to the educated scrutiny of seasoned decision makers. Sell in markets that have important motivators called "budgets" to spend.

When you integrate the things that Raymond’s working on then it becomes a tantilizingly cool platform that you can run on most somewhat respected (i.e. not out there just competing on price) shared hosting environments. That will be even more true in 6 (or more) months later when it’s actually polished to a releasable state. Until then it might require a more stringent development/testing platform. I’m 100% OK with that.

One thing that I’m confident about, is that the clamor around such a platform will make what we’ve been fortunate to accomplish to date seem insignificant. It will likely mean some temporary discomfort and frustration, learning some new things and how to think in a OO manner, and possibly even loosing some of the less savvy users. To me, a 100% acceptible tradeoff and sacrifice I hope we all decide is for the greater good.

We need to encourage ideas. Explore internal efforts that have timeframes that bear fruit in weeks, not months. Incremental improvments vs. monolithic leaps. In order to do that though, we need an abstracted platform as Jason mentions that accomodates even radical changes on the back end without skipping a beat. It’s just not really feasible on the same type of structure that we’ve got today. I think we should adopt the release early/release often (internally at a minimum) paradigm and target technically savvy folks that can actualy troubleshoot and dig in and help figure things out.

If we take this track, this time next year, the focus will probably change to putting a super slick, wizard driven interface on an insanely robust platform. That’s when we could really kick into high gear the efforts to supporting less experienced users. I can’t afford personally to do so today.

Thoughts?

Ryan,

Are you saying that we that we are not functioning as a team when we have disagreement on some designs issues?

Question... Does it appears to you (or anyone else) that I’m not cooperating as a team player?

I would like us to get this out in the open.

Okay, so here’s my two cents worth.

I agree we need to move toward a solid, robust and powerful platform and take the focus off of the hobbyist. I think that’s the best way we can help the businesses and the hobbyist in the long run. If we focus on a strong modular core with an extensive and well-defined API then we’ve empowered the businesses and the hobbyists to extend MODx for whatever their needs may be.

If we take this focus then I think that we need to start recruiting some team members to handle support specifically. Too many important people wind up handling simple support issues on the forums, there should be people assigned to that task.

Raymond, I can’t speak for Ryan but I’ll say that personally, I think one of the best things for an open source probject is a little disagreement now and then. And I think the concerns you’ve raised recently are definitely worth a good serious look and I don’t think we should commit ourselves to anything too hastily. But I know that if you trace this project all the way back to it’s roots you’ll see a lot of issues because people did not work as a team and too much ownership was taken over specific areas. Alex didn’t want anybody else’s code in his project, aparently Ralph doesn’t either since he’s the only dev, and Travis did everything his own way without much input from the community. So I think we just want to be very careful that we don’t see this pattern repeating, and I think that communicating, sharing code and making decisions on the core as a team is the way to keep this project on track.

Thanks Adam,

I believe in putting forward ideas and getting feedbacks for others. If someone disagrees with it then that’s fine. It’s for me to sell the idea to the team or go back to the drawing board and get things working right.

I was about to post some new ideas and proposals for the manager system for us to review. IMO we can agree to disagree. We will not always see eye-to-eye on on everything but the greatest thing yet is knowing that we can still get together and continue working on the project.

Not sure if I can add something usefull here, but I’ll try nevertheless hehe.

I’ve never seen a group working on a piece of software which are as open, addicted and spirited as you guys.

What I do miss however is some clear roadmap put somewhere. Like gcc, or kde has.
Submit your ideas, and proposed target finish date on the wiki, update the status, and the "release" manager then can decide if it will make it into the next release or not.
After a number of releases - or one release actually -, kick out the release manager, those people never can do any good to the devs haha.
Seriously, a release manager will do just like Ryan did, and thats asking "when do you finish your idea, where’s the code" etc.
Developers get nervous of such people, so it could make sense to have different release managers for each release.

Program against a "base code", and keep in touch if your changes can effects others work, and everything will be lovely...

About using SVN, even if your work changes a lot and isn’t supposed to make it yet into the base.
I like to use it for myself. I can look back at what I did, read the commit comments at what I did at which time, why I did it and so on.
Others can look at that too, and make suggestion early in your development process

Man, I wished my little project had such a team
Hmm, perhaps, Me and Myself are 2, no? ;-P

Keep up the great work, a little disagreement is nice now and then, keeps your mind sharp

Remon

P.S.
Ah, I knew I forgot something. Release when it’s ready, not earlier. Better to release one month later, then start to get hasty and loose focus....

P.S.
Idea: Try to attract someone not to closely to the project, and make him the release manager. He/she perhaps is better at keeping an objective, I hope thats the correct word, overview, instead of someone to much involved into the project?
But I could of course be completely wrong here....

Thanks Ramond, Remon, Adam and Jason,

I think Remon summed up quite well what I’m trying to get to ... a consensus and a target that is well communicated and explored as a team. I find it difficult to plan and figure out what’s going on without seeing the code and playing with it, even if it’s raw and buggy. The ideas have been phenomenal. I’m just trying to push for more of the style like what went on with the parser ... lots of small demostrations and great dialog.

Agreed, to be truly effective as a team, we have to have a plan and a model to use, be it graphical, textual, or otherwise. This encourages good code by giving everyone time to provide feedback about how certain features might/should/could work, before a bunch of coding effort has been put in to implement it.

I just want to offer some basic, simple, and clear principles for development.

• 1. Keep it iterative. We never need to make huge changes to get from point A to point B --> iterative changes are infinitely more manageable (from a development and an upgrade standpoint) and are much less likely to fail or over-extend their timeframe for implementation
• 2. Automate. Why do something over and over again; even if it only takes 10 mins, I’d rather spend 3 hours automating something than spend 10 mins every day doing it manually.
• 3. Collaborate and discuss. I spent time doing Extreme programming, which requires two programmers per workstation. I’m certainly not going to pretend that we can do this ever with our project of remote developers, but we can inherit the spirit of the approach by having two programmers look at the code on a day to day basis as it is being authored (nothing more than a simple "hey, check out what I did today...". I truly think this will improve our code (and our individual knowledge/comprehension) more than you can ever imagine.
• 4. Design -> Test -> Implementation. If we can get a unit testing infrastructure in place, every task/bug we work on should be a three part exercise: design the interfaces for implementation (what methods do I need, what properties, what parameters, etc.), write a test class for your new methods/properties, and then implement it! Just helps you get perspective on what you are authoring so you don’t make hasty implementation decisions, and ensures there is always a test for the code being written.

Any other thoughts in this area?

Jason, I think that very much nails what I’d love to see in the practical sense, which RS summed up in the conceptual sense.