Hi Benoit,
> I think I did answer in that thread already. Yes, you did. And thank you. >> To continue with the documentation (at least on the path I have taken so >> far) I need to better understand the vision. That will allow me to resolve >> and clarify the topics previously raised regarding the community’s approach >> to dealing with newbies. > This sentence sounds like the "support/warranty" discussion turned into > a blocker for you. It is not a blocker in the sense that regardless of the approach the community wants to take, I will continue one way or the other. However, in order to document, I need to understand. In that respect it is a blocker because I still do not fully understand how this community is working. I will write more below about what I mean. > I think instead of using blockers we should propose consensual solutions. All for it! > The approach that emerged from ongoing proposal would be "Through better > branding and documentation, end user would need less support" eventually > making most people happy, without requiring SLAs from community members. It is interesting that you interpreted it this way. Allow me to try to clarify my thinking. What I am trying to understand is (1) this community’s vision, and (2) a slightly deeper understanding of its approach to OSS. I don’t really have proper vocabulary, so I’ll try to explain in my own words. Perhaps somebody has already done research on this topic so can express these ideas better. If you know of any such document, please do let me know. In the meantime, here is my layman’s explanation. 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. All I want to know is: is this intended? Again, all I am trying to do is get clarity. I need the clarity if I am to describe James to outsiders. The first, fundamental, basic questions anyone will want to know is: What is James? Can I use this? What can I expect? If we do not provide a clear and honest answer, as far as I am concerned it is a misrepresentation, and is not ethical. I am not trying suggest which approach to take, I am simply trying to understand this community’s intentions with more clarity in order to properly represent it. Your help would be greatly appreciated. 😀 Cheers, =David --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
