You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by David Leangen <ap...@leangen.net> on 2020/06/15 11:10:13 UTC
Support and service levels
I am moving a comment from Benoit to this new thread:
> Also I would like to differentiate the terms "offering" (what do we
> deliver as part of the James project, who do it targets, and how easy
> should it be to use) from the term "support" which in my view implies
> "how fast you solve my problems", and might be a more sensible topic.
My thought is: if it is not “supported”, then it should not be “offered” in the first place.
By “support”, I mean:
* It is documented so Operators understand what they are operating
* It works as documented
* If it doesn’t work, there is some commitment by the community to fix it
If there is no intention of doing all of the above, then it is not “supported” and should therefore not be “offered”. No confusion. Nobody will be let down.
I think what you are describing refers to the "service level", which also ought to be described in order to set some kind of expectation. (People only get disappointed when their expectations are not met.) Because this is an open source project, it should be very relaxed (i.e. low expectations set, but at least some expectation). Perhaps we could also maintain a list of those who can provide commercial support if a higher service level is desired. However, people should not feel like they are being tricked or forced into commercial support.
Some OSS projects have a “f**k you, this is open source so do it yourself or pay me!” attitude. I don’t think that is very nice and I don’t particularly like those projects. I believe that there should be some reasonable (on both sides) expectations. I believe that a community looks out for its members, and if we want to expand the community, we have to, at least to some extent, look out for those we are asking to join. But that’s just me, and it’s not for me to decide. :-)
For instance:
* The community commits to fixing a bug within X time
X could either be vague (like “a reasonable amount of time given that we are all volunteers"), or something more concrete but plenty generous like “we strive to fix all issues within 4 weeks” (still just a small opening with the “we strive to” part).
Then people can compare the James OSS service level to a commercial service level (which we should require if it is to put added to the list, like) "Issues fixed within 48 hours”.
Or something like that.
It would then be easy for people to make a decision:
* Wait up to 4 weeks, but get free help, or
* Pay ¥50,000 and get my problem fixed in 48 hours
Cheers,
=David
Re: Support and service levels
Posted by Michael Gooden <mg...@michaelgooden.com>.
please take me off this list.
> On Jun 19, 2020, at 8:49 AM, David Leangen <ap...@leangen.net> wrote:
>
>
> Hi,
>
> Please be in a good mood when you read this. Words can be taken the wrong way. I am writing this with a big smile on my face, all in good humour. 😆
>
>>>
>>>> [... snipped everything ...]
>>
>> I agree with everything you wrote.
>
> I think you are taking certain things a little too much out of context. 😀
>
> My point is more about being honest than being generous. I am not trying to recruit anybody to provide free work. Not at all.
>
> When I say there should be some kind of SLA, I am not at all suggesting that everybody commit a fixed amount of time or make any guarantees to solve other people’s problems for free. Actually, I thought I had proposed quite the opposite (that we list people and companies who are willing to do it for a fee.) So it sounds like we are very much in agreement. Nobody should be expected to work for free if the don’t want to.
>
> My point is about being up front and honest, so people know what to expect and can weigh their options. In order to build trust, we need to set reasonable expectations (whatever they happen to be), and stick to them (or update them if we can’t). Personally, I prefer when somebody under-sells and over-delivers the somebody who does the opposite. I can trust that person and if I agree to their terms, I know I will be satisfied. From what I have read and based on the people I know, I think that most people appear to be the same.
>
> If people don’t understand their options, then the unknowns make using James too risky. In my mind, that is not a successful community project.
>
> For instance, if the website states that that a particular feature of James works, then it really should work. Otherwise nobody will trust the James community.
>
> There are already basic standards in place and are I think being respected, else the community would very quickly fall apart:
>
> * New features should have tests
> * Tests should always pass
> * Code should always compile
> * Etc.
>
> I could suggest that we add a bit to that list for the sole purpose of setting expectations and, hopefully, eventually expanding the community.
>
> And anyway, is it really such a horrible thing, for instance, to ask somebody who commits a feature to ensure that it gets documented properly? Or that the code is readable? Etc.
>
> If it is too much to ask, then we should instead write disclaimers on the website to warn people instead of trying to boast about how awesome James is.
>
>> Don't like it? Don't use it.
>
> I don’t disagree with that statement. Let me just make sure that I completely understand with this test: if somebody dumps trash all over a public place, then states “Don’t like it? Don’t use it.” I don’t think I would be very happy. True, I won’t use a park full of trash because I don’t like it, but I think that’s an abuse of this principle. I trust that is not what you mean, right? I am assuming that what you mean is more along the lines of “The suit doesn’t fit? Ok, don’t wear it!"
>
> By all means, please go ahead and make nice suits, even if it doesn’t fit everybody. But please do not dump trash in the park.
>
>
>> I am a volunteer in the Apache Software Foundation as all of us are.
>
> Sorry… I took the bait and feel compelled to respond to your little lecture. 😀
>
> Are you really?
>
> The definition I found was:
>
>> a person who does something, especially helping other people, willingly and without being forced or paid to do it
>
>
> Except for the “without getting paid” part, I should point out that you are stating exactly the opposite. 😂
>
> It’s all ok. You are just being honest about your intentions: you are in it for your own gain, not to help others. If others can benefit from your work, great, but that is not your primary objective. Fine.
>
> Of course there is nothing wrong with that. My efforts to help with documentation are not entirely altruistic, either. But you can’t have your cake and eat it, too. You can’t call yourself a “volunteer" if really you’re just in it for yourself and others just happen to maybe benefit. And if you really are in it to help others, then you would be thinking of them first.
>
> So yeah, let’s just be honest and set the right expectations so everybody is happy.
>
> Having an SLA will help do that. We should only commit to what we are willing to commit to, but there **must** be a clear definition of the service level that is being offered (even if essentially says "f*** you stupid user”, at least that’s clear and honest.)
>
>
> Ok, all that was very abstract and waaaaaay off-topic, but I wasn’t expecting a reaction like the one you had so I had to have a little fun with it. 😂
>
> If you reread my initial message in this new light, I hope you’ll find that it was not intended to sound unreasonable. It is about honesty and expectation setting, not free work.
>
>
> So if we agree that an SLA is necessary (and I think we are agreeing), then most of what you wrote (i.e. what you are not willing to commit to) relates to what the contents of the SLA ought to be. And what you write makes good sense in that context.
>
>
> Cheers,
> =David
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Support and service levels
Posted by Tellier Benoit <bt...@apache.org>.
I opened the following ADR to better define "quality levels"
https://github.com/apache/james-project/pull/219
Please have a look ;-)
Le 21/06/2020 à 13:03, Tellier Benoit a écrit :
>
>
> Le 19/06/2020 à 20:49, David Leangen a écrit :
>>
>> Hi,
>>
>> Please be in a good mood when you read this. Words can be taken the wrong way. I am writing this with a big smile on my face, all in good humour. 😆
>>
>>>>
>>>>> [... snipped everything ...]
>>>
>>> I agree with everything you wrote.
>>
>> I think you are taking certain things a little too much out of context. 😀
>>
>> My point is more about being honest than being generous. I am not trying to recruit anybody to provide free work. Not at all.
>>
>> When I say there should be some kind of SLA, I am not at all suggesting that everybody commit a fixed amount of time or make any guarantees to solve other people’s problems for free. Actually, I thought I had proposed quite the opposite (that we list people and companies who are willing to do it for a fee.) So it sounds like we are very much in agreement. Nobody should be expected to work for free if the don’t want to.
>>
>> My point is about being up front and honest, so people know what to expect and can weigh their options. In order to build trust, we need to set reasonable expectations (whatever they happen to be), and stick to them (or update them if we can’t). Personally, I prefer when somebody under-sells and over-delivers the somebody who does the opposite. I can trust that person and if I agree to their terms, I know I will be satisfied. From what I have read and based on the people I know, I think that most people appear to be the same.
>>
>> If people don’t understand their options, then the unknowns make using James too risky. In my mind, that is not a successful community project.
>>
>> For instance, if the website states that that a particular feature of James works, then it really should work. Otherwise nobody will trust the James community.
>>
>> There are already basic standards in place and are I think being respected, else the community would very quickly fall apart:
>>
>> * New features should have tests
>> * Tests should always pass
>> * Code should always compile
>> * Etc.
>>
>> I could suggest that we add a bit to that list for the sole purpose of setting expectations and, hopefully, eventually expanding the community.
>>
>> And anyway, is it really such a horrible thing, for instance, to ask somebody who commits a feature to ensure that it gets documented properly? Or that the code is readable? Etc.
>>
>> If it is too much to ask, then we should instead write disclaimers on the website to warn people instead of trying to boast about how awesome James is.
>
> This is a fair point, but 'quality' differs from 'support' concerns.
>
> We of course need to refresh / clarify our expectations regarding code
> quality as a all.
>
> As part of the 3.0.0 release in 2016 we did that work and decided that
> to be supported:
>
> - 'interfaces' in components needs a contract test suite
> - 'implementation' of these interfaces needs to pass this test suite
> - Decent integration tests coverage is needed
> - Performance tests needs to be conducted out.
> - Quality Assurance with external clients
>
> Everything not matching these standards would be categorized as
> experimental.
>
> Enforcing this for 3.0.0 (JAMES-1765) id lead us to this kind of
> documents [1], in order to leverage faith in the existing components.
>
> [1]
> https://github.com/chibenwa/james-project/blob/v3.0_roadmap/v3.0_roadmap.adoc
>
> I would add to the list:
> - known existing production deployments/usages
> - usable documentation
>
> I believe the 'quality' of what we provide is independent from the
> support we offer (of course better quality might bring less needs of
> support).
>
> I will write an Architecture Decision Record on this topic.
>
>>
>> Cheers,
>> =David
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Support and service levels
Posted by Tellier Benoit <bt...@apache.org>.
Le 19/06/2020 à 20:49, David Leangen a écrit :
>
> Hi,
>
> Please be in a good mood when you read this. Words can be taken the wrong way. I am writing this with a big smile on my face, all in good humour. 😆
>
>>>
>>>> [... snipped everything ...]
>>
>> I agree with everything you wrote.
>
> I think you are taking certain things a little too much out of context. 😀
>
> My point is more about being honest than being generous. I am not trying to recruit anybody to provide free work. Not at all.
>
> When I say there should be some kind of SLA, I am not at all suggesting that everybody commit a fixed amount of time or make any guarantees to solve other people’s problems for free. Actually, I thought I had proposed quite the opposite (that we list people and companies who are willing to do it for a fee.) So it sounds like we are very much in agreement. Nobody should be expected to work for free if the don’t want to.
>
> My point is about being up front and honest, so people know what to expect and can weigh their options. In order to build trust, we need to set reasonable expectations (whatever they happen to be), and stick to them (or update them if we can’t). Personally, I prefer when somebody under-sells and over-delivers the somebody who does the opposite. I can trust that person and if I agree to their terms, I know I will be satisfied. From what I have read and based on the people I know, I think that most people appear to be the same.
>
> If people don’t understand their options, then the unknowns make using James too risky. In my mind, that is not a successful community project.
>
> For instance, if the website states that that a particular feature of James works, then it really should work. Otherwise nobody will trust the James community.
>
> There are already basic standards in place and are I think being respected, else the community would very quickly fall apart:
>
> * New features should have tests
> * Tests should always pass
> * Code should always compile
> * Etc.
>
> I could suggest that we add a bit to that list for the sole purpose of setting expectations and, hopefully, eventually expanding the community.
>
> And anyway, is it really such a horrible thing, for instance, to ask somebody who commits a feature to ensure that it gets documented properly? Or that the code is readable? Etc.
>
> If it is too much to ask, then we should instead write disclaimers on the website to warn people instead of trying to boast about how awesome James is.
This is a fair point, but 'quality' differs from 'support' concerns.
We of course need to refresh / clarify our expectations regarding code
quality as a all.
As part of the 3.0.0 release in 2016 we did that work and decided that
to be supported:
- 'interfaces' in components needs a contract test suite
- 'implementation' of these interfaces needs to pass this test suite
- Decent integration tests coverage is needed
- Performance tests needs to be conducted out.
- Quality Assurance with external clients
Everything not matching these standards would be categorized as
experimental.
Enforcing this for 3.0.0 (JAMES-1765) id lead us to this kind of
documents [1], in order to leverage faith in the existing components.
[1]
https://github.com/chibenwa/james-project/blob/v3.0_roadmap/v3.0_roadmap.adoc
I would add to the list:
- known existing production deployments/usages
- usable documentation
I believe the 'quality' of what we provide is independent from the
support we offer (of course better quality might bring less needs of
support).
I will write an Architecture Decision Record on this topic.
>
> Cheers,
> =David
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Support and service levels
Posted by David Leangen <ap...@leangen.net>.
>> Don't be afraid, debate is sane
>
> Thanks for the reassurance. It’s sometimes difficult in a “new” community to know how people will take things.
Right now, since I am new to the community, I don’t feel that it would be appropriate for me to debate any issue too strongly, let alone an issue like this one. Rather, my main focus is to capture the **actual** state of the code and the **actual** way the community thinks and functions.
I did want to rebut some comments that were made because I felt that what I tried to express was completely misunderstood. That said, some interesting and relevant points came out of the discussion. I have attempted to document my understanding of the opinions expressed in this thread:
* https://github.com/apache/james-project/pull/206/files#diff-ede06c35ad2bae68b87128141eea7eb7
However, I am not convinced that I did a good job of capturing the ideas, so comments would be very welcome.
Cheers,
=David
Re: Support and service levels
Posted by David Leangen <ap...@leangen.net>.
> What we say is: "you are all welcome, come join us, we'll try to help
> as much as we can". It's very different from both "we commit to help
> you" and to "you won't get any support".
Ok, then let me focus on precisely this point, in the hope of nailing down some kind of agreement.
> you are all welcome, come join us, we'll try to help as much as we can
I accept your statement and will not argue against it, but allow me in return to ask for some clarifications.
What does that mean precisely?
What kind of help are you referring to exactly?
What can I expect in terms of turnaround for such help? Does that mean that I may get somebody to answer one question every day? Or only one per week? If I am in trouble, does that mean that somebody will usually be able to help me within a few days? Or should I expect that in many cases I may never get any help?
How many questions is it even ok for me to answer? Can I ask 10 questions a day? Or is that not acceptable? Why not?
Cheers,
=David
Re: Support and service levels
Posted by Matthieu Baechler <ma...@apache.org>.
On Sat, 2020-06-20 at 00:03 +0900, David Leangen wrote:
> > Don't be afraid, debate is sane
>
> Thanks for the reassurance. It’s sometimes difficult in a “new”
> community to know how people will take things.
>
>
> > Commitment is just text and I don't have much trust in text.
>
> Well, if most people here think this way, then there really is no way
> forward with this idea.
>
> I find this a bit cynical, but maybe I am too naive. Or perhaps I
> have been living in Japan for way too long.
>
>
> > I still think it's not a good idea unless you want to handle the
> > SLA
> > yourself or with some other people from the community because I
> > don't
> > expect to have a commitment with virtually anybody at anytime.
>
> But I think again you miss the point.
>
> Saying something like “you will never, ever, ever get any support
> whatsoever” is also an SLA. So to some extent, what you just wrote
> above ironically **IS** the SLA you are willing to commit to (at no
> time to anybody).
I'm not saying that nobody will ever get any support. I said that I
don't when to commit to anything.
The reality is that people do receive support, they just can't complain
that we don't respect a specific commitment, it's a best effort
initiative and that's the spirit of most free software licenses BTW.
> It’s all about setting expectations so that people can make
> reasonable plans, not about committing to volunteer time. It’s about
> communicating what the community is willing (or not) to offer, so
> people know how to approach us.
>
> But then if this is the thinking:
>
> > Commitment is just text and I don't have much trust in text.
>
> Then it’s all pretty much moot. 😀
>
What we say is: "you are all welcome, come join us, we'll try to help
as much as we can". It's very different from both "we commit to help
you" and to "you won't get any support".
Cheers,
-- Matthieu Baechler
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Support and service levels
Posted by David Leangen <ap...@leangen.net>.
> Don't be afraid, debate is sane
Thanks for the reassurance. It’s sometimes difficult in a “new” community to know how people will take things.
> Commitment is just text and I don't have much trust in text.
Well, if most people here think this way, then there really is no way forward with this idea.
I find this a bit cynical, but maybe I am too naive. Or perhaps I have been living in Japan for way too long.
> I still think it's not a good idea unless you want to handle the SLA
> yourself or with some other people from the community because I don't
> expect to have a commitment with virtually anybody at anytime.
But I think again you miss the point.
Saying something like “you will never, ever, ever get any support whatsoever” is also an SLA. So to some extent, what you just wrote above ironically **IS** the SLA you are willing to commit to (at no time to anybody).
It’s all about setting expectations so that people can make reasonable plans, not about committing to volunteer time. It’s about communicating what the community is willing (or not) to offer, so people know how to approach us.
But then if this is the thinking:
> Commitment is just text and I don't have much trust in text.
Then it’s all pretty much moot. 😀
Cheers,
=David
Re: Support and service levels
Posted by Matthieu Baechler <ma...@apache.org>.
On Fri, 2020-06-19 at 22:49 +0900, David Leangen wrote:
> Hi,
>
> Please be in a good mood when you read this. Words can be taken the
> wrong way. I am writing this with a big smile on my face, all in good
> humour. 😆
Don't be afraid, debate is sane
> > > > [... snipped everything ...]
> >
> > I agree with everything you wrote.
>
> I think you are taking certain things a little too much out of
> context. 😀
>
> My point is more about being honest than being generous. I am not
> trying to recruit anybody to provide free work. Not at all.
>
> When I say there should be some kind of SLA, I am not at all
> suggesting that everybody commit a fixed amount of time or make any
> guarantees to solve other people’s problems for free. Actually, I
> thought I had proposed quite the opposite (that we list people and
> companies who are willing to do it for a fee.) So it sounds like we
> are very much in agreement. Nobody should be expected to work for
> free if the don’t want to.
>
> My point is about being up front and honest, so people know what to
> expect and can weigh their options. In order to build trust, we need
> to set reasonable expectations (whatever they happen to be), and
> stick to them (or update them if we can’t). Personally, I prefer when
> somebody under-sells and over-delivers the somebody who does the
> opposite. I can trust that person and if I agree to their terms, I
> know I will be satisfied. From what I have read and based on the
> people I know, I think that most people appear to be the same.
>
> If people don’t understand their options, then the unknowns make
> using James too risky. In my mind, that is not a successful community
> project.
When it comes to evaluate a piece of software, I don't really look at
commitment: people rarely deliver what they commit to. What I look for
is "how it behaves usually": are people getting answers? are problem
usually get solved? how many people are active on the project? What is
their direction? who uses it?
Commitment is just text and I don't have much trust in text.
> For instance, if the website states that that a particular feature of
> James works, then it really should work. Otherwise nobody will trust
> the James community.
>
> There are already basic standards in place and are I think being
> respected, else the community would very quickly fall apart:
>
> * New features should have tests
> * Tests should always pass
> * Code should always compile
> * Etc.
>
> I could suggest that we add a bit to that list for the sole purpose
> of setting expectations and, hopefully, eventually expanding the
> community.
>
> And anyway, is it really such a horrible thing, for instance, to ask
> somebody who commits a feature to ensure that it gets documented
> properly? Or that the code is readable? Etc.
>
> If it is too much to ask, then we should instead write disclaimers on
> the website to warn people instead of trying to boast about how
> awesome James is.
>
> > Don't like it? Don't use it.
>
> I don’t disagree with that statement. Let me just make sure that I
> completely understand with this test: if somebody dumps trash all
> over a public place, then states “Don’t like it? Don’t use it.” I
> don’t think I would be very happy. True, I won’t use a park full of
> trash because I don’t like it, but I think that’s an abuse of this
> principle. I trust that is not what you mean, right? I am assuming
> that what you mean is more along the lines of “The suit doesn’t fit?
> Ok, don’t wear it!"
>
> By all means, please go ahead and make nice suits, even if it doesn’t
> fit everybody. But please do not dump trash in the park.
Internet is not a finite space as parks are: you can create "internet
parks" at will with a single click, it's a button called "fork".
What I mean is: active community members define goals for the project
that matter to them, no matter what others expect. You want to
influence decision? Come and contribute. By the way, it's exactly what
you did: make the project change by contributing to it.
If you like the software and have different goals: fork it.
The only reason we care about users is because it matters to us not
because they have some rights on the project.
>
> > I am a volunteer in the Apache Software Foundation as all of us
> > are.
>
> Sorry… I took the bait and feel compelled to respond to your little
> lecture. 😀
>
> Are you really?
Yes, definitely.
> The definition I found was:
>
> > a person who does something, especially helping other people,
> > willingly and without being forced or paid to do it
>
> Except for the “without getting paid” part, I should point out that
> you are stating exactly the opposite. 😂
I don't. I am both a volunteer and a paid contributor.
> It’s all ok. You are just being honest about your intentions: you are
> in it for your own gain, not to help others. If others can benefit
> from your work, great, but that is not your primary objective. Fine.
Not my opinion at all.
> Of course there is nothing wrong with that. My efforts to help with
> documentation are not entirely altruistic, either. But you can’t have
> your cake and eat it, too. You can’t call yourself a “volunteer" if
> really you’re just in it for yourself and others just happen to maybe
> benefit. And if you really are in it to help others, then you would
> be thinking of them first.
There are more than two reasons to be here. I care about being paid, I
care about users but I also have other motivations. I don't feel like
help others should be "first".
>
> So yeah, let’s just be honest and set the right expectations so
> everybody is happy.
>
> Having an SLA will help do that. We should only commit to what we are
> willing to commit to, but there **must** be a clear definition of the
> service level that is being offered (even if essentially says "f***
> you stupid user”, at least that’s clear and honest.)
>
>
> Ok, all that was very abstract and waaaaaay off-topic, but I wasn’t
> expecting a reaction like the one you had so I had to have a little
> fun with it. 😂
>
> If you reread my initial message in this new light, I hope you’ll
> find that it was not intended to sound unreasonable. It is about
> honesty and expectation setting, not free work.
>
>
> So if we agree that an SLA is necessary (and I think we are
> agreeing), then most of what you wrote (i.e. what you are not willing
> to commit to) relates to what the contents of the SLA ought to be.
> And what you write makes good sense in that context.
>
I still think it's not a good idea unless you want to handle the SLA
yourself or with some other people from the community because I don't
expect to have a commitment with virtually anybody at anytime.
Cheers,
-- Matthieu Baechler
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Support and service levels
Posted by David Leangen <ap...@leangen.net>.
Hi,
Please be in a good mood when you read this. Words can be taken the wrong way. I am writing this with a big smile on my face, all in good humour. 😆
>>
>>> [... snipped everything ...]
>
> I agree with everything you wrote.
I think you are taking certain things a little too much out of context. 😀
My point is more about being honest than being generous. I am not trying to recruit anybody to provide free work. Not at all.
When I say there should be some kind of SLA, I am not at all suggesting that everybody commit a fixed amount of time or make any guarantees to solve other people’s problems for free. Actually, I thought I had proposed quite the opposite (that we list people and companies who are willing to do it for a fee.) So it sounds like we are very much in agreement. Nobody should be expected to work for free if the don’t want to.
My point is about being up front and honest, so people know what to expect and can weigh their options. In order to build trust, we need to set reasonable expectations (whatever they happen to be), and stick to them (or update them if we can’t). Personally, I prefer when somebody under-sells and over-delivers the somebody who does the opposite. I can trust that person and if I agree to their terms, I know I will be satisfied. From what I have read and based on the people I know, I think that most people appear to be the same.
If people don’t understand their options, then the unknowns make using James too risky. In my mind, that is not a successful community project.
For instance, if the website states that that a particular feature of James works, then it really should work. Otherwise nobody will trust the James community.
There are already basic standards in place and are I think being respected, else the community would very quickly fall apart:
* New features should have tests
* Tests should always pass
* Code should always compile
* Etc.
I could suggest that we add a bit to that list for the sole purpose of setting expectations and, hopefully, eventually expanding the community.
And anyway, is it really such a horrible thing, for instance, to ask somebody who commits a feature to ensure that it gets documented properly? Or that the code is readable? Etc.
If it is too much to ask, then we should instead write disclaimers on the website to warn people instead of trying to boast about how awesome James is.
> Don't like it? Don't use it.
I don’t disagree with that statement. Let me just make sure that I completely understand with this test: if somebody dumps trash all over a public place, then states “Don’t like it? Don’t use it.” I don’t think I would be very happy. True, I won’t use a park full of trash because I don’t like it, but I think that’s an abuse of this principle. I trust that is not what you mean, right? I am assuming that what you mean is more along the lines of “The suit doesn’t fit? Ok, don’t wear it!"
By all means, please go ahead and make nice suits, even if it doesn’t fit everybody. But please do not dump trash in the park.
> I am a volunteer in the Apache Software Foundation as all of us are.
Sorry… I took the bait and feel compelled to respond to your little lecture. 😀
Are you really?
The definition I found was:
> a person who does something, especially helping other people, willingly and without being forced or paid to do it
Except for the “without getting paid” part, I should point out that you are stating exactly the opposite. 😂
It’s all ok. You are just being honest about your intentions: you are in it for your own gain, not to help others. If others can benefit from your work, great, but that is not your primary objective. Fine.
Of course there is nothing wrong with that. My efforts to help with documentation are not entirely altruistic, either. But you can’t have your cake and eat it, too. You can’t call yourself a “volunteer" if really you’re just in it for yourself and others just happen to maybe benefit. And if you really are in it to help others, then you would be thinking of them first.
So yeah, let’s just be honest and set the right expectations so everybody is happy.
Having an SLA will help do that. We should only commit to what we are willing to commit to, but there **must** be a clear definition of the service level that is being offered (even if essentially says "f*** you stupid user”, at least that’s clear and honest.)
Ok, all that was very abstract and waaaaaay off-topic, but I wasn’t expecting a reaction like the one you had so I had to have a little fun with it. 😂
If you reread my initial message in this new light, I hope you’ll find that it was not intended to sound unreasonable. It is about honesty and expectation setting, not free work.
So if we agree that an SLA is necessary (and I think we are agreeing), then most of what you wrote (i.e. what you are not willing to commit to) relates to what the contents of the SLA ought to be. And what you write makes good sense in that context.
Cheers,
=David
Re: Support and service levels
Posted by Matthieu Baechler <ma...@apache.org>.
Hi,
On Fri, 2020-06-19 at 12:39 +0300, Eugen Stan wrote:
>
> > [... snipped everything ...]
I agree with everything you wrote.
Also, I get money from working on free software and I think it would
not make sense to expect free software to be funded exclusively by
unpaid volunteers time.
It's a sane thing that people can make free software go forward by
using companies money, by the way.
That's not to say I won't help people in the community on my own time
but I won't take any commitment to it and I think it would not help the
community to offer such commitments.
Cheers,
-- Matthieu Baechler
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Support and service levels
Posted by Eugen Stan <eu...@netdava.com>.
Hello David,
We all have our view of the world.
I am a volunteer in the Apache Software Foundation as all of us are.
I signed the ICLA https://www.apache.org/licenses/icla.pdf
"""
6. You are not expected to provide support for Your Contributions,except
to the extent You desire to provide support. You may providesupport for
free, for a fee, or not at all. Unless required byapplicable law or
agreed to in writing, You provide YourContributions on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONSOF ANY KIND, either express or implied,
including, withoutlimitation, any warranties or conditions of TITLE,
NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE.
"""
Free Software / Open source IMO does not mean costs or free work done by
others.
I can speak on my behalf, others might have different reasons for
contributing:
- I contribute because I like building software.
- I contribute to Open Source as a way of giving back for the software I
use to support myself.
- Open Source comes with no guarantees, just like some commercial
software does.
Don't like it? Don't use it.
- The community is a volunteer one and people have a life other than
fixing bugs for someone else for free.
This might sound a bit rude but so is the entitlement of saying: I
have a bug, fix it for me for free in X days.
- If you want support, contract a company or a person to help you out.
I won't stop anyone in offering free support or free services for the
software.
If you like to do it, it's fine; I will cheer for you, I might help from
time to time, but I personally can't commit to offering support for free.
I believe payed support is a very good thing and it's the job of companies.
The community should do it's best to help out when it can we can't offer
any guarantees as a community.
Let's say we do adopt a "We'll fix a bug in 4 weeks or less policy".
How would you enforce this in a community of volunteers?
The model doesn't make quite make sense IMO.
This email is my own opinions that may or may not be shared by others.
They don't seem to be shared by you.
I do not oppose us offering free support, but I will not commit to it
either.
I do support having a page of companies offering payed support for
Apache James.
Regards,
Eugen
La 15.06.2020 14:10, David Leangen a scris:
> I am moving a comment from Benoit to this new thread:
>
>> Also I would like to differentiate the terms "offering" (what do we
>> deliver as part of the James project, who do it targets, and how easy
>> should it be to use) from the term "support" which in my view implies
>> "how fast you solve my problems", and might be a more sensible topic.
>
> My thought is: if it is not “supported”, then it should not be “offered” in the first place.
>
> By “support”, I mean:
>
> * It is documented so Operators understand what they are operating
> * It works as documented
> * If it doesn’t work, there is some commitment by the community to fix it
>
> If there is no intention of doing all of the above, then it is not “supported” and should therefore not be “offered”. No confusion. Nobody will be let down.
>
> I think what you are describing refers to the "service level", which also ought to be described in order to set some kind of expectation. (People only get disappointed when their expectations are not met.) Because this is an open source project, it should be very relaxed (i.e. low expectations set, but at least some expectation). Perhaps we could also maintain a list of those who can provide commercial support if a higher service level is desired. However, people should not feel like they are being tricked or forced into commercial support.
>
> Some OSS projects have a “f**k you, this is open source so do it yourself or pay me!” attitude. I don’t think that is very nice and I don’t particularly like those projects. I believe that there should be some reasonable (on both sides) expectations. I believe that a community looks out for its members, and if we want to expand the community, we have to, at least to some extent, look out for those we are asking to join. But that’s just me, and it’s not for me to decide. :-)
>
> For instance:
>
> * The community commits to fixing a bug within X time
>
> X could either be vague (like “a reasonable amount of time given that we are all volunteers"), or something more concrete but plenty generous like “we strive to fix all issues within 4 weeks” (still just a small opening with the “we strive to” part).
>
> Then people can compare the James OSS service level to a commercial service level (which we should require if it is to put added to the list, like) "Issues fixed within 48 hours”.
>
> Or something like that.
>
> It would then be easy for people to make a decision:
>
> * Wait up to 4 weeks, but get free help, or
> * Pay ¥50,000 and get my problem fixed in 48 hours
>
> Cheers,
> =David
>
>
--
Eugen Stan
+40720 898 747 / netdava.com