DTP 1.0 released

DTP 1.0 has been released and is now available on the download site.

I'd like to thank everyone in the community who helped DTP achieve this important goal. As Bjorn said in the release review, this is an "important step." Yes, it is important , because with 1.0 we move from incubating to mature status as a project. It is also a step, one move forward along the DTP path. We have a number of exciting ideas for DTP in 2007, not the least of which is participation in the Europa coordinated release. Also, there are a number of DTP presentations scheduled for EclipseCon, many of which will explore these directions.

We at DTP are looking forward to working with an expanding community in the coming months -- please keep telling us (newsgroup, Bugzilla, mailing lists, etc.) what we are doing well, where we need to improve, and what you'd like to see! And, making on final turn on a recent PlanetEclipse theme, since Eclipse is all of us, we really appreciate all the help the community can offer! :-)

Eclipse is you, and you are all different

Eclipse is who? It's you, says Bjorn and Doug points out that this dovetails nicely with the Time Magazine Person of the Year. This sort of image resonates with the ideal of open source, but in practice runs into some complications, as Ian has discussed. Yet I'm not sure that I'd say, following Ian, that some are more important than others in the Eclipse ecosystem. Sure, committers can make decisions that others, say users, can not. But users can vote with their feet, and being a committer on a project without users is no fun. Rather, there are different roles, responsibilities and powers for different members of the community. While committers, project leads, the EMO, and so on tend to get a lot of the visibility, the plain fact is that Eclipse would be nowhere today without the other members of the ecosystem. And the impact of change on ecosystems is famously difficult to predict: large, unpredicted consequences can appears from seemingly small events.

Anyhow, I do take the original point, and I can understand the frustration that Ian expresses. This sort of thing has been bothering me for a while. So here it is: I think we on the committer side of projects at Eclipse make it much harder than necessary for others to participate. I have some ideas to help with this, but I'll wait to see if others agree that there is a problem in the first place, before taking blogspace with proposals.

The Eclipse Mine

It's natural enough when thinking about IBM and open source to also think about Eclipse. When I think of "Eclipse" and "mining," my first association is usually BIRT. But now there's another link in the chain: Marc Fleury says that IBM's approach to open source is "strip mining." An interesting image, perhaps, but not one that makes a lot of sense to me. Assuming for a minute that Marc's argument holds, we still do not have something analogous to strip mining, because others, in addition to IBM, are able to obtain benefit from the open source in question. In strip mining, however, the resource is extracted only once. In other words, open source is nonrival.

But there's an interesting twist in Marc's argument. He says: "...dual strategy of proprietary products and low-end open source." What is this "low-end open source?" Does it apply to Eclipse and, if so, what are the implications?

Anyway, if there is an Eclipse mine, then who/what is the canary?