Hate to put a spanner in the works, but I have to agree with the person you quoted. In many respects this is the same wolf leadership team in sheeps clothing. Nothing progressed in three years, nothing changed, same old discussions and same old problems. If your going to clear out a dusty old garage for you nice new clean car, get rid of the old car first.

Quote:

You're right, and you're wrong. Let me explain
You're right the previous teams were too closed by design. This could be part of the reason why they failed.

Whether an open team structure will be more successful I doubt. And you provide the argument for that yourself (so this is where you are incorrect IMHO).
Transparency and an open structure are means to an end. And the end here is to provide the means to make everyone take responsibility. Is isn't a no-strings-attached situation, true openness. It means that everyone is responsible, and accountable too. Openness is a means for everyone to take action, not just hold those who *do* take action accountable at all times.
And this is where it conflicts with leadership. Having someone responsible by default means that there isn't true openess and transparency. If a select few are responsible, things are going to be done their way, so they can control the risks of being held accountable. This is truly unavoidable.
And this is why a truly open team structure is bound to fail by design as well. You can't have some people responsible with an open membership structure where anyone can get in and out anytime they like. There's no way to make someone accountable for their choices, and thus responsible and open. And transparency doesn't solve that particular problem.

So, the truth is probably in finding a working balance between leadership and full transparency.

That is why I propose a self-organising community. Let the core devs deal with code development and decision making methods common in open source development. Let the Foundation take care of corporate communications and product promotion, which ever way the project evolves. And let the support community organise itself, without an all-overseeing body of people responsible.

Herko

That pretty much makes sense to me as well.

(And I am sorry for getting involved again - when I had intended to just have a break from moderation... )

Quote:

No, this is the closed team model. It is exactly the opposite of what I mean by open teams.

The leader of an open team would be responsible for coordinating the effort of the wider community for some aspect of xoops. That might mean:

* Maintaining a list of tasks that need doing
* Trying to encourage people to take on particular jobs
* Encouraging people to work together
* Encouraging debate on a common direction
* Encourage community comment and review on technical contributions and suggestions from community members
* Delegating any or all of the above to others!

Anyone interested community member could:
* Take on tasks that need doing
* Propose new tasks or improvements
* Provide input on direction of that aspect of xoops
* Help review technical contributions and suggestions from community members.

This is an open way of working.

Yes the coordinator may be called on to make a judgement call from time to time when there isn't a clear consensus on something (we need that) but they absolutely should not be dictating direction or doing things 'their way'. The accountability issue can be solved simply by introducing accountability mechanisms.

------

This and my other posts are not shots at anyone. Please take it at face value, I want to make things better, that's all.

it's time to make some changes in xoops.org

for me, for you, for XOOPS...

...

Quote:
This is the way the Core and Management Teams have worked in the past. Exactly like that. I am serious, ALL the above is what you will find, in various degrees of openness and closedness.

This isn't truly open, because there is a scarcity of resources, and these need to be allocated by the coordinator.
This means: deciding 'what needs to be done' based on concepts and ideas that are not the result of a public consent mechanism (as getting this public consent at this strategic level is impossible, ask any organization). This will be based on what the selct few feel 'is best for everyone and the project'. This can be monitored and judged by an accountablility system, but that's only *after* the fact, and therefore counterproductive.
Since there aren't enough resources to do 'all the work' (everything that 'needs to be done'), judgement calls need to be made. This by default means negotiations, because people will have to free their personal resources to make it happen.
Encouraging people definately isn't enough. Especially if that coordinator is to be held accountable for the resource allocation choices made. Then this coordinator will need to be given the resources to hold people to their promises, to make them to something slightly different then they would themselves in the interest of the common goal and plan. And this can never be the case, because this would be in direct conflict with the openness.

There hasn't been clear community census on anything, ever. There have been many many looong wishlists, but only very few people willing to add their resources to the common pool to make them happen. Most of the time permission is asked to actually do something. Why? Isn't true openness about being able to add value? Then do so. There doesn't need to be a leader that will allow you to do anything. If theres a need for coordination, this can be done by the people actually doing it. And then they can be held accountable by their peers for failing to do so. Why make someone else responsible for that, when it *should* be placed at the source?

Like I siad before, if this is about leadership, it should be about everyone becoming a leader and taking responsibility. Not delegating the responsibility to someone else, without giving them the tools to actually do the work. Why make someone responsible for everyone else's failure to think about the consequences and coordinate their efforts?

True openness means everone is a leader and responsible, and accountable by his or her peers. Isn't that what open source is all about? Freedom to express yourself?

Herko

Quote:
If we take an example of something that has been on the list for a long time: the XOOPS site restructure

How would you think this is best arranged? Apart from the items mentioned above, where do you start? Who has a stake in this project?

Note: I have no idea what the current status of the site restructure is at the moment

Quote:
the add-ons subsite was quite finished at mid january, but some, too perfecionnists, dreamed about a better one that needed some module dev for that.
Conclusion : the addons is still at the same stage as when i quit the team (and for other reasons i won't developp here )
i much more prefer small steps (with a vision) that never ended/started big jumps.

about the overall project, would be better to check first who are still the core dev before dreaming about anything. And the mandatory element is to have a team, with team spirit, the ability to share ideas and the willingness to go further quickly and with efficiency. In words 3 pragmatism, humility, honesty. i'm starting to think would be better to rebuild from scratch.

that' not the case for now.

Look I just can’t agree that the teams have worked in the past and I don’t think its how they are working now. The reason that we have a scarcity of resources is because people are unable to contribute. Offers are being made and ignored and people are frustrated.

I can’t understand how the open teams idea above could be seen as ‘not truly open’. The resources under this model come from enabling people to contribute as they wish. The coordinator *isn’t telling people what to do*, they are *maintaining a list of things that need to be done*. There’s a big difference! That list *can be added to by community members* and it doesn’t stop people from contributing other things - it just gives a bit of suggested direction on important issues.

This is a community driven approach that is participatory, allows freedom of expression and facilitates wide input, while helping people to build on each others efforts. That’s what I think that’s what open source is about!

When I speak of accountability my main concern is simply that there should be a mechanism for removing people that aren’t active, or that aren’t allowing others to contribute.

------

Just a reminder: This is nothing personal against anybody!

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?