[
https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15155664#comment-15155664
]
Richard Pawson commented on ISIS-1303:
--
I'm not going to express any further preference about the name, but I would
like to make a comment about the tag-lines: all the ones I've seen suggested
here read, to me, like generic marketing 'burble'. They convey nothing about
what Isis (currently) is. Might I propose this thought experiment:
Imagine that you were doing a presentation of Isis, where you couldn't mention
the name or the tag line, and where you were presenting alongside 10 other
frameworks. (They don't have to be direct 'competitors' as such, just other
significant software development frameworks that might be used by potential
customers in some overlapping way). At the end of the 10 presentations, the
audience is handed a slip of paper with the name of your product AND the
tag-line. Would they be able to identify which of the 10 frameworks that
applied to? In an ideal world, your name and/or tag line would convey the
nature of the product without having seen it, but that is not always possible.
If it's not possible then the next best thing is that once they have understood
the product, they will remember the name and/or tag line, because the latter
will clearly remind them of the product. I don't think any of the name /
tag-line combinations proposed pass either test.
As I said to Dan offline last week: I fully understand why you want to downplay
or move away from both the naked objects pattern, and DDD, but I think you
need to replace them with something equally concrete that defines your space.
That definition is as much about what you would NOT do in future as what you
would do. i.e. if one of the team said 'let's add feature x' - would you have
a clear way to decide whether X was enhancing the strategic direction of
diluting/confusing it (even though X might not be a bad idea in itself)?
I know there are many people who tell you to 'sell benefits, not features', but
the problem with that advice is precisely that you don't end up with anything
differentiating. You cannot, I believe, find a succinct set of business
benefits that are in any way unique: the same benefits will be claimed (with
some legitimacy even) by multiple other products. So you have, to some extent,
to sell features: but preferably ones that at least some people will see a
benefit from.
> Rename the project to better describe its values and purpose
>
>
> Key: ISIS-1303
> URL: https://issues.apache.org/jira/browse/ISIS-1303
> Project: Isis
> Issue Type: Wish
>Affects Versions: 1.11.1
>Reporter: Dan Haywood
>Assignee: Dan Haywood
> Fix For: 1.13.0
>
> Attachments: ApacheFarthing.jpg, ApacheFarthing.jpg,
> ApacheGestalt.jpg, Offset-curves-of-sinus-curve.svg
>
>
> In the past there have been a couple of discussions regarding renaming the
> project, the reason generally cited being the potential embarrassment of
> sharing a name with the jihadist militant group [1] currently prominent in
> the headlines. After due discussion on the mailing lists the prevailing view
> has been to retain our name: "we were here first".
> Until now I've concurred with that view also... after all, I originally came
> up with the name "Isis", originally based on the name of the Thames as it
> flows through Oxford [2] (many of the original authors of the framework live
> within Oxfordshire, UK).
> Separately to that discussion, we have the issue of marketing. Originally we
> marketed ourselves as a framework implementing the "naked objects" pattern
> [3]; the original name of the framework (prior to Apache) was of course the
> Naked Objects Framework. However, this pattern is either not well-known or
> is misunderstood (only a low proportion of developers that encounter the idea
> immediately "get it"). The crudity of the original user interfaces didn't
> help. And the name also, of course, can cause embarrassment in some cultures.
> Then, when domain-driven design [4] came along as a movement, that seemed an
> obvious platform upon which to position the framework: we obviously share the
> core belief that the domain is the most important bit of the system. However
> - and I still find this surprising - despite attempts otherwise we haven't
> really made too much of an impression in that community. The fact that the
> DDD community got massively sidetracked for a while by the CQRS pattern is
> perhaps part of it. I also often detect the view that DDD should imply not
> using a framework. The irony of course is that in rejecting framework such
> developers actually have to write more infrastructure code vs business domain
> code.
>
