|
Author
|
Message
|
|
Nicolas Steinmetz
|
Thursday 09 September 2010 12:11:34 pm
Hi guys, As spotted by @bdunogier, the forum can be a better place than twitter for a discussion on this announcement. I started a new thread to avoid polluting the one of Nicolas P. regarding Governance ;-) Far from feeding a troll, the announcement leads me to the following questions / remarks :
- Will integrators sell service based on the community version or only the entreprise one (so customer is "forced" to subscribe to eZ Premium). Maybe small structures will based their work on the community version. But as the community version will be a kind of bleeding edge version, hard to guarantee some work on this. Bigger structure may chose the Entreprise version only.
- When will the two version differ too much to become 2 separate products ?
- eZ Publish said they proved the viability of the OSS business model. This annoucnement makes me think more about a strategy change than a confirmation of this business model
- For existing customer (with or without an integrator) that used the gpl version, what will they become as there will not be a stable version for a sane period of time (if they do not choose support)
- Stable vesion for a customer means Entreprise version. No support = no future ?
Am I the only sceptical in the room or do others share more or less the same feeling ? As a customer, I thnink this change could lead to see eZ Publish differently regarding their choice criterion.
|
|
Bertrand Maugain
|
Thursday 09 September 2010 1:30:15 pm
Hi Nicolas, You made the effort to post a discussion in English here, so I will do the same! :) Let me react on your different points to give you my view of this : 1) Integrators : which version to use? I would say it is up to the integrator to decide ! Their decision should be based on how business critical the website of their customers is and if that would require the rock solid, tested version (Enterprise Edition) or the one where innovation happens (Community Edition). That being said, you are aware of the 2 Partner Programs we have today : Community Partners and Business Partners.
- Community Partners want to show their knowledge of eZ technology and their implication in the ecosystem (sometimes very involved as Share.ez.no team members) but do not want to commit to any business / commercial relation with eZ. Most of the time, they use the Community Edition and sell their consulting services and support services on top of it. This is absolutely understandable
- Business Partners commit to the Business model of eZ : they want to be trained, certified (and retrained and recertified at each new release) and they understand that eZ makes its business on Enterprise Subscriptions. They do want eZ to be successful commercially and we commit to bring business to them. Those partners base all their projects on the Enterprise Editions and sell their consulting services and 1st level support services to their clients. You are right that those companies tend to be larger companies working with medium to large projects.
But again, it is up to anyone to decide what version to use. And it should be this way ! 2) Will the 2 versions differ too much to become two separated products? From my perspective, they are 2 different products already. Even if 90% of the functionality will be similar, the testing, the packaging, the releases will be different. All commodity functionality has to be part of the Community Edition. We may consider having some Enterprise Only plug ins in the future, if this makes sense. Today, we actually already have that since the eZ Network modules enable the monitoring and automatic patching for our Premium ( now renamed Enterprise Subscription) clients. So yes, they are different and depending on the criticality of the website / portal it possible to choose what is needed. The path between both editions (both GPL by the way) are key and it should be easily possible to go from one to the other. More technical people may be willing to comment that part but be sure we want to stay away from Vendor Lock In! 3) Proven Viability of the OSS Business model You are right. We have proven this and the essence of that success if the presence of a vendor able to control and guarantee the quality of an open source software. At the same time, I want to say that this new distribution model does not change our Business model at all. The main concepts are still valid.Users and Integrators still have the choice to choose between eZ Publish with or without support, guarantee, maintenance, bug fixes, clear IP. Our Premium Subscriptions today include eZ Publish with Service Packs and some modules (like eZ network) enabling us to deliver maintenance and added value services. The reason of the move is to take eZ Publish one step forward. We believe we can get more speed in the development, more innovation that should allow us to become even more attractive and competitive. Why now and not 2 years ago? Because we have restructured our all engineering activities with a heart bit development cycle (6 months) and this process is now over. The engineering machine is working and we can add the Community aspect on top of it. So our business is still about selling subscriptions and the main reason of that move is community involvement. 4) Concerning your 2 last points, the main aspect here is that bug fixes will be back-ported in the trunk of the community for the next version being developed. I think that the pictures on the CMSWire article illustrate that well : http://www.cmswire.com/cms/web-cms/ez-systems-splits-web-cms-software-into-community-enterprise-editions-008542.php I am sure Roland Benedetti and Nicolas will be documenting the processes around this much more in details in the next days and weeks. I think my answer is already quite long but I want to finish that it is more than allowed to be skeptical. Now it is our job to make that happen and prove that this new model can be even more successful. I think the last sentence of the CMSWire article is a perfect conclusion : "If that process proves to be healthy and timely, then this restructuring sounds like a win-win for community and company alike, and should be applauded." Give us some time to implement that and please jump in the community train ! :) Sorry for a long post !!
Bertrand
|
|
Nicolas Steinmetz
|
Thursday 09 September 2010 4:28:23 pm
Hi Bertrand, Thanks for the (long) answer. Happy to see that my post is not seen as a troll/fud/... but as a request for explaination and that you play the game (thanks for that, one point for eZ ;-) ) Maybe should I add that the firm I work for started an eZ Premium contract in July. Back to your answers : Integrators For me there were just the community and Business Partners. It does not change that much for the role of each of them with what you say by the end. The shift looks for me as a way to "force" buying the support to eZ Systems. I agree it's your business model and you need this. But as a serious customer, it looks now you cannot use eZ Publish without the Entreprise edition. I understand your point of view but I see some issues :
- Customer will have pay twice for the support in some extend : once when dealing with its integrator and one with eZ Systems. What is the interest of the customer or even the integrator here ? Looks that for the customer, it just add salt on the bill. Customer usually relies on its integrator to provide support and expertise on the product (= business model for OSS integrators).
- In our case, we took eZ Premium because we internalized the development (so no more integrators) and we may need some support for development, deployment & co. So eZ Premium makes sense for us.
- Even in our case : we took support for two projects made with eZ Publish. What happens if we start a new one. Do we also have to add it into the support to use eZ Publish ?
Kind of "vente forcée/liée" in fact ;-) One or two products For me and according to sales people from eZ Systems, so far, eZ Premium = unique eZ Publish product + services including some certified extension, the eZ Network module (which does not support proxy (weird for a corp module...)), certification, audit, training, etc. No problem with this :-) With the shift to two versions, I cannot see how the product cannot diverge :
- each of them has its own release schedule and may have some extra code
- Even if eZ Systems makes the sync between both code, I doubt it will be able to do it on the long term : huge costs due to time & ressources required for this
- You could say me that eZ Publish is modular and that divergence will be only on extensions but one day, there will be divergence on the kernel itself.
- So even if code is GPL and you want to avoid the vendor lock in, bridge between both versions will be broken somehow in the future. There may be some importer/converter from time to time but they would be more workaround than something else.
- What will eZ Systems do when the Community version will be too far from the entreprise one and that you will have no more interests in it as you don't earn money with it ?
OSS Business model So if you proved it, why changing ? Why don't you just open the code to some externals, with keeping control on the code and defining some rules for maintaing a stable "entreprise ready" product ? Looks eZ Systems has more a copyright issue than a coding one in fact. Many "entreprise" or not OSS are opened to externals who proved their value to be promoted commiters of the solution. I think a better solution was to open code to some externals and define some rules to maintain your QA objectives for example. Thus, you would have been able to maintain one single product and not two. The "lab" features could have intialized within a single product I think with some experimental branches (like some branches of the linux kernel for example). I think (I hope so at least ;-) ) you thought about it and evaluted it. If it's not confidential (I would understand it is), I would like to understand why you did not chose this way for opening the code. To conclude with, of course I will let you the opportunity and the time for explaining us how it will move forward. I'm quite interested in it even if I'm now quite cautious. To be honnest, I think many people (integrator, customer, etc) will think twice before starting new projects with eZ Publish with current conditions. Sorry also for the long post :-)
|
|
Bertrand Maugain
|
Friday 10 September 2010 12:18:34 am
Hi Nicolas, I think this is good a opportunity to explain things. So here I go again, trying to keeping as short as possible. Integrators About support (which is only one side of our Enterprise Edition by the way). First, the new distribution model does not change the fact that you buy support from an integrator / web agency and from eZ. This is the way it is today and since the beginning of the Partner Program in 2005, we have been working on co-selling support together with our partners. Indeed, a client should get project support from his local partner who is the best choice in order to cover what this company has specifically implemented. The question is :"does the customer need to get additional Vendor support to cover the core of the product?" I would say not necessarily for small projects where the website / intranet / portal is not critical. For larger projects, it definitely does and you illustrate that well with your own case where you actually play the role of the integrator. And as our business partners (who use the Enterprise Edition for all projects), while you take care of what you implement, you appreciate the fact that you can benefit from the service from eZ. So in my opinion having first level support from a partner and 2nd level from the vendor has nothing to do with this new approach. But it could actually help clients and partners to make their decision if they need both or not. Of course you could say that it is forcing medium and large clients to buy the Enterprise Edition but it is also those clients who are buying Premium today. One or Two products You are asking me to predict the future and what you describe may happen indeed. I am simply able to repeat what I told you yesterday. All the management at eZ is aware that the PATH between the 2 editions is a key element. How will that concretely be in 4 releases from now? Will there be a 2 way upgrade path? Will we merge repositories after some time when we see that a too big gap does not serve the ecosystem as it should? I am not able to answer (and I will let Nico comment these things :) ). But a sure thing is that we are aware that the commercial success of the Enterprise Edition depends on the success of the Community Edition. The other way around is not true and will not benefit to eZ in the long run. And I am sure you would agree that the Community initiatives launched during the last 12 months confirm that move : Community Manager in place ( Nico!), new community portal, european community tour launched now, community project announced this week. And more to come. Time will show ! OSS Business model I thought I told you that we are not changing our business model :) But you bring a very important point : IP. This is something we do not want to compromise on. The main reason is that some large enterprises choose eZ because of that. I personally believe this is a competitive advantage and if we manage to open up the development as we are initiating now AND keep a clear IP, we will be very successful. You can argue that we would get even more community involvement if we would not keep the copyright. And I totally agree. But the attractiveness of the model will decrease in large enterprises because they want to have a clear IP situation, because they sometimes HAVE TO use a proprietary license (and we can dual license eZ Publish thanks to the copyright). So we will continue selling subscriptions based on a Open Source software we have copyright on. We will continue working very closely with Business Partners to achieve our goals from a short term to mid term commercial perspective and with our Community to develop even faster and get the most attractive product in the market. For those who think that it is a move in the Proprietary direction, I hope that they now understand that we are actually going more in the other direction. We are moving from a development mode that was quite proprietary (with community extensions) to a much more open mode. That is it for now Nicolas. I will let the other Nicolas comment on this and take the discussion further and I will go back to working on the 4.4 release and the new ez.no website. Stay tuned :) Thanks for the discussion which will hopefully be useful for others. See you maybe on the 21st in Paris if I manage to make it. Cheers,
Bertrand
|
|
Nicolas Pastorino
|
Friday 10 September 2010 1:25:27 am
Hi Nicolas,
Thanks for this interesting discussion, absolutely not trollish. It brings key questions into the limelight and helps transparently clarify all points of this new distribution model.
Let me add a few elements, following the discussion structure you guys proposed. One or Two productsWhile we are no soothsayers, we have a bit of intuition. One major risk is to see divergence grow between the Community Project and the Enterprise Edition, as you pointed. It turns out to be common sense to diminish this risk, and this will not only be eZ's responsibility, but the Community Project Board's. This is embodied by points 2 & 3 of the Board responsibilities drafted out there : http://share.ez.no/blogs/ez/the-community-project-step-1-governance. The core of our Community is made of professionals, working on a daily basis with eZ Publish. They are, in average, addressing mid-size projects on which vendor warrantee may be required (vendor support, hence Enterprise Edition). The same people can become contributors to the Community Project, eating some of their time, and are not likely to be willing to harm their own business when contributing to their preferred CMS. This brushes up the very reason for opening-up Community contribution : innovation. The Community Project is all about this, and reducing the drift can be enforced practically :
- Any specific addition we would add to the Enterprise Edition will purely be in an extension
- While the release cycle for the Community Project will be decided by the Board, it will be smartly picked to be in synchronization with the Enterprise Edition release cycle (the one you currently know). This concretely means that for every cycle, all bits of innovation which happened in the Community Project will potentially be repatriated to the Enterprise Edition, and run through the enterprise edition QA machine. Regular repatriations reduce their average size, the time required, the resources required.
- Potential kernel differences should be avoided. Having eZ dudes aboard on the Community Project, as well as having the eZ Engineering team working hand in hand with the Community contributors will mean discussion, understanding each others' ins & outs, find compromises when trade-offs need to be made, etc…basically : people from different horizons collaborating towards one goal : making eZ Publish tomorrow's killer Content Management Platform. That is point 3 in the Board's responsibilities.
OSS Business modelI think Bertrand pointed to the essence of it all here : Intellectual Property. eZ keeping her IP on eZ Publish is key to the survival of eZ Publish. And this will server everyone in the ecosystem, at no exception. This has never been contradictory with openness, transparency, community-driven contribution and innovation, specially with regards to the nature of our Community, as stated earlier : largely composed of persons making commercial uses of eZ Publish in their professional activity.
Well, now time to deep-dive back in our beloved Community.
I hope to see you in Paris on the 21st ( http://share.ez.no/blogs/ez/ez-community-tour-paris-sept.-21st ) Cheers !
--
Nicolas Pastorino
Director Community - eZ
Member of the Community Project Board
eZ Publish Community on twitter: http://twitter.com/ezcommunity
t : http://twitter.com/jeanvoye
G+ : http://plus.tl/jeanvoye
|
|
Kevin Gaudin
|
Friday 10 September 2010 4:01:04 am
Hi, I might be Nicolas Steinmetz "spokesman" at the september 21st Paris event ;-) (unless he decides to come anyway) I have no clear idea for now on how your new governance changes will affect or not our projects, but I'll try to depict here how our company took the path from a community-only usage of eZ Publish to a Premium contract. I think this may lead to some interesting discussion too. As the effective product selection could be applied to any other OSS based project, I'm not going to use the CMS or eZ Publish terms, just to be sure to have a discussion on licensing principles and not product-specific aspects.
- A project starts with some business entity expressing needs for a new application. Analysis of the business needs and expected user experience allow us to define a set of required technical features for the project.
- If an enterprise product is already defined as the corporate standard product for this type of project, just use it.
- If the corporate selected solutions do not qualify (i.e. do not provide the right set of features or is becoming obsolete), selecting an OSS product gives an oportunity to start without additional licence/support costs on top of project human costs.
- When a first project has already been delivered successfuly, other new projects in need of the same type of technical features will naturally use the selected OSS product with benefits of both pricing and corporate experience.
- As the usage of the selected OSS solution grows and become the base of business critical applications, official commercial support with well-defined QoS engagement and warranties come in the discussion with IT managers.
Until now, with your previous product governance, things were quite straightforward : just contact eZ Systems and agree on a contract. If this process was to happen now, in addition of the commercial negocation comes the question of the technical prerequisites : will eZ Systems support my existing applications ? As the Professional edition is only available to eZ Systems paying customers, this means that I have developed my applications with the Community Edition. Now that I need your support, am I forced to migrate from Community to Enterprise (with potential technical nightmares => additional costs) or am I forced to contract with an Integtrator who will help me with my Community edition applications without official eZ Systems support ? This could sound quite awkward to IT Managers. Moreover, your support contracts are based on the number of databases and siteaccess and not a global usage license... If I want to start a new project without adding new licensing costs, I will have to use the Community Edition anyway... This sounds rather complicated to me... and if it does to a technical guy like me, I don't think it will sound good to the people who give the money.
Twitter: @kevingaudin
|
|
Nicolas Pastorino
|
Friday 10 September 2010 7:56:14 am
Hi Kevin and thanks for continuing this discussion ! The one principle easily solving the situation you are describing (pretty generic one, smart choice) is drift control. It will be of the Community Project Board's responsibility to control divergence between the kernel used for the Enterprise Edition and the Community Project one. This opens for smooth migrations paths, back and forth.
Business cases like the one you described must remain a non exceptional, easy to deal with situation once the new distribution model is running. eZ is well aware of this, and will diligently take care of it. This practically translates into having, when it comes to the eZ side of the Community Project Board, a comprehensive set of views on our market :
- A representative from the eZ Consulting team. Having been one for 3 years, i can assure you that they know what a project is and what adding vendor support means (migration, platforms validations, audits). They are deep fried in our market every day.
- A representative of the eZ Engineering team. They are here to put up bond for the technical details of migrations to Enterprise Edition. They know what Quality Assurance is. Their participation to the Board, through their representative, will help us foresee any divergence, solve it immediately or reduced its impact to a negligible detail.
- myself, acting mostly in the first times of the Board's existence, as a facilitator. I have been in turn Consultant, eZ Engineer, and now am in touch with you guys, our fantastic Community, on a daily basis. This should help greasing the process.
Needless to say that the community members who will integrate the Board will bring a tremendous real-life experience with eZ Publish too. Maybe Bertrand will bring complimentary information, to provide you with the most exhaustive answer possible.
HTH :)
See you in Paris on the 21st !
Cheers,
--
Nicolas Pastorino
Director Community - eZ
Member of the Community Project Board
eZ Publish Community on twitter: http://twitter.com/ezcommunity
t : http://twitter.com/jeanvoye
G+ : http://plus.tl/jeanvoye
|
|
Bertrand Maugain
|
Friday 10 September 2010 8:17:59 am
Hi Kevin, Very good questions and comments ! Thanks. I see 3 important aspects that should address your questions :
- eZ supports existing eZ Publish versions for the next 3 years. Even if a client uses eZ Publish 4.1 and contacts us, we will be able to deliver support & maintenance to that client. This is an important point
- Processes to control the split between the 2 versions and to bring a path between them, as explained by Nicolas.
- eZ Publish Enterprise Trials. In both situations (initial project or not) you can use the Community Edition (thanks to 2.) or try the Enterprise Editions. This is something that will be possible and even Business Partners will have their own eZ Publish Enterprise Trial environment.
When it comes to the pricing model, this is the same as it is today. If you have 4 sites and 4 databases on the Enterprise Edition and want to add an additional one as part of your agreement, this is possible at an extra fee. I think your situation and the scenario that you describe would be very similar. That is your decision to know if you want a subscription or not, and our role to make sure we can deliver the subscription service to you either by support an older version or by bringing you as smoothly as possible on the Enterprise Edition track. I hope this helps and again these are very valid questions !
Bertrand
|
|
Nicolas Steinmetz
|
Sunday 12 September 2010 1:10:46 pm
@Bertrrand (for your answer on my post) : I'm volountary provocative and a kind a "devil's advocate" in my thoughts. I hope you will succeed as my firm use your product and as it would avoid some mess at my level ;-). As a personnal point of view, I have never been a big fan of eZ as a product, maybe due to a bad experience (eZ Publish was young, Project should not have been developped with eZ but with a framework as most of the project was an application and not a CMS and our experience in eZ was small + offshoring). As said here, I hope that Community initiatives are not the tree that hides the forest (does not know if the proverb exists in english, but as you speak french, you know what I mean ;-) ). Let's see how this will move forward. @Nicolas P (for your answer on my post) : I have no issue with IP. My concern is that if you made two repositories just for IP, I think it's the wrong decision. It could have been managed with the "Code rules" for eZ Publich that all code is ceased to eZ Systems. @Nicolas P / Bertrand : regarding your answers to Kevin : There is one thing I do not understand : Let's imagine I have two projects based on eZ Publish Entreprise Edition. I have to start another one. Can I use the eZ Publish Entreprise edition for this project without support as long as I do not request / need it ? Or do I have to use the Community Edition for this third project ? For very small project, it will overkill the project's costs to add the support... :-( If unfortunately code diverge, it means that our developpers need to know almost two differents products depending on the project. To be efficitient, I need one single base code. My concern here is that it could lead people to use a given CMS for big/critical projects and another one for small/medium/non-critical ones with the risk that the second CMS will at the end become the single one for unicity / maintenability / ... purposes. I should be there the 21 for the morning session. Did not get any confirmation so far. Normal ? Cheers, Nicolas
|
|
Geoff Bentley
|
Tuesday 28 September 2010 2:14:39 pm
I have to say, reading through all this and the press release, I'm still confused. The press release says: eZ Publish Enterprise, the version designed for professional use of eZ Publish either under the traditional GPL license or the Professional User Licence (PUL). This version will be available on a bi-annual basis (March and September), and available only through eZ Publish Enterprise Subscription So, a couple of simple questions - I hope you can provide short simple answers:
- If I want to use eZ Publish Enterprise, do I need to sign up with eZ for support?
- If I can't use Enterprise without eZ support, will there be a stable community build, with a similar 6-month release cycle?
Thanks in advance, Geoff
|
|
Nicolas Pastorino
|
Tuesday 28 September 2010 2:53:09 pm
"
- If I want to use eZ Publish Enterprise, do I need to sign up with eZ for support?
"
Hi Geoff ! Yes. eZ Publish Enterprise will also be available as a trial version, for one month. A good way to test it out and/or demo it to customers
"
2. If I can't use Enterprise without eZ support, will there be a stable community build, with a similar 6-month release cycle?
"
Yes, there will be Community Project builds, the frequency of which will be decided by the Community Project Board. The release pace is very likely to somehow match the Enterprise Edition release cycle. I hope these answer were short enough :) Cheers !
--
Nicolas Pastorino
Director Community - eZ
Member of the Community Project Board
eZ Publish Community on twitter: http://twitter.com/ezcommunity
t : http://twitter.com/jeanvoye
G+ : http://plus.tl/jeanvoye
|
|
Sergiy Pushchin
|
Thursday 30 September 2010 3:09:17 am
Hi Nicolas! I am not sure if you ignored bolded text from Geoff by reason, or simply did not spotted it. But I would +1 his question. If you in your press release say: eZ Publish Enterprise, the version designed for professional use of eZ Publish either under the traditional GPL license or the Professional User Licence (PUL). that eZ Publish Enterprise will be available under "traditional GPL licence" it means that I can send to eZ request about getting eZ Publish Enterprise sources and eZ has to give me possibility to download it without any added services or fees.Otherwise you can not say that it is available under this licence. Even if it is a mistake in your press release. Then next question - do I need as a contributor to eZ Publish Comunity release sign a CLA agreement with eZ, as it was before? ;) If not - this mean that you have no right to lock in eZ Publish Enterprise after any line of code of external contributor without signed CLA gets into EE version. Is eZ aware of this?
|
|
Nicolas Pastorino
|
Friday 01 October 2010 2:43:46 am
Hi Sergiy, Thanks for asking for clarifications on these key topics, and thanks for your warnings. Let me bring additional details to your interrogations. First, please have a look at my replies to other, various interrogations there, this will bring first answer elements : http://share.ez.no/forums/discussions/the-base-of-the-community-project-ez-publish-fuji-4.4-released-today.-let-s-launch-the-rocket/comment62211 Secondly, the fact that eZ Publish Enterprise Edition can be distributed under the terms of the GPL license does not necessarily imply that eZ must make it available to anybody, anytime. There is no such constraint in the GPL license. Thirdly, as a contributor to the eZ Community Project, you will have to sign a Contributor License Agreement. This implies that eZ conserves IP (copyright) on the eZ Publish code, and never violates the terms of the GPL license. This ensures that eZ Publish still is properly backed by the eZ, as a vendor, and does not conflict at all with opening-up contribution to the code (within the Community Project, and by extension to eZ Publish Enterprise Edition). This measure serves all sides : innovation, community involvement, enterprise setups and subscription needs.
I hope this brought a fair share of clarification,
Looking forward to hearing your reactions on this,
Cheers,
--
Nicolas Pastorino
Director Community - eZ
Member of the Community Project Board
eZ Publish Community on twitter: http://twitter.com/ezcommunity
t : http://twitter.com/jeanvoye
G+ : http://plus.tl/jeanvoye
|
|
Sergiy Pushchin
|
Friday 01 October 2010 6:47:28 am
Hi Nicolas, thanks for your answers and afford you put to explain everyone eZ's position!
|
|
Michael Lee
|
Friday 01 October 2010 6:36:05 pm
Hi All, Thanks a lot for sharing the information above. Just a few questions about the enterprise edition and the community edition as follows: I have downloaded the eZ Publish enterprise trial edition (v4.4) and eZ Publish community edition (v4.4). I wanted to find out the differences between them at the code base level, so I tried to compare their code base. And since I know that some extensions are not included in the community edition by default, so I removed the extension folders and the "eZ Publish Enterprise - Trial Subscription Agreement v2.pdf". Here is the diff result: _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ diff -uraN ez440 eze440
diff -uraN ez440/kernel/setup/steps/ezstep_create_sites.php eze440/kernel/setup/steps/ezstep_create_sites.php
--- ez440/kernel/setup/steps/ezstep_create_sites.php 2010-09-28 17:03:48.000000000 +0800
+++ eze440/kernel/setup/steps/ezstep_create_sites.php 2010-09-28 17:28:20.000000000 +0800
@@ -1036,7 +1036,7 @@
// Enable OE and ODF extensions by default
$extensionsToEnable = array();
// Included in "fat" install, needs to override $extraCommonSettings extensions
- $extensionsPrepended = array( /*@EZP_BUILD_EXTENSION_ACTIVATE@*/ 'ezjscore' );
+ $extensionsPrepended = array( 'ezmultiupload', 'ezjscore' );
foreach ( array( 'ezie', 'ezoe', 'ezodf' ) as $extension )
{
if ( file_exists( "extension/$extension" ) )
diff -uraN ez440/share/filelist.md5 eze440/share/filelist.md5
--- ez440/share/filelist.md5 2010-09-28 17:20:10.000000000 +0800
+++ eze440/share/filelist.md5 2010-09-28 17:37:30.000000000 +0800
@@ -3031,7 +3031,7 @@
af2f1d8caddc94465f3b105fd090f139 kernel/setup/session.php
4df29ca23909ef8d956b6c1022228943 kernel/setup/settingstoolbar.php
bb5e33ec5e03eb55b7e6947157d3cdb0 kernel/setup/setupmenu.php
-548dc6795d606dff5235e1f44b536e15 kernel/setup/steps/ezstep_create_sites.php
+457de6bb5a4156bc05f0be4727119eb0 kernel/setup/steps/ezstep_create_sites.php
4f3ec003a5bad893728c574abb8e1636 kernel/setup/steps/ezstep_data.php
f4ed397a2bf06a55aadf1c523b38656d kernel/setup/steps/ezstep_database_choice.php
4302a1c2e0398a836fc88aad284e516f kernel/setup/steps/ezstep_database_init.php _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ As we can see from the result, there is no difference between the community edition and enterprise edition in the kernel and lib and that is very good at this moment. However, I think what concerns the developers, partners as well as the customers is: will the code base between eZ Publish enterprise edition and eZ Publish community edition always remain as consistent as above? I don't know the details of how two editions are going to be maintained, but I guess there might several possibilities as follows: 1. Two separate teams maintain two separate branches, and they will revise eZ Publish kernel as well as lib independently. As per Steinmetz's post, this will definitely lead to code base inconsistency and finally result in two totally different products.I guess no one, including eZ, wants it to happen. 2. Two separate teams maintain two separate branches, however, any changes on kernel and lib in one branch will be merged into the trunk (or *master branch) of the other branch. In other words, for enterprise team, they shall make sure to commit any changes (including hot-fixes) to enterprise repository and community repository, while the community team shall commit any changes to community repository and enterprise repository (can they?). However, since the community version can be contributed by the community members, eZ shall take control of the commit process and make sure the code base of community version will not be "polluted". 3. The enterprise team does not change the enterprise edition directly. In stead, the enterprise edition directly comes from the community edition, so all changes will be made on community version first, being tested, then merged into the enterprise edition. And this means community release always comes before enterprise release and of course, the code base of two editions will remain consistent as well. So can someone let me know which scenario above best describes how the enterprise edition and community edition are maintained? If scenario #1 is the case, it will be a bad news for everyone. For developers and partners, we will have to learn two different products in the future, while for customers, they will not be able to switch to enterprise edition if they want to because of the code base inconsistency. If scenario #2 is the case, I will have a few questions about the issue tracker as follows: a) When we report an issue in the future, shall we choose "eZ Publish enterprise edition" or "eZ Publish community edition"? For now, there is no such option b) Or will the issue tracker be used for reporting issues for "eZ Publish community edition" only? c) For now, when an issue is fixed, we will know which revision the fix has been merged into. But again, will the issue tracker tell us if a fix has been merged into enterprise edition repository or community edition repository? d) If all changes are going to be merged into two branches all the time, then technically, we can always get the latest fixes from the community repository. However, just in case, what if an issue is fixed in the enterprise edition, but not committed into the community repository? Who will be there to make sure it happens? If scenario #3 is the case, that will be great. Please feel free to get back to me with your comments. Kind regards, Michael
Michael Lee | Managing Director | ZerusTech Ltd | www.zerustech.com
Skype: zerustech
|
|
Marko Žmak
|
Sunday 03 October 2010 11:41:54 am
"
3. The enterprise team does not change the enterprise edition directly. In stead, the enterprise edition directly comes from the community edition, so all changes will be made on community version first, being tested, then merged into the enterprise edition. And this means community release always comes before enterprise release and of course, the code base of two editions will remain consistent as well.
"
My vote for option 3.
--
Nothing is impossible. Not if you can imagine it!
Hubert Farnsworth
|
|
Jean-Yves Zinsou
|
Friday 22 October 2010 1:13:16 am
"
3. The enterprise team does not change the enterprise edition directly. In stead, the enterprise edition directly comes from the community edition, so all changes will be made on community version first, being tested, then merged into the enterprise edition. And this means community release always comes before enterprise release and of course, the code base of two editions will remain consistent as well.
"
My vote for option 3 to.
Do Androids Dream of Electric Sheep?
I dream of eZpubliSheep....
------------------------------------------------------------------------
http://www.alma.fr
|