[DISCUSSION] Defining an OFBiz Project Strategy

[Sharan Foga]

Hi Everyone

One of the topics that came up during the brainstorming in Seville was that the project desperately needs a clear strategy and roadmap.

Benefits:
- A strategy will provide a clear path for people to follow
- A strategy will allow us to set goals / milestones and metrics about progress

In past maybe we have tried to do too much (tried to do it all at once - which is why we find it h ard to focus).

- One suggestion was to set a maximum of 3 goals and then work only on these. To define these goals we need to look at what is the most important thing that we want to achieve - and base them on that.
- Another suggestion was that the most important thing for the project is driving adoption. If this is true then what are the key blockers that stop user adoption of OFBiz? (the UI!) 
- Suggestion to organise / setup teams from the community that focus on specific areas (e.g. workgroups) - this could really help progress

So to get the discussion started:

1. Do people agree that the project needs to focus on driving adoption?
2. Do people think that the UI is one of the key things that stops this ? (If, not then please include what do you think is)
3. What goals could we set?
4. Are people interested in working in workgroups, to focus on specific areas (or goals)?

(I know there are some ideas/work around the UI going on, but I will post the Seville details and notes about that in separate discussion thread.)

Thanks
Sharan

[Sharan Foga]

There was a bit that I missed - and this is a common thing that keeps coming back up when we get together and talk:

OFBiz could deliver more than one product. We could have more than one product active at the same time e.g

   - Framework with applications
   - Advanced UI but without all features
   - Advanced features but with the poor UI

This is also something that we could think about for the high level strategy.

Thanks
Sharan

On 2016-11-28 11:08 (+0100), "Sharan Foga"<[hidden email]> wrote:

> Hi Everyone
>
> One of the topics that came up during the brainstorming in Seville was that the project desperately needs a clear strategy and roadmap.
>
> Benefits:
> - A strategy will provide a clear path for people to follow
> - A strategy will allow us to set goals / milestones and metrics about progress
>
> In past maybe we have tried to do too much (tried to do it all at once - which is why we find it h ard to focus).
>
> - One suggestion was to set a maximum of 3 goals and then work only on these. To define these goals we need to look at what is the most important thing that we want to achieve - and base them on that.
> - Another suggestion was that the most important thing for the project is driving adoption. If this is true then what are the key blockers that stop user adoption of OFBiz? (the UI!) 
> - Suggestion to organise / setup teams from the community that focus on specific areas (e.g. workgroups) - this could really help progress
>
> So to get the discussion started:
>
> 1. Do people agree that the project needs to focus on driving adoption?
> 2. Do people think that the UI is one of the key things that stops this ? (If, not then please include what do you think is)
> 3. What goals could we set?
> 4. Are people interested in working in workgroups, to focus on specific areas (or goals)?
>
> (I know there are some ideas/work around the UI going on, but I will post the Seville details and notes about that in separate discussion thread.)
>
> Thanks
> Sharan
>
>

[taher]

Hi Sharan,

Thank you for starting this important topic. OFBiz definitely needs
strategic objectives and a sense of direction. To try to formulate a
strategy, I would suggest perhaps we highlight where I think OFBiz delivers
value and where it does not, and based on that provide a few suggestions on
moving forward.

OFBiz main value proposition
-------------------------------------------
- A very robust domain model based on the data model resource book.
- A library of services to control and manipulate the data model.
- A DSL that hides and abstracts away the complexity of everything
(services, entities, widgets, routing, etc...) and makes it easy for
adopters to provide value quickly.
- A business automation suite.

What OFBiz is not (yet?)
------------------------------------
Currently OFBiz may provide some of the below, but it is not the main value
proposition.

- A web framework
- A general purpose programming environment
- An ERP system ready for immediate use by business owners (not geared for
end-users)

Where should we focus?
-----------------------------------
If you agree with the above assessment on OFBiz's value proposition, then I
think we need to focus our limited resources and efforts and utilize the
help of the community where it provides the highest value for effort. To
start this discussion I suggest the list of below strategic objectives to
try and move forward over the next 1-2 years at which time we can review
and amend the strategy:

- UI redesign: I think the user interface is one of the weakest points in
our project and is probably the most critical item for adoption because at
the end this is what people _see_. Having non-technical people download
OFBiz, fire it up and start using it immediately without the intervention
of a consultant or a developer is key to bigger adoption. Bigger adoption
in turn leads to a more thriving community and business built around OFBiz.
Hence we need a fully redesigned user interface that is not a reference for
developers but rather a usable interface immediately to someone who needs
an ERP platform for their business.

- Documentation: We have a lot of documentation resources, but they are
unorganized, scattered and outdated. Documentation is another key driver of
adoption and I think a significant amount of work needs to go into
organizing and cleaning up our documentation. We need a unified resource
for getting information. I really like for example the documentation of
Gradle found in docs.gradle.org which breaks things down beautifully into a
user guide, a DSL reference and JavaDocs with very good sub-categorization
and hyperlinks between everything.

- Branding: A new website, activities on social media, success stories
(updating), references, etc ...

The reason I recommend the above strategic initiatives is that they are
relatively easy and most community members can contribute to which would
provide great value by leveraging the help of as many people as we can.

Thoughts?

Cheers,

Taher Alkhateeb

