Re: [oxid-dev-general] OXID Deployment System + The Community
Hi guys, @Dave: thanks for your thoughts. This is close to the way we are thinking presently. But: no decisions made yet nor any time frame! Actually, the development and CI structures have been build up before we went open source. In this time nobody expected any contributions :-) The re-structure is just a technical issue as well as a question of time and resources: the code base has to be split, the CI process (grown historically) has to be re-factored etc... @Alex: this will never ever happen Never say never. but to me this looks like a prevention mechanism so nobody can recreate enterprise features Wrong. Oxid will end up like osCommerce did. You could have found a better example ;) @Marc: You're wrong. Regards and have a nice weekend Marco From: dev-general-boun...@lists.oxidforge.org [dev-general-boun...@lists.oxidforge.org] on behalf of Development @ ORCA Services AG [developm...@orca.ch] Sent: Thursday, November 22, 2012 2:24 PM To: dev-general@lists.oxidforge.org Cc: Dino Fellmann - ORCA Services AG Subject: Re: [oxid-dev-general] OXID Deployment System + The Community Hi Dave Thanks for your thoughts. To put it simple: In my opinion OXID eSales, or better said the management of them, never really understood the concept of a real community driven/developed, open source software. What they see is a product to market, a property to protect, just like a usual piece of proprietary software. They talk about the OXID eco system, not the community, there we have it. And thus we will never ever see something just remotely resembling to what you described if not something in management’s head changes… It’s kind of depressing but that’s the way I, and probably not just me, see it. Greetings from Switzerland Marc Würth ORCA Services AG Bahnhofstrasse 11 CH-4133 Pratteln Office Basel: Aeschengraben 10, CH-4051 Basel marc.wue...@orca.chmailto:marc.wue...@orca.ch T. +41 61 205 80 80 T. +41 61 205 80 73 (direkt) F. +41 61 205 80 81 www.orca.chhttp://www.orca.ch, www.orca-services.chhttp://www.orca-services.ch We convert your visitors into customers. Von: dev-general-boun...@lists.oxidforge.org [mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von Dave Holloway Gesendet: Donnerstag, 22. November 2012 10:19 An: dev-general@lists.oxidforge.org Betreff: [oxid-dev-general] OXID Deployment System + The Community Hi all, I was having a bit of a surf yesterday and found this comment from Erik: http://phpterror.wordpress.com/2009/08/26/oxid-esales-show-me-your-94-unit-test-coverage/#comment-16 The original post was about unpublished Unit-Tests, which wasn't terribly interesting, but it was the comment that caught my eye. It describes the internal code deployment system of OXID and why it's tricky to accept code contributions. It's now clear to me why the switch to a distributed version platform such as GIT/GITHub/BitBucket is so difficult: OXID has one codebase, and the deployment scripts remove certain parts for the different distributions (i.e the SOAP-Code gets removed for PE, and the WYSIWYG-Editor gets removed for CE etc.). This means it isn't practical or even possible for OXID to share their code, and why we only have access to the neutered pseudo SVN repository at http://svn.oxid-esales.com, where almost all authors are called nightlybuild. The whole structure got me thinking: why does this problem exist?, and I'm pretty sure that it all boils down to the marketing of the editions (CE/PE/EE). Each edition is advertised as a separate product, each with (basically) a separate license. Since most of the codebase of the 3 editions are the same, people who want to contribute need to jump through hoops and sign NDAs/similar documents to agree that the code belongs to OXID and that they have the right to distribute it in all three editions without the requirement of making PE/EE open-source. So my question: why not do it differently? The name community edition is (in my opinion) misleading and seems to have earned the reputation of take this, go away, and stop complaining about it Dave. Why not do something completely different and take CE, rename it to OXID eSales Basic, keep the license as GNU and continue to sell your commercial/encrypted PE/EE features under a different license as 'addon packs', such as Professional Addon Pack and Enterprise Addon Pack? This way, you can keep the basic core open-source and even put it on GitHub, where you will be able to obtain free code contributions/patches from many many developers, and it will still allow you to sell your advanced features and not lose money. The community developers wouldn't have to sign any silly NDAs either. The PE/EE Addon packs could still be versioned internally and wouldn't have to be open-source. So, kurz zusammengefasst, my suggestion would be: - Replace the CE-Edition as OXID eSales Basic - Sell the PE
Re: [oxid-dev-general] OXID Deployment System + The Community
Hi Marco, in my opinion OXID could be much more community driven without code contributions if there was more communication. OXID devs very rarely comment conceptual suggestions in this list and also in the bugtracker. Before developing or submitting new code, the concepts behind the new code would have to be discussed, which is not happening. This leads to the impression that there is no way to contribute to development process except posting bugs where documented features do not work the way they are documented, or Uservoice where new features can be suggested. Both places are not suitable for suggesting conceptual changes to the code, so you can only wait until next release to see what the devs have cooked in their private kitchen. Regards Frank Von: dev-general-boun...@lists.oxidforge.org [mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von Marco Steinhaeuser Gesendet: Freitag, 23. November 2012 12:09 An: dev-general@lists.oxidforge.org Betreff: Re: [oxid-dev-general] OXID Deployment System + The Community Hi guys, @Dave: thanks for your thoughts. This is close to the way we are thinking presently. But: no decisions made yet nor any time frame! Actually, the development and CI structures have been build up before we went open source. In this time nobody expected any contributions :-) The re-structure is just a technical issue as well as a question of time and resources: the code base has to be split, the CI process (grown historically) has to be re-factored etc... @Alex: this will never ever happen Never say never. but to me this looks like a prevention mechanism so nobody can recreate enterprise features Wrong. Oxid will end up like osCommerce did. You could have found a better example ;) @Marc: You're wrong. Regards and have a nice weekend Marco _ From: mailto:dev-general-boun...@lists.oxidforge.org dev-general-boun...@lists.oxidforge.org [dev-general-boun...@lists.oxidforge.org] on behalf of Development @ ORCA Services AG [developm...@orca.ch] Sent: Thursday, November 22, 2012 2:24 PM To: mailto:dev-general@lists.oxidforge.org dev-general@lists.oxidforge.org Cc: Dino Fellmann - ORCA Services AG Subject: Re: [oxid-dev-general] OXID Deployment System + The Community Hi Dave Thanks for your thoughts. To put it simple: In my opinion OXID eSales, or better said the management of them, never really understood the concept of a real community driven/developed, open source software. What they see is a product to market, a property to protect, just like a usual piece of proprietary software. They talk about the OXID eco system, not the community, there we have it. And thus we will never ever see something just remotely resembling to what you described if not something in managements head changes Its kind of depressing but thats the way I, and probably not just me, see it. Greetings from Switzerland Marc Würth ORCA Services AG Bahnhofstrasse 11 CH-4133 Pratteln Office Basel: Aeschengraben 10, CH-4051 Basel mailto:marc.wue...@orca.ch marc.wue...@orca.ch T. +41 61 205 80 80 T. +41 61 205 80 73 (direkt) F. +41 61 205 80 81 http://www.orca.ch www.orca.ch, http://www.orca-services.ch www.orca-services.ch We convert your visitors into customers. _ Von: dev-general-boun...@lists.oxidforge.org [mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von Dave Holloway Gesendet: Donnerstag, 22. November 2012 10:19 An: mailto:dev-general@lists.oxidforge.org dev-general@lists.oxidforge.org Betreff: [oxid-dev-general] OXID Deployment System + The Community Hi all, I was having a bit of a surf yesterday and found this comment from Erik: http://phpterror.wordpress.com/2009/08/26/oxid-esales-show-me-your-94-unit-t est-coverage/#comment-16 The original post was about unpublished Unit-Tests, which wasn't terribly interesting, but it was the comment that caught my eye. It describes the internal code deployment system of OXID and why it's tricky to accept code contributions. It's now clear to me why the switch to a distributed version platform such as GIT/GITHub/BitBucket is so difficult: OXID has one codebase, and the deployment scripts remove certain parts for the different distributions (i.e the SOAP-Code gets removed for PE, and the WYSIWYG-Editor gets removed for CE etc.). This means it isn't practical or even possible for OXID to share their code, and why we only have access to the neutered pseudo SVN repository at http://svn.oxid-esales.com, where almost all authors are called nightlybuild. The whole structure got me thinking: why does this problem exist?, and I'm pretty sure that it all boils down to the marketing of the editions (CE/PE/EE). Each edition is advertised as a separate product, each with (basically) a separate license. Since most of the codebase of the 3 editions are the same, people who want to contribute need to jump through hoops and sign NDAs/similar documents to agree
Re: [oxid-dev-general] OXID Deployment System + The Community [T-EK59Y2G4LW-57]
you are so right Frank I agree in all points :) Mit freundlichen Grüßen Martina Schimbach http://www.facebook.com/www.bastelundhobbykiste.de Martinas Bastel- Hobbykiste Geschäftsleitung Bestellhotline: 0800-9655324 Martinas Bastel- Hobbykiste Inh. Martina Schimbach Zum Grund 9 35796 Blessenbach Germany USt-IdNr.: DE 187589656 Tel: 0049 (0) 6474 - 882816 Fax: 0049 (0) 6474 - 8525 Internet: http://www.bastelundhobbykiste.de/ (http://www.bastelundhobbykiste.de) oder http://www.kreative-buecher.de/ (http://www.kreative-buecher.de) e-Mail: i...@bastelundhobbykiste.de -Ursprüngliche Daten- Datum: 23.11.2012 13:02:31 Von: Frank Zunderer frank.zunde...@zunderer.de An: dev-general@lists.oxidforge.org Betreff: Re: [oxid-dev-general] OXID Deployment System + The Community Vorgang: T-EK59Y2G4LW-57 Hi Marco, in my opinion OXID could be much more bdquocommunity drivenldquo without code contributions if there was more communication. OXID devs very rarely comment conceptual suggestions in this list and also in the bugtracker. Before developing or submitting new code, the concepts behind the new code would have to be discussed, which is not happening. This leads to the impression that there is no way to contribute to development process except posting bugs where documented features do not work the way they are documented, or Uservoice where new features can be suggested. Both places are not suitable for suggesting conceptual changes to the code, so you can only wait until next release to see what the devs have cooked in their private kitchen. Regards Frank Von: dev-general-boun...@lists.oxidforge.org [mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von Marco Steinhaeuser Gesendet: Freitag, 23. November 2012 12:09 An: dev-general@lists.oxidforge.org Betreff: Re: [oxid-dev-general] OXID Deployment System + The Community Hi guys, @Dave: thanks for your thoughts. This is close to the way we are thinking presently. But: no decisions made yet nor any time frame! Actually, the development and CI structures have been build up before we went open source. In this time nobody expected any contributions :-) The re-structure is just a technical issue as well as a question of time and resources: the code base has to be split, the CI process (grown historically) has to be re-factored etc... @Alex: this will never ever happen Never say never. but to me this looks like a prevention mechanism so nobody can recreate enterprise features Wrong. Oxid will end up like osCommerce did. You could have found a better example ;) @Marc: You're wrong. Regards and have a nice weekend Marco From: dev-general-boun...@lists.oxidforge.org [dev-general-boun...@lists.oxidforge.org] on behalf of Development @ ORCA Services AG [developm...@orca.ch] Sent: Thursday, November 22, 2012 2:24 PM To: dev-general@lists.oxidforge.org Cc: Dino Fellmann - ORCA Services AG Subject: Re: [oxid-dev-general] OXID Deployment System + The Community Hi Dave Thanks for your thoughts. To put it simple: In my opinion OXID eSales, or better said the management of them, never really understood the concept of a real community driven/developed, open source software. What they see is a product to market, a property to protect, just like a usual piece of proprietary software. They talk about the OXID eco system, not the community, there we have it. And thus we will never ever see something just remotely resembling to what you described if not something in managementrsquos head changeshellip Itrsquos kind of depressing but thatrsquos the way I, and probably not just me, see it. Greetings from Switzerland Marc Würth ORCA Services AG Bahnhofstrasse 11 CH-4133 Pratteln Office Basel: Aeschengraben 10, CH-4051 Basel marc.wue...@orca.ch T. +41 61 205 80 80 T. +41 61 205 80 73 (direkt) F. +41 61 205 80 81 www.orca.ch , www.orca-services.ch We convert your visitors into customers. Von: dev-general-boun...@lists.oxidforge.org [ mailto:dev-general-boun...@lists.oxidforge.org ] Im Auftrag von Dave Holloway Gesendet: Donnerstag, 22. November 2012 10:19 An: dev-general@lists.oxidforge.org Betreff: [oxid-dev-general] OXID Deployment System + The Community Hi all, I was having a bit of a surf yesterday and found this comment from Erik: http://phpterror.wordpress.com/2009/08/26/oxid-esales-show-me-your-94-unit-test-coverage/#comment-16 The original post was about unpublished Unit-Tests, which wasn't terribly interesting, but it was the comment that caught my eye. It describes the internal code deployment system of OXID and why it's tricky to accept code contributions. It's now clear to me why the switch to a distributed version platform such as GIT/GITHub/BitBucket is so difficult: OXID has one codebase, and the deployment scripts remove certain parts for the different distributions (i.e the SOAP-Code gets removed
Re: [oxid-dev-general] OXID Deployment System + The Community
Hi there, this will never ever happen - oxid's enterprise features are mostly coupled deeply into the core. I don't know why this is done, but to me this looks like a prevention mechanism so nobody can recreate enterprise features without hacking the core system or jumping through hoops. But I like your idea, and I think this would be the way to go - otherwise some day a fork will be made and Oxid will end up like osCommerce did. -- mit freundlichen Gren Alexander Kludt __ Phone: 09283-5925453 Fax: 09283-592671 Skype: kingschnulli Email: cod...@aggrosoft.de Website: www.aggrosoft.de __ Aggrosoft it intelligence GbR Tannstrasse 12 95111 Rehau GERMANY Sitz Rehau, Amtsgericht Hof Steuernummer: 223/165/54508 Ust.-Id. Nr. gem 27 a Umsatzsteuergesetz: DE260722773 ___ Diese Nachricht ist nur fr den Empfnger () bestimmt, sollten Sie nicht der Empfnger sein lschen Sie diese Nachricht umgehend und geben Sie uns bitte per Email (cod...@aggrosoft.de) Bescheid ber den flschlichen Erhalt. Dave Holloway 22. November 2012 10:19 Hi all, I was having a bit of a surf yesterday and found this comment from Erik: http://phpterror.wordpress.com/2009/08/26/oxid-esales-show-me-your-94-unit-test-coverage/#comment-16 The original post was about unpublished Unit-Tests, which wasn't terribly interesting, but it was the comment that caught my eye. It describes the internal code deployment system of OXID and why it's tricky to accept code contributions. It's now clear to me why the switch to a distributed version platform such as GIT/GITHub/BitBucket is so difficult: OXID has one codebase, and the deployment scripts remove certain parts for the different distributions (i.e the SOAP-Code gets removed for PE, and the WYSIWYG-Editor gets removed for CE etc.). This means it isn't practical or even possible for OXID to share their code, and why we only have access to the neutered pseudo SVN repository at http://svn.oxid-esales.com, where almost all authors are called "nightlybuild". The whole structure got me thinking: why does this problem exist?, and I'm pretty sure that it all boils down to the marketing of the editions (CE/PE/EE). Each edition is advertised as a separate product, each with (basically) a separate license. Since most of the codebase of the 3 editions are the same, people who want to contribute need to jump through hoops and sign NDAs/similar documents to agree that the code belongs to OXID and that they have the right to distribute it in all three editions without the requirement of making PE/EE open-source. So my question: why not do it differently? The name "community edition" is (in my opinion) misleading and seems to have earned the reputation of "take this, go away, and stop complaining about it Dave". Why not do something completely different and take CE, rename it to "OXID eSales Basic", keep the license as GNU and continue to sell your commercial/encrypted PE/EE features under a different license as 'addon packs', such as "Professional Addon Pack" and "Enterprise Addon Pack"? This way, you can keep the "basic" core open-source and even put it on GitHub, where you will be able to obtain free code contributions/patches from many many developers, and it will still allow you to sell your advanced features and not lose money. The community developers wouldn't have to sign any silly NDAs either. The PE/EE Addon packs could still be versioned internally and wouldn't have to be open-source. So, kurz zusammengefasst, my suggestion would be: - Replace the CE-Edition as "OXID eSales Basic" - Sell the PE-Edition as "OXID eSales Basic + Professional Addon Pack" - Sell the EE-Edition as "OXID eSales Basic + Enterprise Addon Pack" ...this would solve your licensing issues, would give you the ability to harness the power of the OXID developer community. And to be super-sure that you don't have to distribute your code for PE and EE, you could deliver each product as two separate ZIP files. e.g. (oxid-basic.zip and oxid-pe-addonpack.zip). Internal
