On Mon, 22 Dec 2014 17:13:58 +0100, John Crisp wrote: > Indeed, you illustrate the problem and it is difficult to set a 'fixed' > price a a result. Geographical economics make it even worse - GBP10 to > you might be small change, to someone say in India it might be a months > wages for all we know.
If you do a direct exchange rate currency conversion. How much is a cup of Coffee/Tea in your country? As guide for "donations" multiply that cost by say 10. "Less than a cup of Coffee a month" looks like a good marketing tag to me. B-) You can't really use a alcholic drink as some countries are dry. Coffee/Tea, in one form or another, is pretty universal. > A big company may think it is nothing at all. Trying to cover all bases makes it complicated and difficult to administer. >> IMHO if they are not putting anything back into SME be that via bug >> fixes, development, NFRs or financially they are effectively stealing >> the code and efforts of others. Doesn't the licence have non-commercial >> use only" clause(s)? > > Basically GPL, so AFAIAA currently the answer is no. If it did have a > commercial use clause then anyone using it, be that as integrator, SOHO > business or whatever would fall under it. So everyone apart from Home > users would effectively be 'stealing' it ! Good point. I didn't like the word "stealing" but couldn't think of another with enough weight to provoke a response and further the discussion. B-) > So it isn't 'stealing' as the licence allows them to do what they do. > That's our fault (if there is one) not theirs. >From what I've seen in the posts so far the licence only means that the *source code* has to be freely available for any use. The compiled binaries, ISO, etc are another matter. Along with the other selling points of SME already mentioned is the bootable install ISO. Going from a bare machine to working server in few tens of minutes and only having to supply basic information has *a lot* of value. SME really does "just work, out of the box". Downloading all the individual source code packages, compiling, then trying to configure it would be quite an excercise. The template system and web based Server Manager are also invaluable for small organisations that can't afford an IT department or bring in a specialist but have a smattering of IT knowledge. Essentially the compiled ISO and Server Manger are the core of SME, perhaps the licence for those could be adjusted, if it needs to be as they are not source code, for future releases? Is there anything we can learn, in a very broad sense, from the RHEL/CentOS relationship? As I see it RHEL market and support a compiled system with some propritary components but make the non-propritary source code freely available, which is where CentOS pick it up. > The point I was trying to make is that they are more likely to > contribute if there is some form of gain or benefit for them. One of gain/benefits is having a "just works, out of the box" solution that is easy to maintain. How the transition from "everything free" to a paid for solution of *some form* is not easy. The first question is what bits could come under the "paid for" umbrella? A non-commercial use exemption? >> I'm tempted to say why should the foundation promote the freeloaders? Is >> it a safe assumption that this advertising would be paid for and at >> sensble, as in commercialish, rates? > > That was kind of the idea.... Again the problem is what is a commercial > rate ? It can vary wildy from country to country. And if you are an > integrator in say the US, do you want to be attracting support business > in India? We have to keep this very simple as a result. CentOS just have "sponsers" with each having a fixed/equal sized logo on the homepage. > As I mentioned there are companies who are willing to work with us with > partnerships like there used to be with Mitel, but we need some things > in order ourselves first. I'm very glad to hear that and am heartened that at least some companies do wish (and do) put something back into SME. > I would say that if someone is good enough to actually write a patch > they probably know a bit about bug trackers at least. >From my seat that is a bad assumption. I came from spotting a bug or wanting a new feature, digging about in the code, finding and fixing said bug/adding feature then wishing to report and give it back. I *then* came across Bugzilla... > The problem tends to be with less experienced people who would probably > do more with some encouragement if you can get them started. I think being flexable on how fixes etc are submitted would help. I can see from the devs point of view that having a standard diff output that can just be applied is wonderful but generating that is yet another block to climb for the novice. However devs spending time converting plain text descriptions of fixes into patches is not good use of their time. Seems that there is a need for a "bridge" on the SME side between the novice and devs. People with a working knowledge of some parts of SME that can check the code changes for obvious unintended effects and produce a patch for a dev to properly inspect. -- Cheers Dave. _______________________________________________ Discussion about project organisation and overall direction To unsubscribe, e-mail [email protected] Searchable archive at http://lists.contribs.org/mailman/public/discussion/
