[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ide-dev] Photon IDE, by Eclipse

+1 too!

I'm not totally against adding a name to the branding but nothing else.

-100 to choose "Photon". Tons of people will download Eclipse Photon next June. How do you explain them that the next download, also called "Photon" according to your proposal, is not the same old thing?

If we add a name, the only acceptable thing for me would be to cast a vote like we always do for the release name.


From:        Lars Vogel <lars.vogel@xxxxxxxxxxx>
To:        Discussions about the IDE <ide-dev@xxxxxxxxxxx>
Date:        27.10.2017 14:47
Subject:        Re: [ide-dev] Photon IDE, by Eclipse
Sent by:        ide-dev-bounces@xxxxxxxxxxx

+1 to Eds opinion

Am 27.10.2017 12:49 schrieb "Ed Merks" <ed.merks@xxxxxxxxx>:

I'm not sure which thread you wanted to the discussion is in.  Certainly there are technical problems, e.g., having an eclipse.exe, an eclipsec.exe but no photonc.exe in the folder, but those are just details to fix...

Let me say up front that I hate this idea.  But before explaining all the reasons why I hate it, I want take a step back because I still question what fundamental problem(s) are we trying to solve and what we could or should do to solve them.

I believe that Mike has mentioned that establishing a strong brand takes millions of dollars over several years.  The Eclipse brand is well-established and strong.  One problem---the one I believe you are focused on---appears to be that the brand is strongly (too strongly?) associated with the Java IDE, so your solution appears to be to replace Eclipse with Photon (or with ${whatever}) in as many places as possible to try to change that situation.  Unfortunately I don't believe this will in any way, shape, or form improve anything for the IDE itself; the IDE does not need to distinguish itself from any misconception of what exactly it is. 

It is the Eclipse Foundation as an organization that needs to ensure its brand is distinguished from the Java IDE, and it is each of Eclipse's non-JDT projects that need to ensure its Eclipse sub-brand is also strong.   But I don't feel that this should be done at the expense of the IDE itself; the IDE will not benefit from a weakening of its established strong brand.    I also feel that the recent creation of the Java EE project as an Eclipse-hosted project will go a long way toward changing perceptions about all that it means to be be "Eclipse", though even here one might argue that the perception will remain too strongly associated with Java.  That being said, Mike mentioned that a large C++ community perceives Eclipse as a C/C++ IDE, but of course that community is small compare to Java. 

I also question, what will really change if all the users should see Eclipse as a Java IDE suddenly realize that Eclipse is just a great place to host open source projects.  Will they come out in droves to host their projects at Eclipse?  And would we even want that if there were no associated financial investment in the Eclipse foundation?  I doubt that changing the perceptions of IDE users will have any important impact at all.   The end users are not the ones making decisions about whether to host important open source projects at Eclipse, so this as a focal point seems misdirected...

But let's just suppose for a moment that this were a brilliant idea.   Who is planning on rewriting all the long-established documentation to correct all the technical details related to folder and file names?  E.g., to point out that it's now photon.ini you need to edit, not eclipse.ini, unless you have an older version.  Who will migrate all the scripts that make assumptions about file/folder names that will need to be rewritten.  Will I be able to update from Oxygen to Photon; goodness knows we never seem to get that quite right?    Will there now be a .photon hidden folder in the home folder and will I have to migrate my .eclipse content to the .photon folder and will that be annoying if I ever use an older and a new Eclipse IDE at the same time?

So my point is that surely even if it were brilliant to rebrand the IDE, which I doubt, we most definitely should restrict ourselves to the visible branding (splash screen, translable strings, web pages) and avoid changing technical artifacts names because that will be highly disruptive to any existing documentation, scripts, and other infrastructure.


On 26.10.2017 18:52, Mickael Istria wrote:
Hi again,

(You really thought I gave up on this one? :P)
Branding has been an important and interesting topic when chatting at EclipseCon Europe. Surprisingly, I've (finally!) received some positive feedback on this idea of renaming the EPP packages to Photon, and it seems like some people who were strongly against it seem open to re-discuss the idea.
To make things more real, and let you figure out what this proposal changes -and doesn't change- for end-users, I've created a Gerrit patch that takes care of renaming EPP packages from "Eclipse" to "Eclipse Photon IDE": https://git.eclipse.org/r/#/c/110603/. You can try the result at https://hudson.eclipse.org/packaging/job/epp-tycho-build.gerrit/621/artifact/org.eclipse.epp.packages/archive/.
Please give it a try, take the time to evaluate the issues it can cause to users, and what can be the opportunities and simplification that it can bring to the IDE, the end-users and the community of Eclipse.org project just by adding a "first name" to the IDE; and then share your positive and/or negative feedback.
To be clear, the proposal would be to lock the Photon name, call it "Eclipse Photon IDE" forever or at least until the name becomes an issue, and let it have growing versions, whose scheme (4.8/4.9, 2018.6/2018.9...) should remain a different topic which moreover depends a lot on the final decision of the Planning Council regarding release cadence. So let's focus on the name and avoid brainstorming on the versions.

For the technical details, let's use the Gerrit patch and https://bugs.eclipse.org/bugs/show_bug.cgi?id=526456to keep the thread here focusing on the "functional" value/risk of this proposal.


ide-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

ide-dev mailing list

To change your delivery options, retrieve your password, or unsubscribe from this list, visit

ide-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit