james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Leangen <apa...@leangen.net>
Subject [Discussion] Road to 4.0
Date Sat, 15 Aug 2020 01:20:51 GMT


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
 * Have an “Extensible Server” offering that shows where James really shines (i.e. its
     —> 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.


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message