At Thu, 22 Feb 2007 11:12:16 -0800,
Bucky Katz wrote:
> 
> I've done this in a _lot_ of projects over the last thirty years, and
> this is the *only* time I've had something like this happen.

Perhaps it's the only time you've allowed your project, or at least one
of its core components, to be driven so completely by developers outside
of your control (and even though you claim otherwise below, you also add
the caveat that the other cases have involved a project with stated
goals and policies that specifically meet your own needs, while NetBSD
only makes similar promises for individual release branches).

You voluntarily gave up your control over a quickly and sometimes
erratically moving target and you didn't manage to step out of the way
when its sharp edges got too close for comfort.  Don't blame others for
your decision.

Perhaps your decision wouldn't have caused you any problems if you had
enough programmer resources to overcome the divergence that resulted,
but I would guess that luxury is almost never available to most
developers doing so much work on what is to them third-party code.

Don't expect others to be able to read your mind and to be able to
accomodate your specific requirements into _their_ project, regardless
of whether or not they understand that you are a user of their project
who hopes to contribute back to it.



> > This whole thread feels like someone trying to pass the blame for a
> > misguided technical decision.
> 
> If we were developing an application only, you would be partially
> correct. Given that we're adding significant features to the OS
> itself, are you sure you still want to make that claim?

If you wanted to have sufficient control over the OS you were working on
then you should not have allowed decisions made by third party
developers (i.e. by the NetBSD developers) to have such an immediate and
detrimental affect on your whole project.

Leveraging the full resources of open source projects into time and
market sensitive commercial projects is a very tricky process and really
can't be undertaken successfully without significant and direct
co-operation of the core developers in the open source project, and
without some open and mutual agreement and understanding of goals.

In your position I would have wanted at least one, maybe even two,
full-time developers with the sole task of continually tracking NetBSD
and polishing local that are most likely to have general utility to the
whole NetBSD community into a form suitable for NetBSD (e.g. porting it
to -current and testing it) and then generating PRs with those changes.
The "polishing" part would include vetting changes on the lists such
that their final commits would put them in such a form that when they
arrive back on your doorstep in the next release branch you can rely on
them to continue meet your own internal goals while at the same time
knowing what internal changes you'll have to port forward to that new
release.

In fact I wish I could afford to have someone working for me in that
capacity!  :-)

-- 
						Greg A. Woods

H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>       Secrets of the Weird <woods@weird.com>