On Mon, Nov 28, 2016 at 1:35 PM, Sharan Foga <[hidden email]> wrote:

> There was a bit that I missed - and this is a common thing that keeps
> coming back up when we get together and talk:
>
> OFBiz could deliver more than one product. We could have more than one
> product active at the same time e.g
>
>    - Framework with applications
>    - Advanced UI but without all features
>    - Advanced features but with the poor UI
>
> This is also something that we could think about for the high level
> strategy.
>
> Thanks
> Sharan
>
> On 2016-11-28 11:08 (+0100), "Sharan Foga"<[hidden email]> wrote:
> > Hi Everyone
> >
> > One of the topics that came up during the brainstorming in Seville was
> that the project desperately needs a clear strategy and roadmap.
> >
> > Benefits:
> > - A strategy will provide a clear path for people to follow
> > - A strategy will allow us to set goals / milestones and metrics about
> progress
> >
> > In past maybe we have tried to do too much (tried to do it all at once -
> which is why we find it h ard to focus).
> >
> > - One suggestion was to set a maximum of 3 goals and then work only on
> these. To define these goals we need to look at what is the most important
> thing that we want to achieve - and base them on that.
> > - Another suggestion was that the most important thing for the project
> is driving adoption. If this is true then what are the key blockers that
> stop user adoption of OFBiz? (the UI!)
> > - Suggestion to organise / setup teams from the community that focus on
> specific areas (e.g. workgroups) - this could really help progress
> >
> > So to get the discussion started:
> >
> > 1. Do people agree that the project needs to focus on driving adoption?
> > 2. Do people think that the UI is one of the key things that stops this
> ? (If, not then please include what do you think is)
> > 3. What goals could we set?
> > 4. Are people interested in working in workgroups, to focus on specific
> areas (or goals)?
> >
> > (I know there are some ideas/work around the UI going on, but I will
> post the Seville details and notes about that in separate discussion
> thread.)
> >
> > Thanks
> > Sharan
> >
> >
>

[Olivier.heintz]

Answers are in-line

Le 28/11/2016 à 11:08, Sharan Foga a écrit :
> Hi Everyone
>
> One of the topics that came up during the brainstorming in Seville was that the project desperately needs a clear strategy and roadmap.
>

....

>
> So to get the discussion started:
>
> 1. Do people agree that the project needs to focus on driving adoption?
+10
but who are ours target :
  1) ERP services company (consultant or/and technical employees with ERP knowledge)
  2) or IT services company ( SME )
  3) or end user (manager who need a ERP)
  or both ;-)

