[ https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15133166#comment-15133166 ]
Ged commented on ISIS-1303: --------------------------- !ApacheFarthing.jpg! > 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, ApacheGestalt.jpg > > > 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)