Successful open source development

I only do programming very occasionally, so have never before participated in an open source project. I have always been intrigued by the idea of community open-source development mostly because of the spirit of unselfishness that it can promote. So I'm jumping onto this one because it's an opportunity to get in on something with great potential.

I'm wondering if there are some best practices or good management models we can glean from other successful open-source projects out there. Naturally the first prerequisite is talent and a good idea, a given here with the great brains that have started this project rolling. But how do you sustain it into something that continues to grow rather than stagnate?

I'm just thinking on my feet here, but here are some or the factors that come to mind:

1. Vision and leadership. Stating a clearly focused mission that others can easily understand and support, and keeping it on track.

2. Structure. This one seems pretty crucial. Here is an interesting excerpt from an article I just glanced at, talking about the challenges of open source development. One of those is:

"... the tension between embracing the informal work norms and ethos of the hacker style of programming with the need to be more predictable and coordinated in managing software releases. Projects that are more closely coupled with commercial firms have experienced direct pressure from firms to communicate better and do more formal planning of what will be included in a release and when. Several projects that have created foundations are experimenting with this tension now—"How much structure can we impose on volunteers?" People are intimately aware of the fact that too much structure will disenfranchise the very people who make the most successful open source projects possible."

(from http://workingknowledge.hbs.edu/pubitem.jhtml?id=3582&t=technology )

3. User friendliness. You can put a lot in this category: marketing, documentation, support, etc. Fall flat in any of those areas and you won't attract users. And many good ideas do completely fall flat here. It's evident in the plethora of ugly, incomplete and geeky web sites for open source projects.

There's a lot more that could be said about those 3 areas, and there are probably others. If others agree these are good areas to look at, I wonder if we could come up with some practical solutions.

Well, I think that I can help with this one because I have worked with many Open Source.

Leadership, this one is very but very important, in everything is good to have a back-up, because sometimes crucial people disappears because they have problems. And they can't tell us, but not always is possible.


Structure, yeah, there should be a structure, documentation for tell the people how to contribute, etc and the code very commented in a language. In this case I'm sure that you would select English.

User friendliness: Yes that one the people loves it, if you make a friendly community even if the software isn't that good but you treat them very good, they will come.

Another one that isn't mentioned, we shouldn't have pressure, sometimes happens, but in Open Source, stress is something that doesn't exists, so you should relax, and the software will be ready when it's ready.

As a founder of this happy little community and having been a team member and user of other OS projects that have imploded or broken up, I can say the general reason the others have died is because of the way they were run from the top.

Two camps have emerged in dysfunctional projects that I've seen:

1) Projects led by incredibly talented developers that didn't deal with reality of dealing with users

2) Totally inflexible developers who refuse to ever incorporate anything from the community

We'll be doing our best to make this project an outrageous success. At times, that means "non-founders" will be running a large portion of things. At other times that means the project will be run more under the "benevolent dictatorship" mode. However, we will take everyone's ideas and input into account and try to stay true to the original project goal of making a world-class CMS that also happens to be one hell of a great Application Framework.

We'll also do our best to communicate frequently, honestly and openly about what's going on. This is not an ego trip for us; we need great software and so we're creating it. We also feel that the end result will be better if we leverage the minds of more than "just us."

Regardless of how the project is run, the end result will be easy to use software for first-timers, that also just happens to provide more technically inclined developers incredible flexibility and power.

rthrash, that sounds great. It's how an Open Source proyect should be.

The magic words there are open and frequent communication. The more people know about the direction of the project, the less irritation you will get. Acknowledgement of ideas put forth by others is great even if it does not get implemented. It lets them know that you care and want to work with them to better the product

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 Yes
Easy split-menus No (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!)
Calender 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 Low (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?
What can we 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