( it's ordered in my point of view )

> 2. Do people think that the UI is one of the key things that stops this ? (If, not then please include what do you think is)
+10
but maybe the OOTB UI is not the same than the more professional business application plugins.
First should be more fashionable that the second which could be more sober and practical (maybe only a theme difference)

> 3. What goals could we set?
Taher start to answer, I will complete...

> 4. Are people interested in working in workgroups, to focus on specific areas (or goals)?
My "contribution areas" are
- UI scenario Test
- documentation (for consultant or/and technical  with ERP knowledge )
- using plugin manager to create small function plugin
- saying if it's usable by a functional consultant ;-)

>
> (I know there are some ideas/work around the UI going on, but I will post the Seville details and notes about that in separate discussion thread.)
>
> Thanks
> Sharan
>
>

[Olivier.heintz]

comment in-line

Le 28/11/2016 à 22:43, Taher Alkhateeb a écrit :

> Hi Sharan,
>
> Thank you for starting this important topic. OFBiz definitely needs
> strategic objectives and a sense of direction. To try to formulate a
> strategy, I would suggest perhaps we highlight where I think OFBiz delivers
> value and where it does not, and based on that provide a few suggestions on
> moving forward.
>
> OFBiz main value proposition
> -------------------------------------------
> - A very robust domain model based on the data model resource book.
> - A library of services to control and manipulate the data model.
> - A DSL that hides and abstracts away the complexity of everything (services, entities, widgets, routing, etc...)
>    and makes it easy for adopters to provide value quickly.

  - A plugin system AND a plugin strong organization
> - A business automation suite.
>
> What OFBiz is not (yet?)
> ------------------------------------
> Currently OFBiz may provide some of the below, but it is not the main value
> proposition.
>
> - A web framework
> - A general purpose programming environment
I prefer : A general purpose programming and parametrized environment
> - An ERP system ready for immediate use by business owners (not geared for end-users)
  - A business functions library usable to build a Vertical Business ERP solution

>
> Where should we focus?
> -----------------------------------
> If you agree with the above assessment on OFBiz's value proposition, then I
> think we need to focus our limited resources and efforts and utilize the
> help of the community where it provides the highest value for effort. To
> start this discussion I suggest the list of below strategic objectives to
> try and move forward over the next 1-2 years at which time we can review
> and amend the strategy:
>
> - UI redesign: I think the user interface is one of the weakest points in
> our project and is probably the most critical item for adoption because at
> the end this is what people _see_. Having non-technical people download
> OFBiz, fire it up and start using it immediately without the intervention
> of a consultant or a developer is key to bigger adoption. Bigger adoption
> in turn leads to a more thriving community and business built around OFBiz.
> Hence we need a fully redesigned user interface that is not a reference for
> developers but rather a usable interface immediately to someone who needs
> an ERP platform for their business.

I propose to change the last sentence by :
... developers but rather a usable interface immediately
to demonstrate ofbiz usability and flexibility
to someone who needs an ERP platform for their business.

Maybe the difference at which I want to point is only on the use case definition to implement on the OOTB kernel
>
> - Documentation: We have a lot of documentation resources, but they are
> unorganized, scattered and outdated. Documentation is another key driver of
> adoption and I think a significant amount of work needs to go into
> organizing and cleaning up our documentation. We need a unified resource
> for getting information. I really like for example the documentation of
> Gradle found in docs.gradle.org which breaks things down beautifully into a
> user guide, a DSL reference and JavaDocs with very good sub-categorization
> and hyperlinks between everything.
+10 for
> Documentation is another key driver of
> adoption and I think a significant amount of work needs to go into
> organizing and cleaning up our documentation.
But also at the technical architecture and tools available for the writers.

Documentation (creating / modifying / reading / customizing / organizing) should be part of the
" general purpose programming and parametrized environment"
Documentation should be usable as help for key-users/consultant/technical, directly from "ofbiz applications".

> - Branding: A new website, activities on social media, success stories
> (updating), references, etc ...
>
> The reason I recommend the above strategic initiatives is that they are
> relatively easy and most community members can contribute to which would
> provide great value by leveraging the help of as many people as we can.
>
> Thoughts?
>
> Cheers,
>
> Taher Alkhateeb
>
> On Mon, Nov 28, 2016 at 1:35 PM, Sharan Foga <[hidden email]> wrote:
>
>> There was a bit that I missed - and this is a common thing that keeps
>> coming back up when we get together and talk:
>>
>> OFBiz could deliver more than one product. We could have more than one
>> product active at the same time e.g
>>
>>    - Framework with applications
>>    - Advanced UI but without all features
>>    - Advanced features but with the poor UI
>>
>> This is also something that we could think about for the high level
>> strategy.
>>
>> Thanks
>> Sharan
>>
>> On 2016-11-28 11:08 (+0100), "Sharan Foga"<[hidden email]> wrote:
>>> Hi Everyone
>>>
>>> One of the topics that came up during the brainstorming in Seville was
>> that the project desperately needs a clear strategy and roadmap.
>>>
>>> Benefits:
>>> - A strategy will provide a clear path for people to follow
>>> - A strategy will allow us to set goals / milestones and metrics about
>> progress
>>>
>>> In past maybe we have tried to do too much (tried to do it all at once -
>> which is why we find it h ard to focus).
>>>
>>> - One suggestion was to set a maximum of 3 goals and then work only on
>> these. To define these goals we need to look at what is the most important
>> thing that we want to achieve - and base them on that.
>>> - Another suggestion was that the most important thing for the project
>> is driving adoption. If this is true then what are the key blockers that
>> stop user adoption of OFBiz? (the UI!)
>>> - Suggestion to organise / setup teams from the community that focus on
>> specific areas (e.g. workgroups) - this could really help progress
>>>
>>> So to get the discussion started:
>>>
>>> 1. Do people agree that the project needs to focus on driving adoption?
>>> 2. Do people think that the UI is one of the key things that stops this
>> ? (If, not then please include what do you think is)
>>> 3. What goals could we set?
>>> 4. Are people interested in working in workgroups, to focus on specific
>> areas (or goals)?
>>>
>>> (I know there are some ideas/work around the UI going on, but I will
>> post the Seville details and notes about that in separate discussion
>> thread.)
>>>
>>> Thanks
>>> Sharan
>>>
>>>
>>
>

[Nicolas Malin-2]

Hi all,

Le 28/11/2016 à 22:43, Taher Alkhateeb a écrit :

> Hi Sharan,
>
> Thank you for starting this important topic. OFBiz definitely needs
> strategic objectives and a sense of direction. To try to formulate a
> strategy, I would suggest perhaps we highlight where I think OFBiz delivers
> value and where it does not, and based on that provide a few suggestions on
> moving forward.
>
> OFBiz main value proposition
> -------------------------------------------
> - A very robust domain model based on the data model resource book.
> - A library of services to control and manipulate the data model.
> - A DSL that hides and abstracts away the complexity of everything
> (services, entities, widgets, routing, etc...) and makes it easy for
> adopters to provide value quickly.
> - A business automation suite.

Agree nothing to add
> What OFBiz is not (yet?)
> ------------------------------------
> Currently OFBiz may provide some of the below, but it is not the main value
> proposition.
>
> - A web framework
> - A general purpose programming environment
> - An ERP system ready for immediate use by business owners (not geared for
> end-users)
Yes the best hunting area for OFBiz is create a business application
quickly but permanently. So we don't need to focus on your different
point because too many project work as well on each of them
Our strong is on the business automation suite : coherence on each
element to realize business application not to create a business
application.

>
> Where should we focus?
> -----------------------------------
> If you agree with the above assessment on OFBiz's value proposition, then I
> think we need to focus our limited resources and efforts and utilize the
> help of the community where it provides the highest value for effort. To
> start this discussion I suggest the list of below strategic objectives to
> try and move forward over the next 1-2 years at which time we can review
> and amend the strategy:
>
> - UI redesign: I think the user interface is one of the weakest points in
> our project and is probably the most critical item for adoption because at
> the end this is what people _see_. Having non-technical people download
> OFBiz, fire it up and start using it immediately without the intervention
> of a consultant or a developer is key to bigger adoption. Bigger adoption
> in turn leads to a more thriving community and business built around OFBiz.
> Hence we need a fully redesigned user interface that is not a reference for
> developers but rather a usable interface immediately to someone who needs
> an ERP platform for their business.

Capitain ! The work is in progress, the earth is far but the sea is
quite and the sun shine :)

