Hello!
I wanted to tie together a few ongoing threads and make a proposal for the road
to a 4.0 release. My assumption is that there currently is not roadmap to 4.0.
If I am mistaken, please do let me know and I will adapt.
I think by now it is clear that, although a great project with TONS of great
work put into it by some very dedicated people over several years, over time
James has drifted away from having a user focus. (I’ll say “user” here because
it is more natural, but I really mean “Operator” as we defined recently). What
this means is:
* It is difficult for new users to understand how James works
* It is difficult to get James working
* It is not easy to understand how to configure James
(or even to understand what all the different configurations are)
I don’t think this was ever intended, but it just kinda happened over time. I
think it is understandable, as James is a very complex project. Maintaining a
working system of this scale by a small team of volunteers is not at all an
easy task. I am not at all trying to suggest that this is a “bad” thing in any
way, so please don’t get me wrong.
I get the feeling that there has been a lot of support in the community to
shift towards making James more user-friendly, and that it shouldn’t require a
huge effort because there are so many good things already baked into the
project. The current direction seems to be:
* Redo the documentation (already underway, though taking more time than
expected)
* Have a “Basic Server” entry-level offering that is ideally very easy to
install and operate
* Have an “Extensible Server” offering that shows where James really shines
(i.e. its extensibility)
—> Include some kind of “build project” that helps operators build the
James they want
* Have a “Distributed Server” offering for more heavy-duty environments
(There are a few other servers as well, but maybe they are more
development-oriented??)
My intention in this thread is to set a very clear objective for a 4.0 release.
I would like to propose that for the 4.0 release, we start to make the
objectives more user-oriented. I would like to propose that as part of setting
our objectives for 4.0, we adhere to the following:
* Set clear metrics to determine if the objectives are met or not
* Make the metrics user-oriented
As part of this release, I would like to resolve how the community sees its
role. In the discussion we had last time, it seemed to be very inward focused
(what do I get out of this; how do I ensure that I don’t feel stuck doing
something I don’t want to do) instead of being outward focused (what does the
user get, how should the user expect to benefit). I would argue that any
user-oriented documentation should be for the user’s benefit, and ought to be
user-focused. I think we need a clear resolution, and I think it is related to
the 4.0 objective.
By the way, to coincide with the release, if the objectives are clear, perhaps
there is a commercial organization (or individual) who would be willing to
provide paid-for professional support starting from 4.0? I think it would help
complete the offering, and hopefully provide a commercial opportunity as well
in a way that is beneficial to all, including the James community. We just need
to ensure that the “contract” is very clear, and that we avoid any potential
conflicts of interest. I think we should include this item in the scope of the
discussion as well. (Just a thought, but maybe the “Distributed James” could be
a commercial offering, rather than a community offering??)
To resolve this thread, I will be satisfied once we have a clear statement of
objectives regarding the 4.0 release.
Cheers,
=David
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
