As I prepare for a trip to Denver, where the august board of directors may well be tempted to make yet more rules, we really do need to take pause for a moment and consider if Eclipse's symphony of rules contains any sour notes. Do we really have only as many rules as required, neither more nor less? I rather doubt it. Watching the progress of 237412 makes me wonder about the actual value of the rule about incubation, and where exactly the dividing line is between the rule as is was written and the policy around its interpretation. It even makes me wonder about the actual intent of the rule in the first place. It's seems perhaps like a game of telephone where a little is lost and a little is added at each step from the conception of the rule to the final implementation of the rule.
I've not been on the board long enough to know the origin of all the rules, the incubation one being one of them. It probably sounded like a really good idea at the time. Similarly when the board decided that all projects should have a navigation link to a consistent collection of project metadata, it must have seemed like a smashing idea; consistency is like motherhood. Unfortunately, getting the Eclipse community to follow rules consistently is like herding ill-tempered cats. Our beloved Bjorn Freeman-Knuckles-Benson typically ends up with the unenviable task of enforcing those rules. But what can he actually do to encourage, and ultimately force, all projects to conform to this or any other board edict? Generally people will just ignore what they're being asked to do, and apparently the board members themselves don't actively participate in the process of encouraging their own employees to follow their own edicts. If you don't act, he may just have to replace your home page. Won't that make him popular?!
I'm going to cast a more critical eye on the making of new rules. I'll question whether it's just a good idea, or something truly required and hence something to be enforced. I'll question how it will be enforced and the penalties of non-compliance. I'll question how the affected parties will be informed about the new rules. I'll question the cost of complying to the new rules. And I'll question the cost of writing them, maintaining them, learning them, and enforcing them. I might even question a few of the rules we already have. I wonder if this will make me the most popular board member?
Posts
7 comments:
Ed, well spoken. In some ways eclipse is starting to migrate away from it's agile principals and founding to a more traditional project management structure. I believe the IP policy is a good one, but it seems as some of the other items while well intentioned are just a burdon to the Project managers and the developers in general. If we are just creating paperwork to create paperwork, it's a rule that needs to go. We need to keep the entire process as light as possible. Not only will this help existing committers and projects, but it will make it much easier for new people to join a project and get up to speed. The Eclipse Foundation, should leverage the work of the EPF Composer group and generate their methodology and processes with that tool. It even produces a nice little web site. By having it documented consistently and in one place, a better overall picture of what is needed and what is just "oooh...we need this because we have it where I work" stuff.
Tangent: that first photo would make a beautiful watercolor. Mind if I borrow it?
Kim, you're more than welcome to exploit my photography!
Hi Ed,
>I wonder if this will make me the >most popular board member?
:) obviously not...but it might make you a popular committer (and even community member).
<soapbox on>
To put it simply, I think the corporate members of the Board are welching WRT their commitments. They require (and get via Board and EF) all sorts of things from projects/committers...obviously to serve their own interests (e.g. retentive IP, 'enterprise sw process', product exposure, etc., etc). While at the same time they don't meet their own commitments WRT supporting the actual software development (i.e. supporting committers to innovate on Eclipse/EF projects, rather than their own products). This is rabidly self-interested at best, and exploitative at worst...and getting more so as IBM pulls back from supporting Foundation projects in favor of Jazz, Oracle develops and promotes an IDE competitor, and other corporate members contribute little but $$ and more rules. IMHO, these things make the EF less than healthy from the point of view of the committer, adopter, and user communities.
<soapbox off>
Too many rules, you say? Nah, there's never enough process to go around. :P
Dave, you keep saying that "Eclipse" is migrating away from agile and yet you don't offer any specifics (nor do you distinguish between the EMO processes versus the way each project manages itself). I'm assuming that your complaints are about the EMO processes, however I find it hard to claim that the EMO is forcing a more traditional management structure (I assume you mean waterfall). If you look at the history of the rules that the EMO (which includes the Councils) has written, you'll find that there are fewer of them today than there were two and three years ago. So the rules are actually getting lighter and more agile...
Of course, I still agree with Ed that we should only have rational rules that everyone is actually willing to spend time/money to implement.
I think there are few people who can claim they've done more to help make the rules more sensible than Bjorn. Unfortunately, as the enforcer of the rules, often ones he didn't help write and sometimes ones he might not even agree with, he's all too easily seen in a different light. My general impression is that things are improving.
Post a Comment