First refactoring the screen engine base
Second define new best practice for screen development
Third create a tiny demo application for end user

Oh you give me an idea for the adoption. When a user download ofbiz he
need to run a gradle target present on the documentation.
So we can add two new targets :
  * ./gradle simpleUse that enable the tiny demonstration application
and disable all application component (for the webapp)
  * ./gradle advancedUse that enable all application component.

We just need change the documentation to :
for run ofbiz just : ./gradle simpleUse loadDefault ofbiz
If you are a developer you can do : ./gradle advancedUse loadDefault ofbiz

>
> - Documentation: We have a lot of documentation resources, but they are
> unorganized, scattered and outdated. Documentation is another key driver of
> adoption and I think a significant amount of work needs to go into
> organizing and cleaning up our documentation. We need a unified resource
> for getting information. I really like for example the documentation of
> Gradle found in docs.gradle.org which breaks things down beautifully into a
> user guide, a DSL reference and JavaDocs with very good sub-categorization
> and hyperlinks between everything.
dream, but it's not my strong ^^
>
> - Branding: A new website, activities on social media, success stories
> (updating), references, etc ...
>
> The reason I recommend the above strategic initiatives is that they are
> relatively easy and most community members can contribute to which would
> provide great value by leveraging the help of as many people as we can.
>
> Thoughts?
I wil try to follow you Taher :)

Cheers,
Nicolas

>
> Cheers,
>
> Taher Alkhateeb
>
> On Mon, Nov 28, 2016 at 1:35 PM, Sharan Foga <[hidden email]> wrote:
>
>> There was a bit that I missed - and this is a common thing that keeps
>> coming back up when we get together and talk:
>>
>> OFBiz could deliver more than one product. We could have more than one
>> product active at the same time e.g
>>
>>     - Framework with applications
>>     - Advanced UI but without all features
>>     - Advanced features but with the poor UI
>>
>> This is also something that we could think about for the high level
>> strategy.
>>
>> Thanks
>> Sharan
>>
>> On 2016-11-28 11:08 (+0100), "Sharan Foga"<[hidden email]> wrote:
>>> Hi Everyone
>>>
>>> One of the topics that came up during the brainstorming in Seville was
>> that the project desperately needs a clear strategy and roadmap.
>>> Benefits:
>>> - A strategy will provide a clear path for people to follow
>>> - A strategy will allow us to set goals / milestones and metrics about
>> progress
>>> In past maybe we have tried to do too much (tried to do it all at once -
>> which is why we find it h ard to focus).
>>> - One suggestion was to set a maximum of 3 goals and then work only on
>> these. To define these goals we need to look at what is the most important
>> thing that we want to achieve - and base them on that.
>>> - Another suggestion was that the most important thing for the project
>> is driving adoption. If this is true then what are the key blockers that
>> stop user adoption of OFBiz? (the UI!)
>>> - Suggestion to organise / setup teams from the community that focus on
>> specific areas (e.g. workgroups) - this could really help progress
>>> So to get the discussion started:
>>>
>>> 1. Do people agree that the project needs to focus on driving adoption?
>>> 2. Do people think that the UI is one of the key things that stops this
>> ? (If, not then please include what do you think is)
>>> 3. What goals could we set?
>>> 4. Are people interested in working in workgroups, to focus on specific
>> areas (or goals)?
>>> (I know there are some ideas/work around the UI going on, but I will
>> post the Seville details and notes about that in separate discussion
>> thread.)
>>> Thanks
>>> Sharan
>>>
>>>

[Nicolas Malin-2]

Le 29/11/2016 à 20:21, Olivier Heintz a écrit :

> Le 28/11/2016 à 22:43, Taher Alkhateeb a écrit :
>> >Hi Sharan,
>> >
>> >Thank you for starting this important topic. OFBiz definitely needs
>> >strategic objectives and a sense of direction. To try to formulate a
>> >strategy, I would suggest perhaps we highlight where I think OFBiz delivers
>> >value and where it does not, and based on that provide a few suggestions on
>> >moving forward.
>> >
>> >OFBiz main value proposition
>> >-------------------------------------------
>> >- A very robust domain model based on the data model resource book.
>> >- A library of services to control and manipulate the data model.
>> >- A DSL that hides and abstracts away the complexity of everything (services, entities, widgets, routing, etc...)
>> >    and makes it easy for adopters to provide value quickly.
>    - A plugin system AND a plugin strong organization

I'm agree to the plugin system but not on plugin strong organization.

Offer good tools to realize some plugin is different that offer a
plateform to deploy and manage a plugin store
We need to concentrate the effort on the core, have some official plugin
for example, special case and define best pratice.

We are to few to maintain the ofbiz core so for me manage a plugin store
is more for integrator company or another dedicate community with
different rules.

