Dan Haywood updated ISIS-1303:
    Fix Version/s:     (was: 2.6.0)

> 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
>            Priority: Major
>             Fix For: 2.0.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.
> 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

Reply via email to