Before I answer the question that Jacques raised ( rephrased into: Should we generate binary packages aka zip files of our source releases as a convenience to our potential and existing adopters?), I will give my take on why I believe projects do provide those to the broader audience.
Projects provide these convenience downloads as a sign of maturity (of the code), as a statement (at that moment in time) of confidence to be able to say: 'if you run this -as is- you can use it for what we say you can use it for, as a means to promote the project and it's project as with each release there is something new to talk about. Each release, conveniently packaged into a zip, tar or whatever variant having something that can be run out of the box!. It is - also - the 'easy to run as is' that drives the success of adoption. Look at the success of products like ActiveMQ, Directory, Httpd, Studio, Tomcat, and many more under the umbrella of the ASF and elsewhere... Easy to run OOTB is key in this. Ease of use for first timers creates buzz, validates the reasons why contributors participate in the project. And yes, easy to extend help as much too. It is not the 'go download, configure, read documents (or in our project: filter through 1000s of email postings and out-of-date wiki pages), etc. etc. first to run it' that drives first time adopters, to see the success of the product, like we (the project) see it. It drives first timers away, because to difficult, community not participating enough... The various projects (including the one of which I am a part of PMC) ensure that the person downloading their product can have a one-click (entering a single statement through the cli) running product. Just 1 click/ statement, a bit of waiting and go use! (I would even go as far as in saying: the majority of projects of the ASF work towards providing that 1-click experience). Can this project provide that experience? Yes it can! But it requires volunteers willing to work towards that goal. After all, it's about scratching one's own itch, right? For the benefit of the first timer, the returning adopter, the project, this community and everyone participating in it. Now, having a product mature enough to be able to provide it to the intended audience (first timers in this case, not the the existing adopters who want to explore new stuff in the release in their own environment with their own data - although that is relatively easy to configure) requires a few extra steps: 1. create the binary package aka the zip file (build tools are used for that...) 2. sign the zip 3. make it available somewhere We have done so with every release in the past (and I thank Jacopo for each time he has taken that burden upon himself), expressing our confidence in the product as it was at that time. Having each time our moment to generate buzz. Now, we didn't deliver a 1 click experience, but what we provided OOTB was easy enough. And the community willing to help that new first timer. Through answers to questions posted. Some even wrote books about it. All acceptable. Nobody ever complained (AFAICT). So, back to the question: Should we generate binary packages aka zip files of our source releases as a convenience to our potential and existing adopters? Yes, we should! Each time we have a release! Each time this moment of celebration has arrived! I provided some arguments above. I feel confident there are enough +1 arguments one can image on this that outweigh the -1 arguments. It won't hurt our audience. It won't hurt the volunteer taking the extra step. It won't hurt the project or this community. In the previous postings I read arguments like 'it requires additional downloads, etc.' as one of the main reasons not to do these zips. I say: the build process takes care of this for that 1st time experience, and can take care of that 1-click experience. The product contains enough to extend that (and the project provides more than just that release) for those who want more. There are 2 things I see - with respect to that 1-click/1-statement experience - that are missing: 1. download of the external library that is required to facilitate the experience 2. incomplete cleanup process. It seems to me these omissions can be fixed easily before our next release. FWIW, issue OFBIZ-7783 <https://issues.apache.org/jira/browse/OFBIZ-7783> can be regarded as part of a 1-click experience. Best regards, Pierre Smits ORRTIZ.COM <http://www.orrtiz.com> OFBiz based solutions & services OFBiz Extensions Marketplace http://oem.ofbizci.net/oci-2/ On Thu, Aug 25, 2016 at 1:31 PM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > Le 25/08/2016 à 13:16, Taher Alkhateeb a écrit : > >> Glad you got the workarounds docs :) >> >> What do you mean by "your servers cannot connect to the Internet (but >> Internet can connect to them)"? Is that a DMZ, .iptables, port blocking, >> or >> what exactly? Sounds like what you're saying is not (no internet) but >> certain custom firewall / network settings >> > > Oh, they have clever enough engineers there to put you enough sticks in > your wheels, believe me ;) > > Eg: working with a PayPal sandbox w/o a browser installed on the test > server and no global Internet access (but specific dispensation, ie indeed > I guess several layers of .iptables, I mean several layers of servers with > of course also firewalls and such) > > Jacques >