Cheers,
Nicolas

[Shi Jinghai-3]

Well done Olivier!

Personally, I think we should consider Hadoop in OFBiz roadmap. In the past 10 years, I have to agree, Hadoop is the most important progress, and it's from Apache.

-----邮件原件-----
发件人: Olivier Heintz [mailto:[hidden email]]
发送时间: 2016年11月30日 1:33
收件人: [hidden email]
主题: Re: [DISCUSSION] Defining an OFBiz Project Strategy

Answers are in-line

Le 28/11/2016 à 11:08, Sharan Foga a écrit :
> Hi Everyone
>
> One of the topics that came up during the brainstorming in Seville was that the project desperately needs a clear strategy and roadmap.
>

....

>
> So to get the discussion started:
>
> 1. Do people agree that the project needs to focus on driving adoption?
+10
but who are ours target :
  1) ERP services company (consultant or/and technical employees with ERP knowledge)
  2) or IT services company ( SME )
  3) or end user (manager who need a ERP)
  or both ;-)

( it's ordered in my point of view )

> 2. Do people think that the UI is one of the key things that stops this ? (If, not then please include what do you think is)
+10
but maybe the OOTB UI is not the same than the more professional business application plugins.
First should be more fashionable that the second which could be more sober and practical (maybe only a theme difference)

> 3. What goals could we set?
Taher start to answer, I will complete...

> 4. Are people interested in working in workgroups, to focus on specific areas (or goals)?
My "contribution areas" are
- UI scenario Test
- documentation (for consultant or/and technical  with ERP knowledge )
- using plugin manager to create small function plugin
- saying if it's usable by a functional consultant ;-)

>
> (I know there are some ideas/work around the UI going on, but I will post the Seville details and notes about that in separate discussion thread.)
>
> Thanks
> Sharan
>
>

[Jacques Le Roux]

Le 29/11/2016 à 22:12, Nicolas Malin a écrit :

>
> Le 29/11/2016 à 20:21, Olivier Heintz a écrit :
>> Le 28/11/2016 à 22:43, Taher Alkhateeb a écrit :
>>> >Hi Sharan,
>>> >
>>> >Thank you for starting this important topic. OFBiz definitely needs
>>> >strategic objectives and a sense of direction. To try to formulate a
>>> >strategy, I would suggest perhaps we highlight where I think OFBiz delivers
>>> >value and where it does not, and based on that provide a few suggestions on
>>> >moving forward.
>>> >
>>> >OFBiz main value proposition
>>> >-------------------------------------------
>>> >- A very robust domain model based on the data model resource book.
>>> >- A library of services to control and manipulate the data model.
>>> >- A DSL that hides and abstracts away the complexity of everything (services, entities, widgets, routing, etc...)
>>> >    and makes it easy for adopters to provide value quickly.
>>    - A plugin system AND a plugin strong organization
> I'm agree to the plugin system but not on plugin strong organization.
>
> Offer good tools to realize some plugin is different that offer a plateform to deploy and manage a plugin store
> We need to concentrate the effort on the core, have some official plugin for example, special case and define best pratice.
>
> We are to few to maintain the ofbiz core so for me manage a plugin store is more for integrator company or another dedicate community with different
> rules.

As I suggested elsewhere, as delivered by the community, this could be as simple as a Maven repository on our demo server and a wiki page to reference
plugins. New plugins would be asked to be put in the Maven repo by creating Jira issues.
Anyway the 1st step is technical: we need to complete the plugins mechanisms to install from a Maven repo not on localhost. I must say I did not test
the current feature yet nor looked at what enhancing it entails...

Jacques

>
> Cheers,
> Nicolas
>

[Sharan-F]

I've added a comment inline

On 30/11/16 10:27, Jacques Le Roux wrote:

>
>
> Le 29/11/2016 à 22:12, Nicolas Malin a écrit :
>>
>> Le 29/11/2016 à 20:21, Olivier Heintz a écrit :
>>> Le 28/11/2016 à 22:43, Taher Alkhateeb a écrit :
>>>> >Hi Sharan,
>>>> >
>>>> >Thank you for starting this important topic. OFBiz definitely needs
>>>> >strategic objectives and a sense of direction. To try to formulate a
>>>> >strategy, I would suggest perhaps we highlight where I think OFBiz
>>>> delivers
>>>> >value and where it does not, and based on that provide a few
>>>> suggestions on
>>>> >moving forward.
>>>> >
>>>> >OFBiz main value proposition
>>>> >-------------------------------------------
>>>> >- A very robust domain model based on the data model resource book.
>>>> >- A library of services to control and manipulate the data model.
>>>> >- A DSL that hides and abstracts away the complexity of everything
>>>> (services, entities, widgets, routing, etc...)
>>>> >    and makes it easy for adopters to provide value quickly.
>>>    - A plugin system AND a plugin strong organization
>> I'm agree to the plugin system but not on plugin strong organization.
>>
>> Offer good tools to realize some plugin is different that offer a
>> plateform to deploy and manage a plugin store
>> We need to concentrate the effort on the core, have some official
>> plugin for example, special case and define best pratice.
>>
>> We are to few to maintain the ofbiz core so for me manage a plugin
>> store is more for integrator company or another dedicate community
>> with different rules.
>
> As I suggested elsewhere, as delivered by the community, this could be
> as simple as a Maven repository on our demo server and a wiki page to
> reference plugins. New plugins would be asked to be put in the Maven
> repo by creating Jira issues.
> Anyway the 1st step is technical: we need to complete the plugins
> mechanisms to install from a Maven repo not on localhost. I must say I
> did not test the current feature yet nor looked at what enhancing it
> entails...
>
> Jacques

If I remember correctly ,when we asked the question to the community
regarding addons/plug-ins, the consensus was that they wanted to project
itself manage official approved plug-ins (so to setup an official
repository for those) Looking at the discussions we are having now, some
of our standard components may technically become plug-ins (and we've
already said that the specialpurpose ones will be). I wouldn't be happy
for the community to have to rely on service providers to provide what
should be standard functions / components or plug-ins.

So I would be in favour of something like Jacques is proposing that we
have an official project repo for plug-ins.

Thanks
Sharan


>
>>
>> Cheers,
>> Nicolas
>>
>

[Jacopo Cappellato-5]

On Wed, Nov 30, 2016 at 10:40 AM, Sharan Foga <[hidden email]> wrote:

> [...] I wouldn't be happy for the community to have to rely on service
> providers to provide what should be standard functions / components or
> plug-ins.
>
> So I would be in favour of something like Jacques is proposing that we
> have an official project repo for plug-ins.
>

We could look at the feasibility (from an infra and a legal perspective) of
publishing our plugins to:
http://repo.maven.apache.org/maven2

Jacopo

[Shi Jinghai-3]

+1 to use repo.maven.apache.org if possible.

-----邮件原件-----
发件人: Jacopo Cappellato [mailto:[hidden email]]
发送时间: 2016年11月30日 17:54
收件人: [hidden email]
主题: Re: [DISCUSSION] Defining an OFBiz Project Strategy

On Wed, Nov 30, 2016 at 10:40 AM, Sharan Foga <[hidden email]> wrote:

> [...] I wouldn't be happy for the community to have to rely on service
> providers to provide what should be standard functions / components or
> plug-ins.
>
> So I would be in favour of something like Jacques is proposing that we
> have an official project repo for plug-ins.
>

We could look at the feasibility (from an infra and a legal perspective) of publishing our plugins to:
http://repo.maven.apache.org/maven2

Jacopo

[Jacques Le Roux]

Le 30/11/2016 à 10:54, Jacopo Cappellato a écrit :

> On Wed, Nov 30, 2016 at 10:40 AM, Sharan Foga <[hidden email]> wrote:
>
>> [...] I wouldn't be happy for the community to have to rely on service
>> providers to provide what should be standard functions / components or
>> plug-ins.
>>
>> So I would be in favour of something like Jacques is proposing that we
>> have an official project repo for plug-ins.
>>
> We could look at the feasibility (from an infra and a legal perspective) of
> publishing our plugins to:
> http://repo.maven.apache.org/maven2
>
> Jacopo
>

If I understand well, this Maven repo is only for ASF internal use, right? (though I see http://repo.maven.apache.org/maven2/external/atlassian/ but I
guess it's a matter of agreement with infra and maybe Maven teams?)
If it's the case, that's quite an idea Jacopo, less work for us :)
Will you ask?

Jacques

[Jacopo Cappellato-5]

On Wed, Nov 30, 2016 at 11:26 AM, Jacques Le Roux <
[hidden email]> wrote:

> If I understand well, this Maven repo is only for ASF internal use, right?
> (though I see http://repo.maven.apache.org/maven2/external/atlassian/ but
> I guess it's a matter of agreement with infra and maybe Maven teams?)
> If it's the case, that's quite an idea Jacopo, less work for us :)
> Will you ask?
>
> Jacques
>

I am not sure it is only for ASF projects, probably not.
But, since one of the requirements by the ASF for distributing official
releases (and afaik each plugin will be technically a release) is that the
release packages must be available from ASF owned infra, the above should
do the trick.
I would prefer to wait before asking any question until we have a better
knowledge of our intentions, requirements and architecture; in the meantime
we can explore more in this and other directions.

Jacopo

[taher]

Folks, I need to note that the plugins issue is simple and does not need
that much effort.

Instead of firing up an entire maven repository we can just create source
branches for the plugins, and publish to JCenter with an OFBiz account.
This is a simpler faster way moving forward. Firing up an entire maven
repository just for a few packages does not seem necessary to me at this
time. This step might be necessary in the future if we get a huge volume of
plugins or something like that.

So a simple naming convention for the plugin versions combined with hosting
the source code in branches is enough to get us started.

For example:

- For trunk: We can create a task called ./gradlew pullOfficialPlugin
-PpluginId=Whatever. This task will pull the source code from subversion or
whatever and just put it in /specialpurpose
- For releases 16.11: ./gradlew pullPlugin
-PdependencyId='org.apache.ofbiz.plugin.release16.11:myplugin:1.0.0'

So I'm rooting for simplicity, I suggest not to over-engineer too quickly
before testing all aspects of the plugin system. In the end, the OFBiz
plugin of a certain version in a certain release is really just a tag in
subversion or something like that. It's not a big deal to publish it to
JCenter or similar repository providers because we will always have that
exact copy available in our source code system.

Cheers,

Taher Alkhateeb

On Wed, Nov 30, 2016 at 1:37 PM, Jacopo Cappellato <
[hidden email]> wrote:

> On Wed, Nov 30, 2016 at 11:26 AM, Jacques Le Roux <
> [hidden email]> wrote:
>
> > If I understand well, this Maven repo is only for ASF internal use,
> right?
> > (though I see http://repo.maven.apache.org/maven2/external/atlassian/
> but
> > I guess it's a matter of agreement with infra and maybe Maven teams?)
> > If it's the case, that's quite an idea Jacopo, less work for us :)
> > Will you ask?
> >
> > Jacques
> >
>
> I am not sure it is only for ASF projects, probably not.
> But, since one of the requirements by the ASF for distributing official
> releases (and afaik each plugin will be technically a release) is that the
> release packages must be available from ASF owned infra, the above should
> do the trick.
> I would prefer to wait before asking any question until we have a better
> knowledge of our intentions, requirements and architecture; in the meantime
> we can explore more in this and other directions.
>
> Jacopo
>

[Jacopo Cappellato-5]

On Wed, Nov 30, 2016 at 11:52 AM, Taher Alkhateeb <
[hidden email]> wrote:

> [...]
> Instead of firing up an entire maven repository we can just create source
> branches for the plugins, and publish to JCenter with an OFBiz account.
> This is a simpler faster way moving forward. [...]


Hi Taher,

I am not sure I understand what you mean with "firing up a maven repo" but
my proposal was not that: instead I was proposing to explore the
possibility to use the existing official repo offered by the ASF to
distribute Maven plugins.
Sharan and Jacques had a quick chat today with some Infra guys to explore
the options available (I will let them add more info if I am missing
something).

In my opinion the following points should be considered:
* each plugin created by the OFBiz project is actually a "product" and
should be treated as a product
* as an ASF project/community we can only distribute products that we
create and publish/release with a formal vote; the OFBiz project cannot
distribute code that is not formally approved/released
* the primary distribution channel for the products published by the OFBiz
project must be owned/managed by the ASF Infra; it is ok to distribute the
OFBiz project's products using different alternative channels (like the
mirrors release network leveraged by all the ASF projects) provided that
the primary channel is owned by the ASF.

