Some questions about the project direction and management...

[Re-post - I put the original post in the wrong spot :shock: ]
Hi,

I'm a front-end designer (no-PHP) - and have done template work/development with Mambo, CMSimple, SOHO Launch, MySource, and Etomite.

I am developing a business relationship with a talented C++ coder (coming up to speed with PHP). We are looking to go much further than integration, and develop a business model around a small business CMS: templates/integration/support/training.

I'm trying to get an understanding if it would make sense for us to get involved closely with this project.

How will it work in practice?
As a business person (and non-programmer) I have a few questions:
1. Who is on the core team so far?
2. Is it practical to have non-programmers [with good CMS integration experience] have a serious say in the project direction? Will there be steering committee?
3. I have a list of items that I feel should be in the core distribution (although parts of it may be modules) - which I'll set out below. Any feedback on whether the founding team agree would be appreciated.
4. Will the project focus on being framework for business websites? [Are we steering clear of the being another community portal...?]

Where's the money?
I think one of the things that the contributors need to work out is how they are going to make a living out of this. For the team that have put so much work into modX I'm figuring that it works closely with their vision of how they can service their clients best. Will there be other ways the founders will make money from this? eg commercial modules.

For those coming on board now - we need to be clear that the "vision" works for us, and will be flexible enought to address our issues. Also I'd like to get some feedback from the founders and the community so far on whether they will discourage/encourage or feel neutral about:
1. commercial modules for some functionality eg shopping carts (like Mambo), Advanced SEF or is the expectation that all modules will be GPL?
2. commercial template sales?
3. commercial support services (eg Flash tutorials for sale)
4. non-attribution in the front and back interfaces (it seems the idea is to allow complete re-branding)

