There's been an interesting thread going on in [email protected] [1] about
(a) the number of podlings in the incubator and (b) how long some of
them are taking to graduate. One of the main points being made is that
podlings that have been in the incubator for a certain period of time
(no-one is suggesting how long exactly, but 1 year is being used as a
strawman in the thread) should be more explicit in defining their
roadmap and action steps towards graduation.
To be honest, this is all very reasonable, but from Isis' point of view
it is perhaps slightly worrying, because although we've made some
progress with getting our code etc together (and the licenses, ICLAs,
release processes etc are in good shape), we haven't made a lot of
progress in attracting new committers. Indeed, arguably we've gone
backwards in that space: right now only Kevin, Rob and myself currently
actively commit.
With that in mind, Kevin, Rob and I had a skype conf call this weekend
to discuss some ideas to move Isis forward towards graduation.
Obviously, this is it's slightly against Apache policy ("if it didn't
happen on the mailing list then it didn't happen"), which is why I'm
posting here now to post some of our initial conclusions and to broaden
out the discussion to everyone else who might be interested. (Kevin and
Rob: correct me if I overstate on any of this).
*Marketing Message*
The main thing we discussed was the "marketing message" for Isis.
/Automatic UI/
The view we came to was that the automatic-UI generation part of Isis
(ie the naked objects pattern) is possibly more of a negative than a
positive, at least so far as attracting new users:
* That is, for those that have heard of naked objects (guestimate: 1/4
to 1/3 of developers), chances are that they have dismissed it as being
a way to build over-simplified CRUD-style applications. (Of course,
those of us who have actually used it to build apps know that ain't so,
but that's a different discussion).
* For those that have not heard of naked objects, the proposition that
"here's a framework that will automatically generate your UIs" doesn't
resonate. Why? I guess we can speculate; my view is that there are now
plenty of UI technologies that are quite productive/easy to use/fun;
probably a lot more so than when the original naked objects framework
was developed c: 2000. Another reason might be that developers put too
much emphasis over owning the UI rather than making sure the domain
model is good.
On the other hand, we did conclude that the automatic-UI is useful as a
design tool, and would-be users of Isis could probably understand it in
those terms. The fact that the automatic UI is also suitable for use by
end-users in some situations is subsidiary and something that adopters
of Isis might discover only later on.
/REST/
Another point that I was keen to see factored into the marketing message
for Isis is its REST support (the json-viewer). As you may have picked
up from other posts, I've been developing a standalone spec, Restful
Objects [2], which defines defines a set of RESTful resources, and
corresponding JSON representations, for accessing and manipulating a
domain object model.
I'm quite excited by this Restful stuff. On the one hand, as well as
Isis' implementation, there's also another .NET implementation underway
via Naked Objects MVC (Richard Pawson has been providing great feedback
on the spec). And Johan Andries has been making good progress on a new
RESTful UI, which I'm hoping might go open source. Also, the REST
approach has met a good reaction at our (joint) client in Ireland.
In terms of marketing, my view is that REST is an area where there is
currently a lot of interest, but developers looking into it will likely
realise that it's a complex area to do right (ful support for HATEOAS,
HTTP headers and status codes etc). As such, developers might be
interested in a framework that can help them out, at a somewhat higher
level of abstraction than JSR-311. The proposition is: press a button
and get a complete, fully restful API to any domain model.
/DDD/
A third message is for those that are interested in domain
modelling/domain driven design, for whom the automatic UI might (again)
be a useful design tool who might want to deploy their app on some other
framework, eg Spring or JEE.
So, overall this gives us three target use cases to address. The view
we took on was that the home page should reflect these use cases:
- domain modelling (and deploy on own platform)
- REST
- automatically generated webapp (primarily to support the other two use
cases, but optionally as a deployment in its own right)
With this in mind I've sketched up a new graphic that could be used for
the home page, see [3]. The current home page (the hexagonal
architecture) would probably be demoted to a supporting page describing
the architecture of Isis.
In addition, we thought that the side bar menu should be restructured
around these use cases.
*Alpha status viewers*
Another point we discussed was the incomplete nature of some of the
viewers. Having would-be users come across code that is broken is
clearly not a good experience, at least if there expectations are that
everything works.
Specifically:
* the scimpi viewer is code complete but its supporting documentation is
incomplete
* the wicket viewer is not complete (though it's documentation is pretty
good!)
* the xhtml viewer (which is a precursor to the json viewer, but using
XHTML representations) is superceded by the json viewer and so should be
removed
* the dnd viewer (which has worked in the past), is currently broken
(doesn't repaint properly)
We discussed the dnd viewer quite a lot. Although it is, in some sense,
the "purest" expression of the naked objects pattern (bringing in some
of the original ideas of expressive systems), the truth, probably, is
that for our target audience this isn't important to emphasise. Crudely
put: would-be users are not going to understand what the somewhat
unconventionaly UI that the dnd browser provides is trying to achieve.
The fact that it is currently broken hardly helps atters.
So one of the points we thought made sense was to change things so that
the HTML viewer is the default, rather than DnD.
In terms of the documentation and the site, we decided that the web site
pages for the scimpi, wicket and dnd viewers should indicate that they
are "alpha" status, and on the left hand menu we should group them under
"other viewers". As such, we probably should remove them from the Maven
archetype until such time that they are back to production quality.
*Remoting*
We also discussed the remoting component. The remoting component
enables the dnd viewer to be deployed in a client/server configuration,
and is what is used in the big Irish project (on the old .NET version of
the naked objects framework). However, my personal view is that
remoting is, well, broken. In fact, I think it should be removed: (a)
the caching semantics for client-side domain objects is not
well-defined; (b) anyone wanting a client/server solution would probably
look towards an approach that uses REST, (c) the remoting support
introduces a lot of complexity in the default runtime (notably, the
separation of the "Persistor" API and the "ObjectStore" API).
However, we didn't necessarily all agree on this viewpoint. So for now,
we decided to de-emphasise remoting, because it doesn't fit into the 3
main use cases that we highlighted above. That means that it won't
appear in the left-hand menu, for example. My suggestion is that we
link to it from the dnd viewer page (because that's the only viewer that
would make use of it).
*Release*
Kevin has been working through the release procedures that I documented,
and made some changes and clarifications. I think that by-and-large
they are holding up ok.
I offered to push out a new release, because we are well overdue for
another release. I propose to do this once we've restructured the site
a little (assuming that we go with the ideas I'm summarizing in this
thread).
*Blogging*
In terms of building up a community, I suggested that we need to be more
organized about blogging. A little organization here between the
contributors could substantially increase Isis' reach:
* one idea is that Rob, Kevin and I take it in turns to publish a blog
post such that there is at least one new blog post every week
* blog posts should also be cross posted to blogs.apache.org (which will
hit some other aggregators)
* publicise blog posts in twitter using #apache #isis hashtags
* publicise blog posts via dzone.com (and any other places you might choose)
* publicise blog posts via isis-dev mailing list, and ask others to
up-vote in dzone).
In terms of content, one question raised was what, exactly, to blog
about. My thoughts are:
* choose a theme for a series of blogs:
- eg tips-n-tricks taken from applications working on (Robert's
PlanChaser, or Kevin's various apps)
- copy-n-paste some of the sidebars from the Richard/Robert's
original Naked Objects book (for Robert)
- work through some of the applib conventions, eg how to do choices
for a property.
In terms of "how to":
* keep it short, something that won't take more than 2 or 3 minutes to read
* if you have more than that, then leave it to the next part
* sit down and write 2 or 3 posts at a time (or split up a draft blog
post that's got too long) and then only publish them according to a schedule
*Articles***
Rob, Kevin and I didn't discuss writing articles in our call; clearly
some articles would be good (eg infoq.com or theserverside.com), but it
takes that much more time to do. I'd rather focus on just getting a
steady stream of blog posts going first.
*Thoughts?*
OK, I think that more or less summarises the points that I wanted to
raise. If anyone has any views on this/clarifications/corrections, then
post them here.
Meantime, I intend to put some additional material on blogging up onto
our wiki.
Thanks,
Dan
[1] http://osdir.com/ml/general.incubator.apache.org/2011-11/msg00182.html
[2] http://restfulobjects.org/
[3] https://cwiki.apache.org/confluence/display/ISIS/RevampedSiteIdeas