All the above doesn't apply to third party plugins: for them there are no
restrictions as they are not distributed by the OFBiz project. Users can
download them, possibly using the OFBiz plugin API, and third party
companies can create them and upload to public/private repositories as they
like.
As an ASF project we will not endorse, promote, approve, distribute or
release third-party plugins; but as a project we could facilitate and
encourage third party companies to create/publish/promote their plugins by
improving the tools (e.g. the plugin API) that enable end users to install
them in their OFBiz instance.

Jacopo

[taher]

Hi jacopo,

I see, all good points on tbe compliance side of things with ASF
guidelines. I was actually replying to a suggestion by Jacques to create a
new maven repository in a VM or something like that which sounded like too
much work to me. So your suggestion of just using an existing ASF
infrastructure seems like a good middle solution.

Cheers,

Taher Alkhateeb

On Nov 30, 2016 3:44 PM, "Jacopo Cappellato" <
[hidden email]> wrote:

On Wed, Nov 30, 2016 at 11:52 AM, Taher Alkhateeb <
[hidden email]> wrote:

> [...]
> Instead of firing up an entire maven repository we can just create source
> branches for the plugins, and publish to JCenter with an OFBiz account.
> This is a simpler faster way moving forward. [...]


Hi Taher,

I am not sure I understand what you mean with "firing up a maven repo" but
my proposal was not that: instead I was proposing to explore the
possibility to use the existing official repo offered by the ASF to
distribute Maven plugins.
Sharan and Jacques had a quick chat today with some Infra guys to explore
the options available (I will let them add more info if I am missing
something).