Features
Here is a short list of features I use for my CMS comparisons. I think modX is pretty HOT as it covers most of these things and allows a lot of flexibility for customisation.
Base functions
Per page templates - Yes
File management - Yes
Column layout - See http://website.soholaunch.com/marketing/demodemo/soholaunch_editpage.htm for interesting use of column layouts and drag and drop text editing
Styles editor - Yes
Basic form - Yes (snippet)
Form builder - Core module should be self-build for users (I am interested in developing this as a core module)
Breadcrumbs - Yes (snippet)
Search forms - Yes (snippet)
SEO - Yes (but I need to do some testing on the SEF aliases) Seems to work like Mambo SEF add-on modules http://dev.xaneon.com/products/alias/
FAQs - Yes (snippet)
Menus
3 Menu levels - Yes
Hierarchical - Yes
Non-hierarchical - No - I'd like to see a Snippet to allow for users to self-build menus outside the hierarchy in a GUI
Ease of use - Yes
List style - Yes
Jscript dropdowns - Yes (snippets)
Easy split-menus - Almost (I'd like some simple snippet for creating split menus - I will work on this)
"On" class - No (Like to see split menus - where the parent menus stay on, when a sub is selected)
Complex functions
Staged publishing - Yes
Secure Areas - Yes (thank you all modX'ers!)
Event Calender with permissions - No (I haven't checked the snippets for this - but not needed for core)
Gallery - No (I haven't checked the snippets for this - but not needed for core)
Blog - Yes (News snippet)
Simple shopping cart - No: Like to do an integration with a smaller shopping cart
e-Newsletter - No (and not wanted!)
Backup (manual) - Yes
Upgrade scripts - No ( I think this is being worked on)
Modifications, standards, Licence
Clean code - Yes, me thinks
Avail. developers for custom work - Limited at this stage (compare http://www.mambolance.com)
GPL - Yes (lets be clear that attribution is only required in the code)
CSS implementation - Excellent
Firefox/Mac compat - Yes
Training and Support
User focussed Manuals - Needed (I can help here)
Flash tutorials Needed - (once the functions have been settled)
Forum support - Coming
Ticket support - No (not coming in OS project)
The Future
Stability - TBA
Major changes - Unknown

Some other things I'd like to mention. There is a discussion in another thread about possible adoption of Smarty template syntax etc. I think we need to be careful about adding another "language" to the layer. Mambo's proposed move to PATemplate system for version 5 is already causing some consternation. Adding a template language adds another barrier to adoption.

What can we do?
We can contribute....
* development - in particular interested in building a form-builder (subject to discussions with my partner)
* user documentation
* testing and usability
* sample templates

Size matters?
Finally - how big do we want to be? Is this project designed to be close group of programmers and small web dev companies - with a tight focus on serving client needs? Or do we want to be BIG with lots of modules, lots of sites, more shared coding (and the management that goes with it)?

I forward to hearing a few views.

Regards

Richard

I'm trying to get an understanding if it would make sense for us to get involved closely with this project.

How will it work in practice?
As a business person (and non-programmer) I have a few questions:
1. Who is on the core team so far?

Today, that's Raymond Irving (xwisdom) and myself (Ryan Thrash). In the very near future, this will be different. To make this project a success, we need forum moderators in multiple time zones, additional people concentrating on different sections of the code and interface (with which they have relevant and extensive experience), and so on. I imagine we'll see the team of contributors grow very quickly.

2. Is it practical to have non-programmers [with good CMS integration experience] have a serious say in the project direction? Will there be steering committee?

I'm a PHP hacker at best, so I sure hope so! It takes me forever to code things, but I have a strong understanding of technical concepts, DB design, and so on. I know enough about it to be very dangerous, and little enough about it to ask some questions and start thinking down alternate ways of doing things. We will gladly welcome feedback from everyone, and particularly from people with strong areas of expertise and direct, personal, relevant experience.

3. I have a list of items that I feel should be in the core distribution (although parts of it may be modules) - which I'll set out below. Any feedback on whether the founding team agree would be appreciated.

When it gets down to it, the real core of our project is simply going to be a Data Access engine, a Plugin/module engine, a Access Control system and a Document parser (and the API, of course). Everything else should be a module.

4. Will the project focus on being framework for business websites? [Are we steering clear of the being another community portal...?]

No YAPS here. Ever. (Yet Another Portal System)

We're about managing content. Period. Now our definition of content means much more than your typical marketing site, so framework is an apt description. And there is certainly no reason why you couldn't BUILD a portal site in MODx.

Where's the money?
I think one of the things that the contributors need to work out is how they are going to make a living out of this. For the team that have put so much work into modX I'm figuring that it works closely with their vision of how they can service their clients best. Will there be other ways the founders will make money from this? eg commercial modules.

Very good question and glad you brought it up. While nothing has remotely been set in stone, we might create some commercial modules. These would be for specialized nice markets or applications of course, like warehouse management and picking ticket automation and so on.

The real truth for me is that I need this tool for my day job, which is building sites for companies. I've got 5 sites going up soon built on MODx, and another one starting today. I've said it many times, it's not really about the tools, but what you do with them.

For those coming on board now - we need to be clear that the "vision" works for us, and will be flexible enought to address our issues.

You have to keep in mind too that we were "ejected" and forced into starting MODx as a standalone project, so it's going to take a while to "codify" everything. I can say from personal experience in seeing other projects (with huge initial potential) become marginal that we're going to be proactive and keep an open mind about things, but we're also not going to derail things by trying to be all things to all people.

Also I'd like to get some feedback from the founders and the community so far on whether they will discourage/encourage or feel neutral about:
1. commercial modules for some functionality eg shopping carts (like Mambo), Advanced SEF or is the expectation that all modules will be GPL?

I hope to see a market for commercial modules spring up. I can see a great indicator of the project's being if people (even me!) can generate revenues from it.

If modules are commercial, I'd assume they'd not be GPL'd. Perhaps the project can be partially supported via offering a "clearinghouse" and central marketplace for commercial modules ... perhaps enough revenue will be generated to start our own non-profit foundation that actually might hire someone full-time to coordinate things ... just thoughts. Nothing has been set in stone to date and all options are open for discussion right now.

Commercial modules will be separate components stored in separate directories which may access separate data sources, so they won't be modifying the core code. In my non-legally-trained understanding of the GPL, this won't cause the dreaded "GPL infection" that forces people to license their modules as GPL as well. :lol:

2. commercial template sales?
3. commercial support services (eg Flash tutorials for sale)

Please do! On second thought, why not donate a set of generic flash tutorials back to the project as part of the documentation, and offer customized, branded version to individuals who want them for their business. The way I look at it, MODx conservatively stands at a time savings of roughly 2000 hours of Alex's original work and probably 1000+ hours so far in MODx between Raymond and myself.

4. non-attribution in the front and back interfaces (it seems the idea is to allow complete re-branding)

There will most likely always be a non-conspicuous copyright line in the Manager for MODx (or whatever it becomes called), and proper attribution of it (and it's Etomite roots!) in the credits. However, it will be nothing more conspicuous than the About box of an Adobe application which happens to contain licensed bits of code from other companies.

MODx will be very simple and straightforward to brand as your own. This is not about an ego trip or protecting our proprietary IP. It's about sharing a cool code base and hopefully having others make it even better, so that we in turn can work better/faster on our own projects. And if we happen to somehow manage to generate $s from the project itself (commercial module licenses, hosting, etc.) then that's total gravy and a bonus.

Your thoughts?

And on a side note, let's hold off on the second half of your post to maintain a general philosophy / project direction discussion here. We'll start another thread for that one soon, OK?

Thanks for the detailed response. It seems we have a very similar philosophy about this. The core is a GPL framework - modules, templates, snippets and training stuff can be GPL or commercial, but there should be an expectation that those who benefit should make some serious contributions to the community and OS stuff.

I'm getting a warm fuzzy feeling

One issue that I tacked on the end - is also about direction and philosophy....

Size matters?
Finally - how big do we want to be? Is this project designed to be a close group of programmers and small web dev companies - with a tight focus on serving client needs? Or do we want to be BIG with lots of modules, lots of sites, more shared coding (and the management that goes with it)?

Your thoughts?

Richard

PS: I will be starting on some user documentation and Flash tutorials very soon.

In this situation, we will inevitably start small and grow methodically and purposefully. I suspect in the end it will fall somewhere between the two extremes, realizing of course that we can exert no control over what folks do with GPL'd code or prevent them from starting their own wildly optimistic commercial endeavors.