On Friday, April 13, 2012 10:21:59 AM UTC-4, Amy Stephen wrote:
> Hey Will -
> First, so glad to have your involvement, given your database and Semantic
> Web background.
> The platform team is definitely working on major refactoring and that's
> part of the challenge here. If it were simply a matter of minor changes, it
> might be different, but there are deep architectural changes and plans for
> more, coming. So, bearing that in mind, imagine dropping in a new
> foundation that has only been unit tested, into each release of the CMS.
> The purpose of the new CMS release schedule is to conhease and they will
> have to invest time bringing their extensions to spec. But, if the CMS
> includes the platform in each release, and the platform is in major
> refactoring, that means the API could (and will) change with minor CMS
> releases.
> If that's the case, how do 3rd party developers keep up?
> We've been through the cycle one time and that is what happened. That's
> also why devs are wound pretty tight and reacted so strongly to what turned
> out to be a very minor change. They are struggling to keep up.
> If the CMS takes a platform release and goes with it for the entire series
> (updating for major bug issues and security issues), that will help
> stabilize the API after the 3.x release. The platform team can continue
> aggressively refactoring packages and refooting the architecture and 3rd
> party devs can rest assured that they won't have to respond to these
> changes with each CMS release.
> Otherwise, we basically have put the platform team on a six month release
> schedule -- and you'll see much more of this type of drama from 3rd party
> developers because it will be impossible to keep up.
> Have not even mentioned the impact of change on users.
> I've been thinking about ideas for CMS maintainer release teams who can
> help with change management. It might be a good way to engage site builders
> and 3rd party devs in leadership and working roles so that they can help
> manage and communicate the change.
> I like the new schedule. I like the direction things are heading. I think
> we can continue in those directions, better engaging the community, to make
> certain the platform team has room to innovate while managing the change
> better when it hits the real world.
> Hope that helps explain my perspective on this. Over time, as the platform
> stabilizes again, the software will be much more like utilities and
> bringing in new releases will not have the impact it does today.
> Amy
> On Fri, Apr 13, 2012 at 4:42 AM, Will Daniels <m...@willdaniels.co.uk>wrote:
>> Hi Amy,
>> Please excuse my butting in. I don't know all that much about Joomla! but
>> like anyone who has had to manage large software projects where there is a
>> separate platform team I have come up against this issue a few times. So
>> this is just my 2p from my own similar experiences.
>> On 13/04/12 03:19, Amy Stephen wrote:
>>> Elin - Certainly bug fixes and security patches should be applied to the
>>> version selected, but the CMS has got to hold on a version in order to
>>> help
>>> give the platform team room to work. If the CMS tries to keep pace then
>>> every little change the platform makes is going to be scrutinized - and
>>> rightly so! - for potential impact on the developer and user community.
>> I think you might be overstating the general problem based on the current
>> context. This only tends to be an issue for major refactoring work, which
>> in some ways is what the platform is all about, but continual refactoring
>> is likely to become as much of a problem for the Platform itself as it
>> would be for the CMS.
>> I would say the key is to hammer out expectations in advance, which seems
>> to be what is happening here anyway. I understand what you are saying about
>> the Platform needing room to work, but it needs to find a way to do this
>> while still feeding the CMS with new features and new versions.
>> You are assuming the Platform team will have the most inertia for change,
>> but I would be surprised if that happens, except where it comes to
>> architecture. Demand for features will never cease within the CMS and
>> better those features be supplied by the Platform where they fall to that
>> arena.
>> I have seen Platform teams get left behind fussing over architecture
>> while Application teams forge ahead implementing everything their clients
>> need in half-arsed ways that just "get the job done"...even to the point
>> where the Platform code becomes largely redundant in the Apps, which begin
>> to create Platform-esque Apps to do things they haven't been able to just
>> merge from the "real" Platform.
>> We moved from three years between releases where developers could work -
>>> and where servers sat with the same release - to half that time for CMS
>>> releases. But if the CMS picks up the newest release all the time, then
>>> the
>>> platform team gets about 6 months to introduce new code and stabilize.
>>> So,
>>> when and where do they work?
>> Create multiple branches where you need room, and even release multiple,
>> imperfect implementations of the same feature to maintain some amount of
>> backward-compatibility. Whatever you have to do to keep everything flowing
>> in both directions, as often as possible, is a price worth paying IMHO.
>> I believe the single worst result is what will happen if the two sides
>> stop co-operating and stop syncing.
>> In that recent thread "Is three years long enough" on the general list -
>>> people were very clear, it's getting to the point where site builders are
>>> struggling with justifying using Joomla with their clients. We want it
>>> all
>>> but most people just want it to work and more mature code tends to be
>>> much
>>> better for that.
>> Agreed. But that should be motivation for site builders to assist with
>> sponsoring continued development of extensions they use and QA efforts in
>> the CMS. Open Source projects rely upon vested interests for quality and
>> interesting problems for progress. But you need to have both happening at
>> the same time to keep things moving, it's no use trying to have a two-speed
>> project.
>> There are some examples in the FLOSS world where multi-speed projects do
>> work, like the Linux Kernel. Some distros move faster than others,
>> depending on their purpose. RHEL for example moves slowly, applying mostly
>> security patches and bug fixes, while focussed on building enterprise apps.
>> It is like the CMS as site-builders would have it.
>> Others, like Ubuntu/Fedora, move much faster and integrate new kernels
>> more quickly. There is market demand for both, as there is in the CMS. The
>> Kernel moves at it's own pace, which is very fast and they don't care too
>> much about breaking drivers that don't want to implement revised
>> interfaces. If it's not maintained, it gets dumped.
>> But that works for Linux because it is a symbiotic relationship between
>> distros for different purposes. They all feed off each other through a
>> common conduit - the Kernel. What Elin keeps pointing out, and I agree
>> with, is that the Joomla! Platform does not yet have multiple applications
>> of any significance, so there is only a conflict between real problems and
>> interesting problems, and the split falls cleanly between Platform and CMS.
>> The result is that the Platform and CMS stakeholders conflict directly.
>> Until there are other applications to balance the ecosystem they need to
>> work closely together.
>> Perhaps there is a need for two CMS applications at different speeds, as
>> I think was tentatively mentioned a couple of times already? I'm not sure
>> the balance can be struck more directly. The Platform needs to move fast.
>> The CMS needs to move both fast and slow at the same time. It seems logical.
>> -Will
On Friday, April 13, 2012 10:21:59 AM UTC-4, Amy Stephen wrote:
> Hey Will -
> First, so glad to have your involvement, given your database and Semantic
> Web background.
> The platform team is definitely working on major refactoring and that's
> part of the challenge here. If it were simply a matter of minor changes, it
> might be different, but there are deep architectural changes and plans for
> more, coming. So, bearing that in mind, imagine dropping in a new
> foundation that has only been unit tested, into each release of the CMS.
> The purpose of the new CMS release schedule is to concentrate major
> changes in the N.0 release. Developers should expect API changes in that
> release and they will have to invest time bringing their extensions to
> spec. But, if the CMS includes the platform in each release, and the
> platform is in major refactoring, that means the API could (and will)
> change with minor CMS releases.
> If that's the case, how do 3rd party developers keep up?
> We've been through the cycle one time and that is what happened. That's
> also why devs are wound pretty tight and reacted so strongly to what turned
> out to be a very minor change. They are struggling to keep up.
> If the CMS takes a platform release and goes with it for the entire series
> (updating for major bug issues and security issues), that will help
> stabilize the API after the 3.x release. The platform team can continue
> aggressively refactoring packages and refooting the architecture and 3rd
> party devs can rest assured that they won't have to respond to these
> changes with each CMS release.
> Otherwise, we basically have put the platform team on a six month release
> schedule -- and you'll see much more of this type of drama from 3rd party
> developers because it will be impossible to keep up.
> Have not even mentioned the impact of change on users.
> I've been thinking about ideas for CMS maintainer release teams who can
> help with change management. It might be a good way to engage site builders
> and 3rd party devs in leadership and working roles so that they can help
> manage and communicate the change.
> I like the new schedule. I like the direction things are heading. I think
> we can continue in those directions, better engaging the community, to make
> certain the platform team has room to innovate while managing the change
> better when it hits the real world.
> Hope that helps explain my perspective on this. Over time, as the platform
> stabilizes again, the software will be much more like utilities and
> bringing in new releases will not have the impact it does today.
> Amy
> On Fri, Apr 13, 2012 at 4:42 AM, Will Daniels <m...@willdaniels.co.uk>wrote:
>> Hi Amy,
>> Please excuse my butting in. I don't know all that much about Joomla! but
>> like anyone who has had to manage large software projects where there is a
>> separate platform team I have come up against this issue a few times. So
>> this is just my 2p from my own similar experiences.
>> On 13/04/12 03:19, Amy Stephen wrote:
>>> Elin - Certainly bug fixes and security patches should be applied to the
>>> version selected, but the CMS has got to hold on a version in order to
>>> help
>>> give the platform team room to work. If the CMS tries to keep pace then
>>> every little change the platform makes is going to be scrutinized - and
>>> rightly so! - for potential impact on the developer and user community.
>> I think you might be overstating the general problem based on the current
>> context. This only tends to be an issue for major refactoring work, which
>> in some ways is what the platform is all about, but continual refactoring
>> is likely to become as much of a problem for the Platform itself as it
>> would be for the CMS.
>> I would say the key is to hammer out expectations in advance, which seems
>> to be what is happening here anyway. I understand what you are saying about
>> the Platform needing room to work, but it needs to find a way to do this
>> while still feeding the CMS with new features and new versions.
>> You are assuming the Platform team will have the most inertia for change,
>> but I would be surprised if that happens, except where it comes to
>> architecture. Demand for features will never cease within the CMS and
>> better those features be supplied by the Platform where they fall to that
>> arena.
>> I have seen Platform teams get left behind fussing over architecture
>> while Application teams forge ahead implementing everything their clients
>> need in half-arsed ways that just "get the job done"...even to the point
>> where the Platform code becomes largely redundant in the Apps, which begin
>> to create Platform-esque Apps to do things they haven't been able to just
>> merge from the "real" Platform.
>> We moved from three years between releases where developers could work -
>>> and where servers sat with the same release - to half that time for CMS
>>> releases. But if the CMS picks up the newest release all the time, then
>>> the
>>> platform team gets about 6 months to introduce new code and stabilize.
>>> So,
>>> when and where do they work?
>> Create multiple branches where you need room, and even release multiple,
>> imperfect implementations of the same feature to maintain some amount of
>> backward-compatibility. Whatever you have to do to keep everything flowing
>> in both directions, as often as possible, is a price worth paying IMHO.
>> I believe the single worst result is what will happen if the two sides
>> stop co-operating and stop syncing.
>> In that recent thread "Is three years long enough" on the general list -
>>> people were very clear, it's getting to the point where site builders are
>>> struggling with justifying using Joomla with their clients. We want it
>>> all
>>> but most people just want it to work and more mature code tends to be
>>> much
>>> better for that.
>> Agreed. But that should be motivation for site builders to assist with
>> sponsoring continued development of extensions they use and QA efforts in
>> the CMS. Open Source projects rely upon vested interests for quality and
>> interesting problems for progress. But you need to have both happening at
>> the same time to keep things moving, it's no use trying to have a two-speed
>> project.
>> There are some examples in the FLOSS world where multi-speed projects do
>> work, like the Linux Kernel. Some distros move faster than others,
>> depending on their purpose. RHEL for example moves slowly, applying mostly
>> security patches and bug fixes, while focussed on building enterprise apps.
>> It is like the CMS as site-builders would have it.
>> Others, like Ubuntu/Fedora, move much faster and integrate new kernels
>> more quickly. There is market demand for both, as there is in the CMS. The
>> Kernel moves at it's own pace, which is very fast and they don't care too
>> much about breaking drivers that don't want to implement revised
>> interfaces. If it's not maintained, it gets dumped.
>> But that works for Linux because it is a symbiotic relationship between
>> distros for different purposes. They all feed off each other through a
>> common conduit - the Kernel. What Elin keeps pointing out, and I agree
>> with, is that the Joomla! Platform does not yet have multiple applications
>> of any significance, so there is only a conflict between real problems and
>> interesting problems, and the split falls cleanly between Platform and CMS.
>> The result is that the Platform and CMS stakeholders conflict directly.
>> Until there are other applications to balance the ecosystem they need to
>> work closely together.
>> Perhaps there is a need for two CMS applications at different speeds, as
>> I think was tentatively mentioned a couple of times already? I'm not sure
>> the balance can be struck more directly. The Platform needs to move fast.
>> The CMS needs to move both fast and slow at the same time. It seems logical.
>> -Will
On Friday, April 13, 2012 10:21:59 AM UTC-4, Amy Stephen wrote:
> Hey Will -
> First, so glad to have your involvement, given your database and Semantic
> Web background.
> The platform team is definitely working on major refactoring and that's
> part of the challenge here. If it were simply a matter of minor changes, it
> might be different, but there are deep architectural changes and plans for
> more, coming. So, bearing that in mind, imagine dropping in a new
> foundation that has only been unit tested, into each release of the CMS.
> The purpose of the new CMS release schedule is to concentrate major
> changes in the N.0 release. Developers should expect API changes in that
> release and they will have to invest time bringing their extensions to
> spec. But, if the CMS includes the platform in each release, and the
> platform is in major refactoring, that means the API could (and will)
> change with minor CMS releases.
> If that's the case, how do 3rd party developers keep up?
> We've been through the cycle one time and that is what happened. That's
> also why devs are wound pretty tight and reacted so strongly to what turned
> out to be a very minor change. They are struggling to keep up.
> If the CMS takes a platform release and goes with it for the entire series
> (updating for major bug issues and security issues), that will help
> stabilize the API after the 3.x release. The platform team can continue
> aggressively refactoring packages and refooting the architecture and 3rd
> party devs can rest assured that they won't have to respond to these
> changes with each CMS release.
> Otherwise, we basically have put the platform team on a six month release
> schedule -- and you'll see much more of this type of drama from 3rd party
> developers because it will be impossible to keep up.
> Have not even mentioned the impact of change on users.
> I've been thinking about ideas for CMS maintainer release teams who can
> help with change management. It might be a good way to engage site builders
> and 3rd party devs in leadership and working roles so that they can help
> manage and communicate the change.
> I like the new schedule. I like the direction things are heading. I think
> we can continue in those directions, better engaging the community, to make
> certain the platform team has room to innovate while managing the change
> better when it hits the real world.
> Hope that helps explain my perspective on this. Over time, as the platform
> stabilizes again, the software will be much more like utilities and
> bringing in new releases will not have the impact it does today.
> Amy
> On Fri, Apr 13, 2012 at 4:42 AM, Will Daniels <m...@willdaniels.co.uk>wrote:
>> Hi Amy,
>> Please excuse my butting in. I don't know all that much about Joomla! but
>> like anyone who has had to manage large software projects where there is a
>> separate platform team I have come up against this issue a few times. So
>> this is just my 2p from my own similar experiences.
>> On 13/04/12 03:19, Amy Stephen wrote:
>>> Elin - Certainly bug fixes and security patches should be applied to the
>>> version selected, but the CMS has got to hold on a version in order to
>>> help
>>> give the platform team room to work. If the CMS tries to keep pace then
>>> every little change the platform makes is going to be scrutinized - and
>>> rightly so! - for potential impact on the developer and user community.
>> I think you might be overstating the general problem based on the current
>> context. This only tends to be an issue for major refactoring work, which
>> in some ways is what the platform is all about, but continual refactoring
>> is likely to become as much of a problem for the Platform itself as it
>> would be for the CMS.
>> I would say the key is to hammer out expectations in advance, which seems
>> to be what is happening here anyway. I understand what you are saying about
>> the Platform needing room to work, but it needs to find a way to do this
>> while still feeding the CMS with new features and new versions.
>> You are assuming the Platform team will have the most inertia for change,
>> but I would be surprised if that happens, except where it comes to
>> architecture. Demand for features will never cease within the CMS and
>> better those features be supplied by the Platform where they fall to that
>> arena.
>> I have seen Platform teams get left behind fussing over architecture
>> while Application teams forge ahead implementing everything their clients
>> need in half-arsed ways that just "get the job done"...even to the point
>> where the Platform code becomes largely redundant in the Apps, which begin
>> to create Platform-esque Apps to do things they haven't been able to just
>> merge from the "real" Platform.
>> We moved from three years between releases where developers could work -
>>> and where servers sat with the same release - to half that time for CMS
>>> releases. But if the CMS picks up the newest release all the time, then
>>> the
>>> platform team gets about 6 months to introduce new code and stabilize.
>>> So,
>>> when and where do they work?
>> Create multiple branches where you need room, and even release multiple,
>> imperfect implementations of the same feature to maintain some amount of
>> backward-compatibility. Whatever you have to do to keep everything flowing
>> in both directions, as often as possible, is a price worth paying IMHO.
>> I believe the single worst result is what will happen if the two sides
>> stop co-operating and stop syncing.
>> In that recent thread "Is three years long enough" on the general list -
>>> people were very clear, it's getting to the point where site builders are
>>> struggling with justifying using Joomla with their clients. We want it
>>> all
>>> but most people just want it to work and more mature code tends to be
>>> much
>>> better for that.
>> Agreed. But that should be motivation for site builders to assist with
>> sponsoring continued development of extensions they use and QA efforts in
>> the CMS. Open Source projects rely upon vested interests for quality and
>> interesting problems for progress. But you need to have both happening at
>> the same time to keep things moving, it's no use trying to have a two-speed
>> project.
>> There are some examples in the FLOSS world where multi-speed projects do
>> work, like the Linux Kernel. Some distros move faster than others,
>> depending on their purpose. RHEL for example moves slowly, applying mostly
>> security patches and bug fixes, while focussed on building enterprise apps.
>> It is like the CMS as site-builders would have it.
>> Others, like Ubuntu/Fedora, move much faster and integrate new kernels
>> more quickly. There is market demand for both, as there is in the CMS. The
>> Kernel moves at it's own pace, which is very fast and they don't care too
>> much about breaking drivers that don't want to implement revised
>> interfaces. If it's not maintained, it gets dumped.
>> But that works for Linux because it is a symbiotic relationship between
>> distros for different purposes. They all feed off each other through a
>> common conduit - the Kernel. What Elin keeps pointing out, and I agree
>> with, is that the Joomla! Platform does not yet have multiple applications
>> of any significance, so there is only a conflict between real problems and
>> interesting problems, and the split falls cleanly between Platform and CMS.
>> The result is that the Platform and CMS stakeholders conflict directly.
>> Until there are other applications to balance the ecosystem they need to
>> work closely together.
>> Perhaps there is a need for two CMS applications at different speeds, as
>> I think was tentatively mentioned a couple of times already? I'm not sure
>> the balance can be struck more directly. The Platform needs to move fast.
>> The CMS needs to move both fast and slow at the same time. It seems logical.
>> -Will
On Friday, April 13, 2012 10:21:59 AM UTC-4, Amy Stephen wrote:
> Hey Will -
> First, so glad to have your involvement, given your database and Semantic
> Web background.
> The platform team is definitely working on major refactoring and that's
> part of the challenge here. If it were simply a matter of minor changes, it
> might be different, but there are deep architectural changes and plans for
> more, coming. So, bearing that in mind, imagine dropping in a new
> foundation that has only been unit tested, into each release of the CMS.
> The purpose of the new CMS release schedule is to concentrate major
> changes in the N.0 release. Developers should expect API changes in that
> release and they will have to invest time bringing their extensions to
> spec. But, if the CMS includes the platform in each release, and the
> platform is in major refactoring, that means the API could (and will)
> change with minor CMS releases.
> If that's the case, how do 3rd party developers keep up?
> We've been through the cycle one time and that is what happened. That's
> also why devs are wound pretty tight and reacted so strongly to what turned
> out to be a very minor change. They are struggling to keep up.
> If the CMS takes a platform release and goes with it for the entire series
> (updating for major bug issues and security issues), that will help
> stabilize the API after the 3.x release. The platform team can continue
> aggressively refactoring packages and refooting the architecture and 3rd
> party devs can rest assured that they won't have to respond to these
> changes with each CMS release.
> Otherwise, we basically have put the platform team on a six month release
> schedule -- and you'll see much more of this type of drama from 3rd party
> developers because it will be impossible to keep up.
> Have not even mentioned the impact of change on users.
> I've been thinking about ideas for CMS maintainer release teams who can
> help with change management. It might be a good way to engage site builders
> and 3rd party devs in leadership and working roles so that they can help
> manage and communicate the change.
> I like the new schedule. I like the direction things are heading. I think
> we can continue in those directions, better engaging the community, to make
> certain the platform team has room to innovate while managing the change
> better when it hits the real world.
> Hope that helps explain my perspective on this. Over time, as the platform
> stabilizes again, the software will be much more like utilities and
> bringing in new releases will not have the impact it does today.
> Amy
> On Fri, Apr 13, 2012 at 4:42 AM, Will Daniels <m...@willdaniels.co.uk>wrote:
>> Hi Amy,
>> Please excuse my butting in. I don't know all that much about Joomla! but
>> like anyone who has had to manage large software projects where there is a
>> separate platform team I have come up against this issue a few times. So
>> this is just my 2p from my own similar experiences.
>> On 13/04/12 03:19, Amy Stephen wrote:
>>> Elin - Certainly bug fixes and security patches should be applied to the
>>> version selected, but the CMS has got to hold on a version in order to
>>> help
>>> give the platform team room to work. If the CMS tries to keep pace then
>>> every little change the platform makes is going to be scrutinized - and
>>> rightly so! - for potential impact on the developer and user community.
>> I think you might be overstating the general problem based on the current
>> context. This only tends to be an issue for major refactoring work, which
>> in some ways is what the platform is all about, but continual refactoring
>> is likely to become as much of a problem for the Platform itself as it
>> would be for the CMS.
>> I would say the key is to hammer out expectations in advance, which seems
>> to be what is happening here anyway. I understand what you are saying about
>> the Platform needing room to work, but it needs to find a way to do this
>> while still feeding the CMS with new features and new versions.
>> You are assuming the Platform team will have the most inertia for change,
>> but I would be surprised if that happens, except where it comes to
>> architecture. Demand for features will never cease within the CMS and
>> better those features be supplied by the Platform where they fall to that
>> arena.
>> I have seen Platform teams get left behind fussing over architecture
>> while Application teams forge ahead implementing everything their clients
>> need in half-arsed ways that just "get the job done"...even to the point
>> where the Platform code becomes largely redundant in the Apps, which begin
>> to create Platform-esque Apps to do things they haven't been able to just
>> merge from the "real" Platform.
>> We moved from three years between releases where developers could work -
>>> and where servers sat with the same release - to half that time for CMS
>>> releases. But if the CMS picks up the newest release all the time, then
>>> the
>>> platform team gets about 6 months to introduce new code and stabilize.
>>> So,
>>> when and where do they work?
>> Create multiple branches where you need room, and even release multiple,
>> imperfect implementations of the same feature to maintain some amount of
>> backward-compatibility. Whatever you have to do to keep everything flowing
>> in both directions, as often as possible, is a price worth paying IMHO.
>> I believe the single worst result is what will happen if the two sides
>> stop co-operating and stop syncing.
>> In that recent thread "Is three years long enough" on the general list -
>>> people were very clear, it's getting to the point where site builders are
>>> struggling with justifying using Joomla with their clients. We want it
>>> all
>>> but most people just want it to work and more mature code tends to be
>>> much
>>> better for that.
>> Agreed. But that should be motivation for site builders to assist with
>> sponsoring continued development of extensions they use and QA efforts in
>> the CMS. Open Source projects rely upon vested interests for quality and
>> interesting problems for progress. But you need to have both happening at
>> the same time to keep things moving, it's no use trying to have a two-speed
>> project.
>> There are some examples in the FLOSS world where multi-speed projects do
>> work, like the Linux Kernel. Some distros move faster than others,
>> depending on their purpose. RHEL for example moves slowly, applying mostly
>> security patches and bug fixes, while focussed on building enterprise apps.
>> It is like the CMS as site-builders would have it.
>> Others, like Ubuntu/Fedora, move much faster and integrate new kernels
>> more quickly. There is market demand for both, as there is in the CMS. The
>> Kernel moves at it's own pace, which is very fast and they don't care too
>> much about breaking drivers that don't want to implement revised
>> interfaces. If it's not maintained, it gets dumped.
>> But that works for Linux because it is a symbiotic relationship between
>> distros for different purposes. They all feed off each other through a
>> common conduit - the Kernel. What Elin keeps pointing out, and I agree
>> with, is that the Joomla! Platform does not yet have multiple applications
>> of any significance, so there is only a conflict between real problems and
>> interesting problems, and the split falls cleanly between Platform and CMS.
>> The result is that the Platform and CMS stakeholders conflict directly.
>> Until there are other applications to balance the ecosystem they need to
>> work closely together.
>> Perhaps there is a need for two CMS applications at different speeds, as
>> I think was tentatively mentioned a couple of times already? I'm not sure
>> the balance can be struck more directly. The Platform needs to move fast.
>> The CMS needs to move both fast and slow at the same time. It seems logical.
>> -Will
