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: [email protected]
[[email protected]] on behalf of Development @ ORCA
Services AG [[email protected]]
Sent: Thursday, November 22, 2012 2:24 PM
To: [email protected]
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
[email protected]<mailto:[email protected]>
T. +41 61 205 80 80
T. +41 61 205 80 73 (direkt)
F. +41 61 205 80 81
www.orca.ch<http://www.orca.ch>,
www.orca-services.ch<http://www.orca-services.ch>
"We convert your visitors into customers."
________________________________
Von: [email protected]
[mailto:[email protected]] Im Auftrag von Dave Holloway
Gesendet: Donnerstag, 22. November 2012 10:19
An: [email protected]
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-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 development/continuous-integration testing
wouldn't be too hard either: you would just need a few scripts to install
OXID-Basic and the addon packs and to run your tests on them.
What does anyone else think? I know it probably won't happen, but I fear that
OXID will soon slowly die away into insignificance if they don't update their
workflows to something more modern.
Dave
_______________________________________________
dev-general mailing list
[email protected]
http://dir.gmane.org/gmane.comp.php.oxid.general
