Hi David,
On 27/08/2020 10:21, David Leangen wrote:
I have observed a few different types of approaches to OSS:
* Centered on a specification. The spec development has a formal process, and
the spec becomes the driving force. There is a “reference implementation” to
show that the spec works as intended. In this case, the clarity relates to the
spec. There is engagement from the community to make implement the spec in a
way that “works”. The clarity for the user in this case is that they know what
they can expect. (Perhaps OSGi is a great example of this approach.)
* Centered on a clear corporate vision. As a typical case, a company has
developed a product and has decided to open source it. What the product does is
clearly documented, as is the type of support that a user can receive
(community version or commercial version). Again, for the user, there is
clarity in terms of what they can expect to receive. (Maybe something like
Docker would fit this model? Or Elasticsearch?)
* Driven by a clear vision and objective. The scope of the product is very
clear, and there is a commitment (for whatever reason) to make it “work”. By
extension, this means that the meaning of “it works” is very precisely
understood. (Maybe Ant, Maven, and Gradle are good examples, because what is
meant by a “build tool” is pretty well understood.)
* Haphazard “me” approach. In this case, there is no central driver (spec,
company, clear vision). The product evolves more based on the individual
contributions of the members, which themselves are based almost entirely on
what the contributors need for themselves. Unless a contributor has their own
specific need and evolves the product to suite that need, then there is little
chance that the product will move. Because it is unpredictable what each
individual contributor will need, from the user’s perspective the development
is haphazard. There is little clarity in terms of what they can expect to get,
or if the product will continue to be maintained. If they want it to work, they
will have to become a contributor themselves, as there there are no guarantees.
There is no “right” or “wrong”, or even “better” by the way.
From my understanding so far, I think that James seems to fit the latter
approach. Yes, it relates to a few specifications, but James is not (as I
understood) willing to “commit” to being a reference implementation for SMTP,
IMAP, JMAP etc. Yes, there is some vision and some objectives, but nobody is
willing to commit to ensuring that the product works according to the
objectives, and as far as I can tell, the objectives are not entirely precisely
defined. So, based on what I know so far, it seems to fit best the last model.
I think you are correct, I would say that now it is more later approach
as well. Well at least since I started working on the project (might
have been different before).
I think the devs at Linagora are working more towards filling the needs
for the company, to be honest, which is mainly centered around the Guice
distributed server. But all the other Guice implementations are growing
as well with it along the way I would say, as they reuse pretty much the
same components (distributed server being the most complete and complex
one, others are like lighter versions of it).
I believe that we are of course mainly working on distributed server
version, but maintaining the rest as well... Trying to fix some IMAP or
POP bugs, etc.
But the biggest issue with the community would be I think because the
Spring version is still the default promoted one on our current
documentation. So people (as we say doc is quite confusing) start using
this one usually, and ask questions on it. The choice to keep this as
default seems to be because James JPA on Guice is still not as complete
as the Spring one. For example, the Guice version is only running on a
Derby embedded db, among other things missing (if I understood
correctly, but if I'm wrong I'm sure someone else will correct me)
We would like to get rid of the Spring JPA version (also in term of
maintenance, it's always a win to have less different technologies
used), but we can't really as long as the guice JPA is missing things
compared to Spring. But it is not a priority for us and we don't have
enough resources.
But I believe the documentation you started would help clarify things to
users and maybe push newcomers to contribute more on things we try to
maintain but don't have the resources to spend enough time on it.
I would like to add I think we are willing to commit being a reference
implementation to some things though, like lately we are spending energy
on JMAP. First we develop what we need but we will try to complete it
over time to be as close as possible from the specs. Would like to
mention as well some devs here are participating in the writing of the
JMAP specs:
* Benoit Tellier wrote the part regarding VacationResponse in the JMAP
mail specs
* Raphael Ouazana wrote an extension for JMAP MDN that is in the
finalization phase
* myself is trying to contribute an extension on JMAP quotas as well
I hope this helps you having a better vision of the project current
situation!
Cheers,
Rene.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
