1 / 31

Aldo Eisma Consulting IT Specialist IBM Global Services aldo_eisma@nl.ibm

Eclipse and its Corona Inside a Large Scale Open Source Project - What Can we Learn From Open Source. Aldo Eisma Consulting IT Specialist IBM Global Services aldo_eisma@nl.ibm.com. What is Eclipse?. What is Eclipse?. Eclipse - a n open extensible IDE for anything and nothing in particular…

ethrasher
Download Presentation

Aldo Eisma Consulting IT Specialist IBM Global Services aldo_eisma@nl.ibm

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Eclipse and its CoronaInside a Large Scale Open SourceProject - What Can we Learn FromOpen Source Aldo Eisma Consulting IT Specialist IBM Global Services aldo_eisma@nl.ibm.com

  2. What is Eclipse?

  3. What is Eclipse? • Eclipse - an open extensible IDE for anything and nothing in particular… • out-of-box function and quality to attract developersa development environment for itself • endorsement (i.e, products) by some major tool vendors • open-source and supports open source development • industry standard tools platform

  4. Why Should You Care? • as a tool developer… • seamless tool integration • you no longer have to start from scratch • everybody can become a tool smith • Eclipse changes the way tools are built • as a Java developer… • you get a state-of-the-art Java IDE that you can tweak • but Eclipse is more than a Java IDE • as a user… • you get tools from different suppliers to make a tool environment the way you want it • freedom of choice

  5. The Way to Eclipse 1997 1998 1999 2000 2001 2002 2003 2004 VisualAge/Java VisualAge Micro Edition Eclipse March2.1 June3.0 Nov OpenSource announcement June Tech Preview Oct 1.0 June 2.0

  6. Goals • Provide open platform for application development tools • run on a wide range of operating systems • GUI and non-GUI • Language-neutral • permit unrestricted content types • HTML, Java, C/C++, JSP, EJB, XML, GIF, … • Facilitate seamless tool integration • add new tools to existing installed products • Attract community of tool developers • including independent software vendors (ISVs) • capitalize on popularity of Java for writing tools

  7. Why Open Source? • Full life cycle tool support requires contributions from partners • Options: • proprietary APIs • defined APIs plus Open Source • Partners want Open Source • less dependency on IBM • freedom of action for partners: • complement IBM products • implement their own products • Platform rule: the more ISVs - the more relevant is the platform

  8. eclipse.org • Eclipse Project • builds the Platform • adapt, evolve to meet needs of the community • Eclipse Tools Project • best of breed tools • Eclipse Technology Project • research, incubation, education • Web Tools Platform Project • build tooling for enterprise applications • just forming…

  9. eclipse.org Project • Eclipse Project • Platform • JDT: Java Development Tools • PDE: Plug-in Development Environment • Eclipse Tools • GEF: Graphical Editing Framework • EMF, VE, UML2: Modeling frameworks and tools • Hyades: Test, Trace and Monitoring tools • CDT, Cobol: programming tools • Technology • AJDT: Aspect-oriented Java development tools • Equinox: new more dynamic plug-in architecture • … Subprojects

  10. Eclipse Community • Open Source is a “community thing” • an active community is the major asset of an OS project • OS project gives and takes: • OS developer gives: • listen to feedback and react • demonstrate continuous progress • transparent development • OS developer takes: • answer user questions so that developers do not have to do it • report defects and feature requests • validate technology by writing plug-ins • submit patches and enhancements • Give and take isn’t always balanced • community isn’t shy and is demanding

  11. Community (Cont’d) • Increase the knowledge-level of the community • Requires intense communication • mailing list, newsgroups • news group now mostly self supporting • user maintained wiki • Community events • code camps – work with committers on your projects • “sprints” – committers meet to work on the OS project • EclipseCon – tech community conference

  12. Growth of a Community • Vendors are committing to Eclipse • Over 175 vendors including significant commitments from Rational, TogetherSoft, Serena, QNX, Merant • C/C++ IDE plug-in for Linux being led by QNX with RedHat, Rational, and MontaVista • Over 600 open source or freeware plug-in projects available • 450+ plug-ins at: www.eclipse-plugins.info • 150+ plug-ins at: www.eclipse-workbench.com • 50 Eclipse Innovation Grants Approved

  13. Open Source Questions • Impact of transition to Open Source? • Is Open Source chaotic? • What are the contributions? • Open Source and quality? • Planning an Open Source project? • Open Source and business?

  14. Transitioning to Open Source • Challenges • transparency • the community has to be able to observe what is going on to participate • educate community • this takes time and conflicts with the IBM “shipping software” goal • not all developers enjoy Open Source exposure • loss of the product support “firewall” • developers interact with customers directly • initial slow-down due to community engagement but increased transparency

  15. Adopting Open Source Tools • Open Source projects use a common set of tools • Software development: • version configuration management: CVS • build system: Ant • unit testing: JUnit • Integrate OS tools into Eclipse • Collaboration: • bug tracking: Bugzilla • newsgroups/mailing list • user collaboration: Wiki Web • FAQ

  16. Open Source Tools (Cont’d) • Open Source tools are Open Source • high quality • validated for distributed development • Transition to OS tools was (surprisingly) smooth

  17. Chaotic? • OS projects are highly structured – with explicit rules • Commit right rules: public “meritocracy” • only a small number of developers can modify the source base • key architecture defined by a small team of lead developers • peer pressure among committers – continuous reviewing • contributions from outside (patches) have to be reviewed by committers

  18. Contributions? Who is Reporting Bugs? • Eclipse 2.1 (6 months) • Consortium organizations: 7100 defects (= 1185 / m) month) • 341 reporters • Open source community: 3560 defects (= 595 / m) • 1212 reporters

  19. Contributions? Code • Eclipse 2.1 • 42 contributions • Expectation level for contributions is high • platform contributions have to have product quality • conforming to all the conventions is difficult • Larger contributions usually start as independent plug-ins • Products can introduce certification process for external plug-ins • Example: “Ready for WebSphere Studio Software plug-in ”

  20. Quality? Continuous Integration • Fully automated build process • Ant based • Build quality verified by JUnit tests • for a successful Eclipse build > 10’000 JUnit tests have to pass • Staged builds • nightly builds, weekly integration builds, monthly mile stone builds • “Eat your own dog food”

  21. Planning Product requirements suggest improvements commit to plan Eclipse Products Committers • Project Management Committee • posts draft plan • plans start in embryonic form and are revised throughout the release cycle • milestones/time boxes are fixed early on Plan Community enhancements feature requests bug votes

  22. Business? • Business opportunities • support • services and education • enhancements, e.g., easy install, better documentation • customization • Who are those guys? • BCG study of 678 Open Source Developers • 58% professional IT programmers • 30% Open Source is their job!

  23. Extending Eclipse for Fun and Profit… Commercial Development Environments IBMWebsphere Studio family SAPNetWeaver Developer Studio Eclipse SDK Eclipse SDK Commercial Add-Ons IBMWebsphere Studio family SAPNetWeaver Developer Studio Eclipse SDK Eclipse SDK Instantiations, Borland, Sitraka, SlickEdit…

  24. Business? Complementary Products Generate Revenue Enterprise Developer Rational XDE • Enterprise development organizations • Web services based enterprise modernization • Enterprise modeling and RAD Application Developer – Integration Edition • Advanced J2EE developers • Flow composition • Visual adapter creation • Business rule support Application Developer Device Developer • J2EE developers • Relational DB tools • Embedded WebSphere Application Server Site Developer • Professional Web, Java, and Web services developers • Java, XML, Rich media, and Web services WebSphere Studio WorkbenchIBM’s commercially supported version of the Eclipse Workbench

  25. Is it Paying Off? • Internal: tool strategies have aligned • all IBM tools build on top of Eclipse • Perception: Eclipse has a significant impact • “IBM is cool” • Products: a complete set of integrated tools is now available • enterprise application development • modeling (Rational) • C/C++ IDE  not built by IBM • 175 tool vendors are providing plug-ins for Eclipse • Community: a growing asset • testing, feedback, contributions • Costs: fixed cost  IBM needs such a platform anyways

  26. So? (easy…) • Join the Eclipse community and use Eclipse as… • … your tools platform • vendor support available if desired • “now any Joe Engineer can take the Eclipse product and be productive” • CIO Magazine Apr 15 • listen to your top developers • … a platform for building your own products • CPL license allows shipping commercial products • freedom about adding to WS studio or build your own tools • … a Rich Client Platform for your own applications • leverage the proven Eclipse architecture and UI for your own rich client applications • don’t be afraid of Open Source products

  27. So? (increasing aggressiveness…) • Consider “Community Source” Development • use Open Source practices and tools for internal development • you get more transparent processes • more agile development • OS can make a large organization act like a smaller one • more control to the developers • information flows are nakedly visible

  28. So? (most aggressive) • Consider Open Source development for your products • split your product into • commodity (platform) layer • differentiator (application) layers • keep the application layer small • become fully transparent • don’t hide your bugs and plans anymore • start to open source once you have something “interesting” • invest into building a community • manage your expectations • your software will not be written by contributors • community building takes time

  29. Eclipse Wants You • Use Eclipse (any way you like) • learn about OS (Bugzilla, newsgroups, mailing lists) • enter defect reports • Be your own tool smith - develop plug-ins • Show what you know – participate in the newsgroups • Fix it – provide patches • Grow it – provide plug-ins • Get nominated – become a committer

  30. Questions? ! ?

  31. Credits Special thanks for being able to reuse material from: • Erich Gamma -Java Development Tools Lead; Eclipse PMC Member.

More Related