DSDP: Yesterday, Today and Tomorrow
Following up on today’s announcement of milestones in three of the DSDP projects—eRCP 1.0, MTJ 0.7, and TM 1.0—I thought I’d take a moment to reflect on DSDP…how it started, where it is today, and where it’s heading. First, let me start with a timeline of project events.
March 2005. Unofficially, the DSDP project got its start at a BoF session during EclispeCon last year. At the BoF, several device software tools vendors assembled to discuss the need for more embedded-specific functionality in Eclipse, specifically in the debugging area. There was acknowledgment of CDT and its extensive contribution to tooling in the embedded space, but there was also a desire to see more enhancements in the Eclipse Platform and more of a breadth of functionality around device software development. Shortly after EclipseCon, Wind River proposed the DSDP project and its two initial sub-projects, Target Management and Device Debugging. The TM project set out to build a framework and UI for managing remote embedded devices. The DD project initially focused on working with the Eclipse Platform Debug team to create a more customizable debugging framework in the Platform.
June 2005. At the June Eclipse Board Meeting, DSDP became an official project.
January 2006. While the TM and DD projects were working on use cases and code, two new projects came to DSDP: Mobile Tools for the Java Platform and Native Application Builder. MTJ, sponsored by Nokia, set out to create tooling and frameworks for JME application build and deployment. MTJ’s initial focus was on device and emulator frameworks, CLDC/MIDP application build and deployment, and mobile debugging, but their roadmap included visual editing, localization, optimization, and security. NAB, sponsored by Fujitsu, set out to port the open source WideStudio project to Eclipse. WideStudio is C++ GUI builder for mobile devices, with runtime support for various host and mobile operating systems. With these new projects, the DSDP PMC started to take shape and included the project leads as members—Martin Oberhuber, Mika Hoikkala, Shigeki Moride, and myself.
July 2006. Meanwhile, the Embedded Rich Client Platform (eRCP) was busily working in the Technology project and nearing its 1.0 release. In July, they elected to move into the DSDP project, given their project’s alignment with both the DSDP mission and the MTJ project. Mark Rogalski joined the PMC.
August 2006. Motorola proposed the Tools for Mobile Linux project, and Christian Kurzke began participating in the PMC calls as our next member-elect.
September 2006. eRCP 1.0 released.
November 2006. TM 1.0 and MTJ 0.7 released.
Going back to March of last year, it was difficult to see where DSDP might go, because building an Eclipse top-level project focused on the needs of the device software community is no small task. This space is easily as broad and diverse as the enterprise development space, and the line between device software and enterprise software continues to blur. Many of today’s embedded devices have more processing power, memory, and capabilities than PC’s from just a few years ago. Today’s devices frequently have rich user interfaces and are regularly connected to the outside world. Software is written in a variety of low and high level languages, and many applications are written to run on both desktops and mobile devices. Finally, one finds device software on many types of mobile and embedded devices in several vertical markets: aerospace, defense, industrial, automotive, networking, consumer devices, etc.
So where does one take DSDP in such a broad space? Rather than try to set an overall agenda for the project, what has worked well for DSDP has been organic growth. (This shouldn’t surprise those who’ve been in the Eclipse community for a while.) Organic growth allows the community to build what it needs. It allows companies using Eclipse commercially to determine where they’d like to collaborate in open source. As such, DSDP has served as a focal point and a home for a variety of device software technologies to live. DSDP has also served as a venue for technical collaboration between related projects and as a place for mentoring new projects through the Eclipse development process.
As an aside, the idea of a focused top-level project is admittedly one of the things I like about the project structure in Eclipse (in answer to Bjorn’s complaints about how Eclipse structures projects). When one surveys the list of Eclipse top-level projects, it is easy to identify technology horizontals and technology verticals in the community. Horizontal projects like the Platform, Tools (including CDT), and Technology are clearly designed to plug into many different technical areas. They are foundation technologies upon which specific vertical technologies can be built. I would also put TPTP, Modeling, and DTP as horizontal technologies, but that’s just my impression. Contrast these projects with what I believe are distinctly vertical technologies: WTP, BIRT, DSDP, and SOA. Yes, it’s possible to see technical usage across boundaries with these projects—XML tooling, general reporting outside of business apps, target management in the enterprise, SOA apps in embedded—but I believe the generalization holds true. DSDP has attracted a wide variety of focused technology in the embedded / mobile space and will continue to do so.
But back to the subject of this blog. So where does DSDP go from here? First, there’s still a lot of work to do in the existing projects. DD is working on a Debugger Services Framework for their 0.9 release in June 2007. eRCP is working on a QTe port and is recruiting in the community for a GTK Linux port. MTJ is planning UI development tooling and some collaboration with eRCP as part of their 1.0 release next year. NAB, having recently released 0.9.6, is currently recruiting for additional OS ports for their GUI runtime. TM is planning several enhancements for a 2.0 release in June 2007. And TmL is working towards a revised project scope and creation review near the end of the year.
Second, there are new possibilities for DSDP. A couple of companies are working on a new project proposal for tools and frameworks in the Automotive space. Stay tuned for future announcements on that. Additionally, there are several untapped areas that have the potential: EDA tool vendor frameworks, DSDP/FPGA development environments, hardware testing and bring-up, deployed device management, etc. We’re always recruiting.
In the end, where DSDP goes next is entirely up to the needs of the community. I’m pleased with the rapid and diverse growth so far, and I’m looking forward to the next year of technology development.