Hi Pierre, Everyone This was a long post, but I'll try to summarize your points to reply to them:
1- Projects provide these convenience downloads as a sign of maturity 2- The binary package provide an easy to run product which drives adoption with a "Just 1 click/ statement," 3- Other ASF projects have high adoption because of these packages like httpd and tomcat So in reply: 1- Some projects are less than 3 months old with binary packages. That is not a sign of maturity, it's just a convenience download. There are countless examples in Github 2- What is so difficult with ./gradlew loadDefault ofbiz? That is all you need to run the system. Oh and by the way, you still need to install Java right? You need to install Java whether it is a binary release or not. Someone with enough experience to download and install Java would probably be able to type ./gradlew loadDefault ofbiz in the command line. Furthermore, you cannot really use OFBiz OOTB right now can you? The accounting component needs configuring, the demo data needs to be removed, and almost every component needs tweaking to make it work for your business. This is much, much more complex and difficult than ./gradlew loadDefault ofbiz 3- You are comparing oranges and apples. Tomcat and httpd for example are web servers. They are things you just want to run and don't care much about (at least as a beginner) because what you care about is deploying YOUR web application on it. With OFBiz the story is different, this is a complex ERP system that does not just work OOTB (see my comments above). If anything, the only thing I would do with each release is to perhaps zip or tar the source and that's it. Then every user would download it, unzip, ./gradlew loadDefault ofbiz ... Done! Regards, Taher Alkhateeb On Thu, Aug 25, 2016 at 9:04 PM, Pierre Smits <pierre.sm...@gmail.com> wrote: > 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 > > >