In my opinion the following points should be considered:
* each plugin created by the OFBiz project is actually a "product" and
should be treated as a product
* as an ASF project/community we can only distribute products that we
create and publish/release with a formal vote; the OFBiz project cannot
distribute code that is not formally approved/released
* the primary distribution channel for the products published by the OFBiz
project must be owned/managed by the ASF Infra; it is ok to distribute the
OFBiz project's products using different alternative channels (like the
mirrors release network leveraged by all the ASF projects) provided that
the primary channel is owned by the ASF.

All the above doesn't apply to third party plugins: for them there are no
restrictions as they are not distributed by the OFBiz project. Users can
download them, possibly using the OFBiz plugin API, and third party
companies can create them and upload to public/private repositories as they
like.
As an ASF project we will not endorse, promote, approve, distribute or
release third-party plugins; but as a project we could facilitate and
encourage third party companies to create/publish/promote their plugins by
improving the tools (e.g. the plugin API) that enable end users to install
them in their OFBiz instance.

Jacopo

[Pierre Smits]

I am looking forward to seeing a strategy in place, before any *new* code
will be added to the code base.

Best regards,

Pierre Smits

ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Wed, Nov 30, 2016 at 1:56 PM, Taher Alkhateeb <[hidden email]
> wrote:

> Hi jacopo,
>
> I see, all good points on tbe compliance side of things with ASF
> guidelines. I was actually replying to a suggestion by Jacques to create a
> new maven repository in a VM or something like that which sounded like too
> much work to me. So your suggestion of just using an existing ASF
> infrastructure seems like a good middle solution.
>
> Cheers,
>
> Taher Alkhateeb
>
> On Nov 30, 2016 3:44 PM, "Jacopo Cappellato" <
> [hidden email]> wrote:
>
> On Wed, Nov 30, 2016 at 11:52 AM, Taher Alkhateeb <
> [hidden email]> wrote:
>
> > [...]
> > Instead of firing up an entire maven repository we can just create source
> > branches for the plugins, and publish to JCenter with an OFBiz account.
> > This is a simpler faster way moving forward. [...]
>
>
> Hi Taher,
>
> I am not sure I understand what you mean with "firing up a maven repo" but
> my proposal was not that: instead I was proposing to explore the
> possibility to use the existing official repo offered by the ASF to
> distribute Maven plugins.
> Sharan and Jacques had a quick chat today with some Infra guys to explore
> the options available (I will let them add more info if I am missing
> something).
>
> In my opinion the following points should be considered:
> * each plugin created by the OFBiz project is actually a "product" and
> should be treated as a product
> * as an ASF project/community we can only distribute products that we
> create and publish/release with a formal vote; the OFBiz project cannot
> distribute code that is not formally approved/released
> * the primary distribution channel for the products published by the OFBiz
> project must be owned/managed by the ASF Infra; it is ok to distribute the
> OFBiz project's products using different alternative channels (like the
> mirrors release network leveraged by all the ASF projects) provided that
> the primary channel is owned by the ASF.
>
> All the above doesn't apply to third party plugins: for them there are no
> restrictions as they are not distributed by the OFBiz project. Users can
> download them, possibly using the OFBiz plugin API, and third party
> companies can create them and upload to public/private repositories as they
> like.
> As an ASF project we will not endorse, promote, approve, distribute or
> release third-party plugins; but as a project we could facilitate and
> encourage third party companies to create/publish/promote their plugins by
> improving the tools (e.g. the plugin API) that enable end users to install
> them in their OFBiz instance.
>
> Jacopo
>

