Is it just me?
We've all seen these disputes among development teams of all manner of such projects. Obviously disagreement comes with the territory. If two people agree 100% of the time, one of them is not necessary... is the expression that comes to mind.
But why is it that when the going gets rough, core principles of the whole movement are abandoned? Open source, open discussion, open participation and contribution, learning from each other, whether it's our successes or failures. This suddenly turns into conditional agreements of absolute silence, closed mediations, secrecy, and barely explained personnel changes. The pithy voice in my head is trying to remember whether it's the white smoke or the black smoke that lets us know about the change.
It's not that I can't understand it on a simple level. A mailing list lockdown for a single day, big deal. Staving off the flood of "WTF" messages and caffeine fueled diatribes ending in "SRI r00lz, I'll never use catalyst again!" announcements is fine. But the minimalist onward-and-upward pat on the back (lauded as "professional") teaches us nothing. I'd like to know why. I'd like to know why one opinion won out over another.
I can read between the lines like anyone else, but who can deny that some of the best, most enlightening discussions here on PerlMonks have been heated. Someone feels strongly about something and they end up providing great detail about their reasons. Regardless if you agree, you've probably learned something.
Catalyst has become a very significant project. Aren't we missing the benefit of how such a project is lead? Wouldn't we benefit from the technical details such as how changes impact other projects? Wouldn't we also benefit from seeing other's passion for their projects? At minimum, maybe it would expand our awareness of the community as a whole.
Like I said, maybe it's just me.
--
naChoZ
Therapy is expensive. Popping bubble wrap is cheap. You choose.
but who can deny that some of the best, most enlightening discussions here on PerlMonks have been heated.
++.
But the minimalist onward-and-upward pat on the back (lauded as "professional") teaches us nothing.
There's plenty to learn from it, if you choose to. It can teach you that there are alternatives to an endlessly escalating flamewar. It can teach you that irreconcilable personality clashes do not have to destroy projects. Civility is often in short supply on mailing lists for open source projects, and on the Internet in general. Personally, I'd rather see more of it, not less.
I would also say to the OP, that I don't seem to remember many (heated or otherwise) perlmonks discussions where the soul of an entire framework was in the balance.. Discussing for the sake of it is one thing, trying to decide the fate of a project is another. Also, the Catalyst discussing was taking place realtime, on IRC, thus it would have been a lot harder to preview content, consider, post only when really sure, etc, since by that time the moment is gone.. Thus heated discussions would have been a lot more so.
Civility and mediated discussion is definitely a plus, in my book, when things are at stake. Having them closed/private just means people can discuss properly.
C.
I'm sorry to say, but this time I can only see PAX ROMANA. It would be better understood and considered something professional (in the true sense of the word) if the conversations (even mediated) toke place in public, as expected from a proeminent open source project like Catalyst.
This was a big lost for open-source projects, IMHO.
It can teach you that irreconcilable personality clashes do not have to destroy projects.So is that all it was, "personality clashes"? Jeeze, I would have thought some technical visions of the ideal world, would have been behind it. I'm hoping this is more than a brainless contest of armwrestling.
I agree with the OP of this thread, covering up all the technical reasons behind a shroud of polite silence, is going to help noone. So, what's the difference between Catalyst and the new MoJo? I have no idea. And a situation like this one is not going to help anyone, especially not the outsiders.
Get rid of the mystery. If not, it can only hurt both projects.
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
But there is a "ME" ;-)
/J\
...and there is no team without it's individuals.
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
I know none of the details of the Catalyst project--I'm not even sure I know what it is exactly--and none of the details of the problems.
I do know that every team needs a leader. Every idea a progenitor. If you don't like the idea, you don't join the team. If you disagree with the leader and their ideas, you don't gang up to remove the leader, you go off and follow your own notions.
I'm an inveterate non-joiner for exactly those reasons. I'd rather influence (or not), through reason from the outside, than inveigle my way onto a project and then stage a coup--bloodless or otherwise.
I'm also an inveterate private projecteer, because I prefer to follow my own ideas to fruition or failure. It takes longer and may never complete, but it's a lot less frustrating than having to justify your decisions to other, johnny-come-latelys.
Very few technical debates have clear cut black & white answers. They nearly always involve trade-offs and priorities and value-judgements about those. In a volunteer project, IMO, the progenitor gets the casting vote--even against the numerical weight of opinion. Those who cannot live with the progenitors decision have the option of forking the project or starting their own.
In the commercial environment, you do what the man-who-pays, tells you to do.
In a volunteer project, you do it for your own reasons, your own motives and your own passions. Once a project ceases to be something you look forward to doing, and becomes something you start avoiding, you best drop it and move on. The quickest way for a passion to become a burden, is for you to loose heart in it's direction. And the quickest way for that to happen when you are the progenitor of a project, is when you loose control of the direction and goals of your ideas and efforts.
Does any of this relate to the Catalyst project? I have no idea.
But the team is an entity in addition to its individuals.What addition? Are you trying to say "the whole is greater than the sum of it's parts"?
That statement only means you don't understand the parts well enough.
There is only the parts. There is no 'addition'. The team consists of it's individuals. Period. I don't hold with this pseudo spiritualist malarky.
Or, if you want non-American football, the goalkeep trusts the defense. The midfielders trust that when they kick the ball up in a leading pass that the striker will know what's happening and be there.
Or, do you feel that, as an individual, you can win a soccer game on your own?
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
An individual doesn't win the football game: the collection of individuals does. Every individual plays a part in the win or loss of a game. Replacing some of those individuals with other individuals can alter the likelihood of a win pretty drastically. "Teamwork" is the doings of people in the particular, not in the aggregate. People have to work at it (thus the name) as individuals.
There is no centralized entity. I have experience of being part of a team in one of the most team-oriented circumstances in this life -- combat infantry. When you have a fireteam in combat, you should try telling any of the soldiers in that fireteam that the team itself is the important entity, and the individuals cease to be discrete, separate entities themselves, for purposes of "winning". Try telling that to the members of a Ranger fireteam, for instace, whose first rule of combat is that one never leaves a fallen comrade behind.
I don't mean to create some kind of "patrioticker than thou" argument here. I'm just raising the stakes of the team beyond that of a football team, because when lives are at stake the pseudophilosophical pop psychology goes out the window and people start recognizing the nit and grit of what's going on. Sure, a soldier may give his life, but he doesn't do so "for the team". He does it for an ideal and/or for the guy next to him. It doesn't get any more individual than that.
I think I'm more inclined to agree with wfsp's characterization of a team than yours, I'm afraid.
Yes, individuals win (American) football games, as long as you have eleven of them on the field at a time.
|
- apotheon
CopyWrite Chad Perrin |
You can see that this is the important facet of the team vs. the individual by looking at a Ranger fireteam. When one member charges or flanks or whatever else it is that they do, they do so knowing that every other member of the team is in sync with their movements. They move as one unit. It's not coincedence that the military uses the term "unit" as the name for the smallest group of soldiers. Those soldiers are supposed to work together in such a way that it seems like there is one brain controlling 6 bodies. They are, in theory, supposed to be able to anticipate each others' moves and do things that six individuals wouldn't be able to do.
I was calling that trust, and trust is the key to it, but I should have used the word synchronization. Between 6 people, there are hundreds of connections that are formed, both between the individuals as well as between the groups the individuals form. When a fireteam splits into pairs or a pair and a group of four, each group knows how the other group(s) will act, how they'll act, and when they'll act.
While I'm not suggesting that the degree of cooperation in a Ranger fireteam should be the model for a OSS development team, I am suggesting that we could learn a lot about the kind of cooperation that's necessary to truly accomplish something in a cooperative fashion.
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
That's training and predictive cooperation, not telepathy. It's more like a computer program than an overmind.
|
- apotheon
CopyWrite Chad Perrin |
There is only the parts. There is no 'addition'. The team consists of it's individuals. Period. I don't hold with this pseudo spiritualist malarky.I disagree... a team is only as good as they function together.
You can lay all the pieces of a watch on a table, and all you have is the *potential* for a watch... Put them together, and you get a watch... There's nothing different about the pieces, but the way they are joined together for a purpose makes them 'more' than they are just being near each other.
The same is true of people... You can take four people and put them together and *call* them a team, but there's still four people... and they might make useful stuff
But take the same four people, and let them bond and *really* become a team, and you'll see amazing things from them.
All I'm saying is that there's a difference in 'a bunch of parts' and 'a bunch of parts put together for a common purpose'.
That's the meaning of 'the whole'... The 'whole' is the purpose that joins the parts... that's what makes it more.
Trek
It's the characteristics and behaviors of the parts that make up that whole, though. A whole is only the sum of its parts if you consider that assembling the whole to form a cohesive team involves redefining the parts. A team learning to work well together doesn't require some magical addition of aggregate entity mojo (pun intended) -- just that the individuals on the team grow and change so that they work well with the other individuals.
|
- apotheon
CopyWrite Chad Perrin |
This is a matter of opinion only, not anything that can be demonstrated. Statements such as "the whole is greater than its parts" or its converse are simply statements of faith or opinion; they are axions.
Also, "spiritualist" refers to a belief that one can communicate with the dead. It has little to do with Aristotlean assertions.
But that's looking at it from the other direction. In which case you'd have "MEAT". Which should be heated, much like the discussion.
And you just know that's going to torque the vegans to no end.
Or something . . . . At least this makes less sense than I just did. I hope.
Update: Actually you'd have "MAET". Marginal sysdlexia FTW.
TEAM MEANS REDRUM!
The issue is not whether some person in the team thinks he's bigger than the whole. The problem is that when you stop acknowledging the individual members of the team as just that -- individuals, their own persons -- you run the risk of alienating people. See 1 Cor. 12:14-26 for some biblical reinforcement of the dualism (or is it duality?) of a team.
I'm not saying that everyone should submit to the Collective. I'm saying that you can't have rabid individualism and still expect to produce a good product.
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
True, but there is a "U" in "SUCK". (Nothing personal. Stock response only. May contain trace amounts of fat.)
There are individuals within a team, and any team that forgets to consider the value of the individuals -- as the "no I in TEAM" epithet seems to suggest -- is a team doomed to homogeneity and all the failings that implies.
A collection of thoughts and links from the minds of geeks
The Code that can be seen is not the true Code
I haven't found a problem yet that can't be solved by a well-placed trebuchet
Taking that to its logical conclusion, I'm prompted to make reference to groupthink. It was defined by a psychologist named Irving Janis as "a mode of thinking that people engage in when they are deeply involved in a cohesive in-group, when the members' strivings for unanimity override their motivation to realistically appraise alternative courses of action." I tend to have negative reactions to teamwork-conformity platitudes like "there's no i in team" precisely because of my experiences with groupthink in the past.
In point of fact, I think the phenomenon of groupthink is a fair bit of the mechanism behind not only bureaucratic inefficiency, high school drama, and office politics, but also -- in a more abstracted sense -- the successes of market domination strategies of large corporations and even political elections. It's not only important to recognize the contributions of the individual, but also (and perhaps more importantly) to avoid letting the individual be subsumed by the collective. Otherwise, you run the risk of becoming the next SCO, with no greater aggregate talent for innovation than your ability to dream up new lawsuit revenue scams.
|
- apotheon
CopyWrite Chad Perrin |
However, there are very very few discussions like this *ever*. Even amongst so-called professionals. Almost always, emotions get involved. I'd say this is even more likely in an open-source, Internet-based environment. And even more so where people have founded projects that have grown hugely.
The actions taken saved the community from the embarrasment of seeing the leaders of this project exposed at their most vulnerable. True, it's not totally transparent, which is usually something to strive for in open source projects. But would we have learnt much from it? Only that everyone's human, everyone gets upset.
Now that the bans have been lifted, we may get some less-heated discussions on what caused the difference of opinions, which we *may* learn something from. Once everyone's has a chance to cool off a little, they can see that their differences were purely philosophical, and realise that the split was for the best. This can then allow them to present the arguements in a more objective, un-emotional manner. I'd rather read that than something that was said in the heat of the moment.
I'm going to take a moment and expose my ignorance.... Could you link to something/anything about what you are talking about? I googled and searched PM with no sign of what you are atlking about. I have heard the rumors of Catalyst Cataclism, or something like that, but nothing anywhere seems to hint that anything at all has happened. ;)
___________
Eric Hodges
Sure. brian_d_foy announced it recently, Sebastian Leaves the Catalyst Project
--
naChoZ
Therapy is expensive. Popping bubble wrap is cheap. You choose.
I've seen meltdowns that were public, and meltdowns that were kept private, both in the open source and commercial worlds. Just as the emotions of the participants are their personal business, so are the choices to make it public. Most of the times I, personally, have been involved in a public meltdown, I've sure as hell wished it'd been kept private. At least, after the fact... ;-]
Wanting to learn what happened is only human. However, I'd like to suggest two things. First off, the technical issues on each side have almost certainly already been made public through ML discussions and web pages, et al. Secondly, let me suggest that you'll never really learn how to avoid a meltdown by watching. No matter how much fun watching a football game on TV is, you're going to get painfully flattened if you even think you can walk onto the field during a game.
Meltdowns occur for lots of reasons. Sometimes it's technical, sometimes it's ego. Sometimes it's just a choice being made that doesn't 'sit well' with a team member. Sometimes it's that the people involved really believe their project is an important one and needs to be "done right". Maybe it even really is that important. Certainly that has occasioned more than a few of the "left in a huff's" that I've seen in the FreeBSD Project, and cooler heads have sometimes come back to work. The important thing to realize is that the reasons for any given meltdown are specific to that team and that meltdown. Monday-morning quarterbacking doesn't add a whole lot to the situation, no matter how much fun it may be.
It may seem as though there are more meltdowns in open source projects than in the commercial world, and there probably are, but there's also a bright side. Open Source projects can be picked up by anyone who has the chutzpah to take them on. Very few of the commercial meltdowns I've seen have been recoverable.
As a user of open source, as opposed to a developer, I've come more and more to realize what an exceptional and amazing contribution to humanity that this whole movement is, and how much we rely on each individual developer to keep his/her act together in spite of the pressures. Given the lack of financial compensation that is so prevalent in open source development, these pressures can be monumental. We who are merely users need to do our part to support and encourage those who develop. A few quiet /msg's at the right time -- OFF LIST -- can do an amazing amount to shore up the self-motivation of a talented developer. No matter how much they're doing it for their own reasons, praise helps. Money, too, whether it's a new development server or just a beer. I realized this past tax season that I've contributed more in time and money to open source than I've paid for Microsoft products (though not (yet) for all s/w I've paid for), but, then again, I've made more money as a result of open source. I can't count the value of it, for myself or for the world. It's too high! :D
Don Wilde
"There's more than one level to any answer."
Fear not for your competence. I'm sure I'm a less-competent Perl programmer than you (so far).
That aside, I find no fault with anything you've said in this node, and I agree.
One of the things I find most pleasing about the dynamics of open source development is the way it harnesses the energies of disparate, intensely individualistic people in a way that allows them to wander in and out of projects, contributing to a cohesive whole (unless and until they start or get stuck in a project that means enough personally to prompt them to invest more than dilettantism) without having to subsume the individual in any way. Every individual's talents and efforts are individually important in the creation of the whole product, in and of themselves. One doesn't tend to run into the situation typically found in proprietary closed source development circles where someone passes out orders and everybody falls into line for fear of losing the paycheck. That's how marketing flacks gain traction while engineers lose it.
I think perhaps the best thing one can do to help an open source developer maintain the motivation to stick with a project is to remind him or her of what he or she gets out of it. People tend to go into these things for selfish reasons, and I think that's a good thing: when you start writing software because you want the software you're writing, you have a personal stake in producing the best software possible for your purposes. That's why open source development works, for the most part. When a particular developer reaches the point where that motivation for developing a particular piece of software has been worn down while the aggravations have built up, it's best to help the developer remember why he or she started working on the project in the first place. If that's not enough any longer, or if that prompts him or her to fork the project, so be it. At least then the developer will be making the decision for the right reasons.
|
- apotheon
CopyWrite Chad Perrin |
Frank Wiles
www.revsys.com
It's not just you. I thought how it was handled was fascist. People should be free to say what they want, and at the same time they're free to judge others by what they say. The way it was described by Alias in my opinion indicated a major overestimation of the importance of the problem and the project. RAISE SHIELDS! RED ALERT! Too much Star Trek or RPG playing.
And a project calling itself "Elegant" still irritates the piss out of me. Catalyst--