Bringing the Eclipse IDE forward

How do we do it?

We tax for committership!

Seriously?

Let’s charge 300 bucks!

Nooooo!

On one hand, the investment into the Eclipse IDE of existing, long-time contributors is declining. There might be plenty of reasons for that. But over time, this decline in investment has become visible to the users of Eclipse – developers that use it every day to get their job done. Personally, I’m missing innovation in things that really makes up a great IDE. Well, some might say that innovation happens in the web these days. Desktop IDEs are boring.

Really? Because on the other hand, there are many companies out there which are spending quite a bit of money on licenses for commercial desktop IDEs every year! Thus, I’m wondering if some of those companies would rather spend a similar amount or a bit less on Eclipse? Do you care about developers? Imagine there is a team of experienced people with a great vision on the Eclipse IDE available that is seeking for funding. Imagine that with your funding, you can not only contribute to a sustainable future of the Eclipse IDE but also participate in making decisions on how this future should look like. Now I’m telling you, that you don’t even need to hire developers for that!

This idea of leveraging an industry working group for bringing the Eclipse IDE forward has been circulating around for some time now. I finally sat down and put together a proposal for an Eclipse IDE industry working group.

Industry working groups at Eclipse are an easy way for companies to efficiently work together on a common goal. I’m looking for feedback and interested parties! Does that idea sound interesting? What aspects of the proposal do you like and which not at all? How much would you be willing to spend? What kind of participation do you like? What is missing and should be covered?

There are plenty of questions. Please don’t hesitate and reach out to me (@guw or gunnar at wagenknecht dot org) or subscribe to the ide-dev mailing list and join our discussions! There are also two interesting sessions at EclipseCon Europe that you should join: Making the Eclipse IDE fun again and an Eclipse IDE BoF.

5 thoughts on “Bringing the Eclipse IDE forward

  1. Absolutely, a small license fee per developer or site license for big companies would fly. Especially for companies that are building products on top of the Eclipse platform, like mine, and hence have a vested interest in keeping the forward progress going.

    Charging people for being committers is just dumb, and self-defeating. Except for the few who are paid to do it, these people are already donating vast amounts of money at standard engineering cost rates.

  2. Everytime I use Eclipse for anything else then RCP/plug-in development I cry 🙁 Eclipse as an IDE is far behind of all its competitors today. No innovation for many years. Have designers of IDE ever try NetBeans or IntelliJ?

    Is working group also a place to post ideas, review and fund implementation?

  3. The working group is a great idea! Thank you for creating the proposal.

    Other people also suggested this as reaction of my “Imagine the eclipse IDE would cost $300…” blog post. I think it is a great idea.

    I still believe that the “option” to pay for eclipse would make sense and would be complementary to the working group membership.

    The idea behind the $300 was hat shopping shrink-wrap software is a common procedure within companies with little administrative overhead. “Buying” is different form a “donation” and different form becoming “member of a working group”.

    If I am freelancer or a small company, I can easily tax-deduce a software purchase. But to tax-deduce a donation is much more complicated. Yes, I can put it on my expenses and hope it is OK, but I am not sure what a tax control would say about this. Being able to “pay” instead of “donate” can make a difference how much of the $100 of my revenue I invest into eclipse. It may only be $60 ending up at eclipse, because I have to pay $40 on taxes.

  4. Where is Eclipse idea box? And Eclipse crybox?
    I’m working on Eclipse in many aspects: OSGI, Eclipse plugins, WTP, Swing UI…

    I wanted to say what I like/dislike, and have the back of the community with a ‘I like’ system.
    Here’s what I have to say:
    * On the process:
    ** Eclipse commitment process is too long: does component approach really brings to such administrative.
    ** Github for everyone, deployment on repositories such as Maven central

    * On Architecture:
    ** Plugin.xml, Eclipse-LazyLoading and Require-Bundle really? What about blueprint.xml or a true CDI (pax-cdi) OSGI service implementation, there are standards for services too, keep the IDE on what it is doing for: an IDE.

    * On usage:
    ** m2e is not Maven: many of my projects can compile whit Maven, but not with m2e
    ** Plugin dev: when my platform is out of sync, why don’t we reboot the concerned plugin? Can’t we base all plugin/jdt dev to Maven, Gradle or any build tool and, that repeat myself, concentrate Eclipse dvlpmnt solely on the IDE thing.
    ** target platform and run configuration: I’ve many project, some that build with e3.8, some other with 4.3 (some must be compatible): to test one, I’m constrained to change TP, wait for 40 minutes, run my configuration (that is for sure tied with it), then test the other so back to step 1…
    ** wtp is just insane: no way to use it (too slow, too many issues, too hard to make a contribution: please recode…).

    If you want to move Eclipse forward, my point of view is to really improve user experience (reactivity, usage…), instead of thinking about a fee (Eclipse Long Term Plan is done to assist company to grab this product).

    Regards

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.