MadFish wrote:
I thought a few weeks ago a few people had started jointly writing a vision statement or manifest for XOOPS. I thought it was quite good but problem is I can't find it (all I remember was I think carnuke/rabideau were involved).

Might be useful if someone can dig it out?

carnuke wrote:
This is a long post, but it encapsulates some important stuff. I hope it is helpful

There are some crucial issues here that I think need to be explained.

Open source development is usually driven by developers who expand their projects to make them available to public involvement. The project itself is both a concept and a codebase, that is, it has an objective to be useful, entertaining or informative and the code is built to support that objective. Most open source projects begin by developers promoting their code and concept and build on the project from there. Projects usually start from a small idea, even just a single developer who does the whole thing by him/herself.

Up to a point this all works fine, the developer may get some interested people to help develop and test out the code and develop the project further. The problems set in when that project gathers a certain critical mass of followers and users of the code. Gradually the developers see that there is a need for documentation, Organisation, communication of updates, news, file downloads, etc, etc. In effect all this extra stuff is nothing to do with the codebase or the concept; it's the needs of the greater community. It's meta to the real heart of the stuff and can become a real pain to deal with.

So here is where we go wrong and this is not just XOOPS but endemic to many such larger projects. The developers feel quite rightly, that this is 'their baby' and no-one and nothing is going to part them from their work and Kudos. So they hang onto everything. They continue with coding and developing the project and try their danrdest to throw out some help files, run a forum, make archives available and generally run the whole show.

If they have other developer helpers, they will try to divide the duties, giving a real effort to organise and produce meaningful feedback and content for their beloved community of followers.

Sounds good -eh? does it begin to sound familiar also?

Notice one thing here: The people running the project are all probably developers, who really have one main interest and skill and that is erm ... writing code and developing! Whet they start to find is that the demands of their community of followers is taking more and more of their time which they would rather be spending in cutting good code. But they have to maintain the community, because this is their support structure, this is their Kudos and this is their ready audience to approve and accredit their marvelous project.

Soon the cries of documentation, Organisation, communication and forum participation have angry overtones of disappointment from the community. Great software, but where is our support? we need you, we want you, you have an obligation to us.

What's happening now? The developers are torn, both in their commitment to the project codebase and the community needs. They are distracted by what they should be doing and what they feel obliged to do. The codebase begins to suffer as their time is divided. Feature requests pile up, bug reports flood in, their family/ social life suffers and everything goes pear-shaped.

So what has gone wrong here? if this is a real model of what can happen, what should we do to prevent this happening?

1- The first problem is that the initial developer/s need to understand something. There is a world of difference between running a code based development and running the needs of a support community. They are NOT the same thing. They both need different skills, approaches and support structures. Many developers think they can do it all and that is a mistake.

2- The second problem is that the developer/s hang on to their project and try to quickly learn the skills of communication, management and leadership as well as continue to write and develop the codebase. Big mistake. No one person can do that.

3- Big mistake no 3. You may be an excellent computer programmer, you may be able to write code to dazzle your peers, but that is no indication that you have the skills or qualities to be a manager, or a leader.

4- The time factor. You just can't do it all! Something has got to give ... you know as a developer how many thousands of hours it takes to craft that code base. You simply won't have the time to commit to further duties and do a good job.

5- Attitude. You know that programming develops a certain type of 'mindset' you see things in terms of 'on' or 'off' Black and white. Yep, that's part of the attitude of mind that coding requires. The problem is that people are not like that. Many of them are ordinary users, who know tiddly-squat about your code base, they just want the goodies. It's not right that you should talk to them in technical terms that they don't understand and it will probably hard for you to translate their 'layman' language into meaningful code ideas.

6- Leadership and management are not the same thing! As a developer and programming specialist, what do you know about that? Are you aware that there is a whole set of different skills required to lead a community and that to manage the structure of support for the community is likewise totally different from leadership? If you have business skills and training, you will know this.

7- Firefighting. That's the worst problem of all. This is the critical stage where a project starts to fall apart and break into factions. The developers are now self appointed leaders, managers, communicators and administrators. Oh, and coders as well! They desperately try to keep 'all the plates in the air' and hope to god they don't drop any. But they eventually do. Firefighting is a perilous job, it's ugly and destructive and makes everyone look ridiculous.

The solution:

Phew!, here's the good bit, but with a serious and difficult caveat at the end. When an open source project starts to develop publically, there are some critical changes that must take place. It's called 'Forward planning', or if you like a road map

1- If you are a key Developer or owner of the project, here are the key things you must do when your project reaches a certain critical mass with community followers:

- know your limitations,
- know where your skills lie,
- prepare to delegate responsibilities,
- let go of your egos,
- seek out managers to manage,
- understand the meaning of leadership, and let one arise.
- be prepared to let another take center stage in the community sector,
- don't interfere with another man or woman's skills,
- Realise that you are now another contributor, not the king.
- In short, become a team player (ouch!)

Now the painful caveat ..

What do we do if a project has already got to the firefighting stage? how do we recover what has been lost, corrupted, destroyed and the people that are hurt?

1- You have to collectively say the word STOP! and draw a big red line here.
2- That means everyone, including those people who are firefighting.
3- What's already burning probably needs to go anyway.
4- Someone needs to take a position of leadership.
5- The rest of the community needs to stop all the 'static' and listen...
6- A 'true leader' will know how to pour soothing oil on the wounds, but also speak with strength, dignity and authority.
7- S/he will immediately recognise and collect a small team of people who can manage.
8- S/he will delegate jobs to them, based on their wider experience and skills.
9- S/he will understand the needs of human reconsiliation as well as the codebase needs.
10- A true leader is able to let go of demonstrating his authority through ego and power.
11- A leader does not try to manage the people, s/he manages the managers.

And the difficult bit? ... it's turning off the 'static' it's drawing a line, it's the doing of it.

The situation in XOOPS at the moment follows closely the model outlined above. We have developers hanging on to leadership and firefighting. We have people who are skilled in computer programming who have been seen by the community as key players and thus deemed suitable as managers and leaders. They are not, they have not the right nor the skills to be there. They are compromising not only the requirements of the community, but also the codebase development. They need to let go of their egos and we ned to to release them to do the job that they are skilled and respected for.

What XOOPS needs now is to draw that line and let go of the small developer based mindset. This is now a large community that needs real leadership and a proper management structure. We need developers who have the space and time to do just that and nothing more required of them.

Again I ask the question, can we recognise it, can we do it, can we evolve into what we should be?