[Nicolas Malin-2]

Hello,
Le 30/11/2016 à 13:44, Jacopo Cappellato a écrit :

> On Wed, Nov 30, 2016 at 11:52 AM, Taher Alkhateeb <
> [hidden email]> wrote:
>
>> [...]
>> Instead of firing up an entire maven repository we can just create source
>> branches for the plugins, and publish to JCenter with an OFBiz account.
>> This is a simpler faster way moving forward. [...]
>>
>> [...]
>>
>> In my opinion the following points should be considered:
>> * each plugin created by the OFBiz project is actually a "product" and
>> should be treated as a product
>> * as an ASF project/community we can only distribute products that we
>> create and publish/release with a formal vote; the OFBiz project cannot
>> distribute code that is not formally approved/released
>> * the primary distribution channel for the products published by the OFBiz
>> project must be owned/managed by the ASF Infra; it is ok to distribute the
>> OFBiz project's products using different alternative channels (like the
>> mirrors release network leveraged by all the ASF projects) provided that
>> the primary channel is owned by the ASF.
>>
>> All the above doesn't apply to third party plugins: for them there are no
>> restrictions as they are not distributed by the OFBiz project. Users can
>> download them, possibly using the OFBiz plugin API, and third party
>> companies can create them and upload to public/private repositories as they
>> like.
>> As an ASF project we will not endorse, promote, approve, distribute or
>> release third-party plugins; but as a project we could facilitate and
>> encourage third party companies to create/publish/promote their plugins by
>> improving the tools (e.g. the plugin API) that enable end users to install
>> them in their OFBiz instance.
>>
>> Jacopo

:) you resume my mind Jacopo, it's exaclty what I think !

Nicolas

[Olivier.heintz]

Le 29/11/2016 à 22:12, Nicolas Malin a écrit :
>
> Le 29/11/2016 à 20:21, Olivier Heintz a écrit :
>> Le 28/11/2016 à 22:43, Taher Alkhateeb a écrit :
>>>> Hi Sharan,
>>>>
>>>> Thank you for starting this important topic. OFBiz definitely needs

>>>> ....

model.

>>>> - A DSL that hides and abstracts away the complexity of everything (services, entities, widgets, routing, etc...)
>>>>    and makes it easy for adopters to provide value quickly.
>>    - A plugin system AND a plugin strong organization
> I'm agree to the plugin system but not on plugin strong organization.
>
> Offer good tools to realize some plugin is different that offer a
> plateform to deploy and manage a plugin store
> We need to concentrate the effort on the core, have some official plugin
> for example, special case and define best pratice.
>
> We are to few to maintain the ofbiz core so for me manage a plugin store
> is more for integrator company or another dedicate community with
> different rules.

my formulation was too short and so not clear, << plugin strong organization >>
would have of the being something like
<< plugin metadata and some rules to be able to have efficient documentation to find easily what plugin install for the choosing function >>
and nothing about repository management, I apologize for the misunderstanding.

But I immediately add the remark done by sharan, taher, ... It's not a current discussion subject for today.
We should have first have some plugin available. (I'm currently testing the webdriver-tools addon migrated as a plugin)



>
> Cheers,
> Nicolas
>