> >For a myriad of reasons, we feel pretty strongly about staying a Community.
> >We feel that a Community more accurately captures the current state of
> >DTrace. This is in part because DTrace is pretty mature -- there is not
> >a corpus of evolving code that represents DTrace, and there is not a
> >DTrace project team per se, but rather many DTrace-related projects
> >(DTrace providers for different environments, subsystems, etc.) led by
> >leaders that consist of more than the original DTrace project team. We
> >feel it is much more natural for these projects to be Projects in the
> >DTrace community than they Projects living along side DTrace in the
> >Observability community.
> >
>
> This makes sense, but for some reason it feels like an
> exception in the making. On the other hand, it doesn't have
> to be, because certain other entities share the
> characteristics Bryan describes (mature, etc.).
I think the first-order test is actually pretty simple: for a given
entity Foo, do you think of it as "the Foo project" or "the Foo community"?
I think no one -- at this point -- would say that "the DTrace project"
comes to mind before "the DTrace community". Ditto, I would say, for
ZFS and a handful of other technologies. Another clear test: is there
active work to port or support the technology that the community
represents into another operating system? If so, that's a clear
indicator that participants are aligning along the lines of the technology
itself rather than the more qualitative system properties that the
technology perhaps exhibits. That is, if I'm porting ZFS to NetBSD,
I imagine I think of myself as being in the ZFS community -- but I don't
give a damn about the OpenSolaris storage community or the OpenSolaris
filesystem community. To phrase all of this in yet a third way: we need
to be careful about constructing artificial Communities here -- if a
Community is contrived, it will whither or splinter (and probably both).
- Bryan
--------------------------------------------------------------------------
Bryan Cantrill, Solaris Kernel Development. http://blogs.sun.com/bmc
