[
https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Haywood updated ISIS-1303:
------------------------------
Description:
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.
Also, the fit is perhaps not all that good after all. In the DDD community I
don't see anyone talking about modules... one of the named patterns, and a
major focus of our framework, but missing from DDD talks. Instead they get
side-tracked talking only about aggregate roots or bounded contexts; all well
and good, but over-emphasised).
[Aside: Indeed, I raised the topic of modules with Eric Evans himself (in
person), and he agreed there was little emphasis. When I described our
framework's use of domain events to hook modules together (along with vetoing
behaviour we support) he admitted it was a new approach/pattern to him...]
Anyway, so DDD - which looked so promising - hasn't delivered. They might come
around to us one day, but it's probably time to define our own individual
space. Also, in the same way that everyone takes agile development for granted
as the "de facto", we ought to simply take DDD for granted too... "of course
you will be doing DDD, but are you doing it well?"
What we need to better market the framework is some other pattern or concept or
hook, and become known as the framework that best supports that idea. There
are several candidates:
- hexagonal architecture (also called ports and adapters, or the onion
architecture, and related to the clean architecture)
- don't repeat yourself principle
- aspect oriented programming (naked objects pattern is really the recognition
that UI presentation is a cross-cutting concern)
- the general concept of modularity
- DCI (data/context/interactions).
- "clean" "pure" "essential" pojo programming model
- agile, lean
- breaking down barriers between IT and business
Of these, I think that hexagonal architecture looks the best fit; it is well
regarded as a concept among the "cognoscenti", but there are surprisingly no
open source frameworks out there (at least in the Java space) that position
themselves as being the natural choice.
Therefore, I think a name - and appropriate short tag line - based around this
idea of hexagonal architecture should be considered.
Candidate names:
- hex (might hit trademark issues)
- hexagon
- hexagn (deliberately mis-spelled)
- hxg (omitting vowels, but could stand for hexagonal, extensible, generic)
- hx (too short?)
some made up words
- hexag (partial word)
- hexadom (sounds like a dinosaur?)
- mhodex (an anagram of hex and mod)
A common usage of hexagons is in bee hives, so:
- honeycomb (the outer hexagon is the BC, the inner hexagons are modules)
- comb (abbreviating it)
picking up on the DRY principle, we have deserts (might have trademark issues):
- sahara
- kalahari
- gobi
Or, we could go a different way altogether. Some random ideas:
- meld (mind-meld, joining together)
- sweetheart (because we love it)
- neuron (too bland?)
- razor (trademark issues?)
- razr (trademark issues?)
Any new name must pass the ASF naming procedures, documented in [5]. Of these,
the most significant is not conflicting with any existing US trademarks.
However, it's also work checking out what google says for any potential name.
For example, if googling for "Apache Hex" (which I quite like), the first entry
is for "Apache Hex Nipple".
In terms of tag lines, our current is "Domain Driven Applications, Quickly".
Instead of that, ideas we've been brainstorming off-line are:
- "own your code" (custom software is a profit centre, not a cost centre)
- "be responsible, own your code" (more imperative, assertive)
- "stay dry" or "keep dry" (alluding to the DRY principle)
- "simple, but no simpler"
- "don't be square" (a great joke on hexagons)
We also had other some joke straplines; these are *not* to be taken seriously
but I can't resist including them here:
- "not for hipsters" (we've noticed how we appeal to those developers who've
been around the block; we include ourselves in that descriptoin)
- "please shave" (hipster joke)
- "shave before use" (hipster joke)
- "come back when you're ready"
- "one day you'll see
- "monkey see, monkey do" (my favorite expression)
OK, that's it. Please comment on this ticket, and add your own ideas. If you
have name suggestions, also use [5] to check if they are likely to pass US
trademarks.
Thx
[1] https://en.wikipedia.org/wiki/Islamic_State_of_Iraq_and_the_Levant
[2] https://en.wikipedia.org/wiki/The_Isis
[3] https://en.wikipedia.org/wiki/Naked_objects
[4] https://en.wikipedia.org/wiki/Domain-driven_design
[5] http://www.apache.org/foundation/marks/naming
was:
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.
Also, the fit is perhaps not all that good after all. In the DDD community I
don't see anyone talking about modules... one of the named patterns, and a
major focus of our framework, but missing from DDD talks. Instead they get
side-tracked talking only about aggregate roots or bounded contexts; all well
and good, but over-emphasised).
[Aside: Indeed, I raised the topic of modules with Eric Evans himself (in
person), and he agreed there was little emphasis. When I described our
framework's use of domain events to hook modules together (along with vetoing
behaviour we support) he admitted it was a new approach/pattern to him...]
Anyway, so DDD - which looked so promising - hasn't delivered. They might come
around to us one day, but it's probably time to define our own individual
space. Also, in the same way that everyone takes agile development for granted
as the "de facto", we ought to simply take DDD for granted too... "of course
you will be doing DDD, but are you doing it well?"
What we need to better market the framework is some other pattern or concept or
hook, and become known as the framework that best supports that idea. There
are several candidates:
- hexagonal architecture (also called ports and adapters, or the onion
architecture, and related to the clean architecture)
- don't repeat yourself principle
- aspect oriented programming (naked objects pattern is really the recognition
that UI presentation is a cross-cutting concern)
- the general concept of modularity
- DCI (data/context/interactions).
- "clean" "pure" "essential" pojo programming model
- agile, lean
- breaking down barriers between IT and business
Of these, I think that hexagonal architecture looks the best fit; it is well
regarded as a concept among the "cognoscenti", but there are surprisingly no
open source frameworks out there (at least in the Java space) that position
themselves as being the natural choice.
Therefore, I think a name - and appropriate short tag line - based around this
idea of hexagonal architecture should be considered.
Candidate names:
- hex (might hit trademark issues)
- hexagon
- hexagn (deliberately mis-spelled)
- hxg (omitting vowels, but could stand for hexagonal, extensible, generic)
- hx (too short?)
some made up words
- hexag (partial word)
- hexadom (sounds like a dinosaur?)
- mhodex (an anagram of hex and mod)
A common usage of hexagons is in bee hives, so:
- honeycomb (the outer hexagon is the BC, the inner hexagons are modules)
- comb (abbreviating it)
Or, we could go a different way altogether. Some random ideas:
- meld (mind-meld, joining together)
- sweetheart (because we love it)
- neuron (too bland?)
- razor (trademark issues?)
- razr (trademark issues?)
Any new name must pass the ASF naming procedures, documented in [5]. Of these,
the most significant is not conflicting with any existing US trademarks.
However, it's also work checking out what google says for any potential name.
For example, if googling for "Apache Hex" (which I quite like), the first entry
is for "Apache Hex Nipple".
In terms of tag lines, our current is "Domain Driven Applications, Quickly".
Instead of that, ideas we've been brainstorming off-line are:
- "own your code" (custom software is a profit centre, not a cost centre)
- "be responsible, own your code" (more imperative, assertive)
- "stay dry" or "keep dry" (alluding to the DRY principle)
- "simple, but no simpler"
- "don't be square" (a great joke on hexagons)
We also had other some joke straplines; these are *not* to be taken seriously
but I can't resist including them here:
- "not for hipsters" (we've noticed how we appeal to those developers who've
been around the block; we include ourselves in that descriptoin)
- "please shave" (hipster joke)
- "shave before use" (hipster joke)
- "come back when you're ready"
- "one day you'll see
- "monkey see, monkey do" (my favorite expression)
OK, that's it. Please comment on this ticket, and add your own ideas. If you
have name suggestions, also use [5] to check if they are likely to pass US
trademarks.
Thx
[1] https://en.wikipedia.org/wiki/Islamic_State_of_Iraq_and_the_Levant
[2] https://en.wikipedia.org/wiki/The_Isis
[3] https://en.wikipedia.org/wiki/Naked_objects
[4] https://en.wikipedia.org/wiki/Domain-driven_design
[5] http://www.apache.org/foundation/marks/naming
> 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
>
>
> 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.
> Also, the fit is perhaps not all that good after all. In the DDD community I
> don't see anyone talking about modules... one of the named patterns, and a
> major focus of our framework, but missing from DDD talks. Instead they get
> side-tracked talking only about aggregate roots or bounded contexts; all well
> and good, but over-emphasised).
> [Aside: Indeed, I raised the topic of modules with Eric Evans himself (in
> person), and he agreed there was little emphasis. When I described our
> framework's use of domain events to hook modules together (along with vetoing
> behaviour we support) he admitted it was a new approach/pattern to him...]
> Anyway, so DDD - which looked so promising - hasn't delivered. They might
> come around to us one day, but it's probably time to define our own
> individual space. Also, in the same way that everyone takes agile
> development for granted as the "de facto", we ought to simply take DDD for
> granted too... "of course you will be doing DDD, but are you doing it well?"
> What we need to better market the framework is some other pattern or concept
> or hook, and become known as the framework that best supports that idea.
> There are several candidates:
> - hexagonal architecture (also called ports and adapters, or the onion
> architecture, and related to the clean architecture)
> - don't repeat yourself principle
> - aspect oriented programming (naked objects pattern is really the
> recognition that UI presentation is a cross-cutting concern)
> - the general concept of modularity
> - DCI (data/context/interactions).
> - "clean" "pure" "essential" pojo programming model
> - agile, lean
> - breaking down barriers between IT and business
> Of these, I think that hexagonal architecture looks the best fit; it is well
> regarded as a concept among the "cognoscenti", but there are surprisingly no
> open source frameworks out there (at least in the Java space) that position
> themselves as being the natural choice.
> Therefore, I think a name - and appropriate short tag line - based around
> this idea of hexagonal architecture should be considered.
> Candidate names:
> - hex (might hit trademark issues)
> - hexagon
> - hexagn (deliberately mis-spelled)
> - hxg (omitting vowels, but could stand for hexagonal, extensible, generic)
> - hx (too short?)
> some made up words
> - hexag (partial word)
> - hexadom (sounds like a dinosaur?)
> - mhodex (an anagram of hex and mod)
> A common usage of hexagons is in bee hives, so:
> - honeycomb (the outer hexagon is the BC, the inner hexagons are modules)
> - comb (abbreviating it)
> picking up on the DRY principle, we have deserts (might have trademark
> issues):
> - sahara
> - kalahari
> - gobi
> Or, we could go a different way altogether. Some random ideas:
> - meld (mind-meld, joining together)
> - sweetheart (because we love it)
> - neuron (too bland?)
> - razor (trademark issues?)
> - razr (trademark issues?)
> Any new name must pass the ASF naming procedures, documented in [5]. Of
> these, the most significant is not conflicting with any existing US
> trademarks. However, it's also work checking out what google says for any
> potential name. For example, if googling for "Apache Hex" (which I quite
> like), the first entry is for "Apache Hex Nipple".
> In terms of tag lines, our current is "Domain Driven Applications, Quickly".
> Instead of that, ideas we've been brainstorming off-line are:
> - "own your code" (custom software is a profit centre, not a cost centre)
> - "be responsible, own your code" (more imperative, assertive)
> - "stay dry" or "keep dry" (alluding to the DRY principle)
> - "simple, but no simpler"
> - "don't be square" (a great joke on hexagons)
> We also had other some joke straplines; these are *not* to be taken seriously
> but I can't resist including them here:
> - "not for hipsters" (we've noticed how we appeal to those developers who've
> been around the block; we include ourselves in that descriptoin)
> - "please shave" (hipster joke)
> - "shave before use" (hipster joke)
> - "come back when you're ready"
> - "one day you'll see
> - "monkey see, monkey do" (my favorite expression)
> OK, that's it. Please comment on this ticket, and add your own ideas. If
> you have name suggestions, also use [5] to check if they are likely to pass
> US trademarks.
> Thx
> [1] https://en.wikipedia.org/wiki/Islamic_State_of_Iraq_and_the_Levant
> [2] https://en.wikipedia.org/wiki/The_Isis
> [3] https://en.wikipedia.org/wiki/Naked_objects
> [4] https://en.wikipedia.org/wiki/Domain-driven_design
> [5] http://www.apache.org/foundation/marks/naming
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
