Access to add and change pages is restricted. See: https://cwiki.apache.org/confluence/display/OFBIZ/Wiki+access

Notes from the Meeting:

OFBiz Workshop Session at Apachecon EU 2014

Attendees:

Jacopo Capellato, Olivier Heintz, Catherine Heintz, Pierre Smits, Nicolas Malin, Anahita Goljahani Gil Portenseigne, Youssef Khaye, Sharan Foga

Location:

Corinthia Hotel, Budapest

Time: 14.00 - 17.00 (Pierre Smits left at 16.00)

Workshop Objectives

  • To understand what OFBiz means to everyone
  • To gain a common view of OFBiz and the way ahead for the future
  • To discuss any OFBiz related topics

Background

The meeting started with Sharan giving a quick overview of some key areas that she thought needed to be discussed. These were

  • Project Vision: Do we all have the same vision and understanding of OFBiz and where it is going ? / Which direction do they want to project to go in? / What do they see as important?
  • Project Strategies: What strategies are currently in place? (e.g Communication, Risk, Issue Management etc)
  • Planning: Is there a Roadmap or High Level Plan?
  • Main Areas of Focus: What is the overall planare the main areas the project is working on
  • Organisation: How is the project being managed, controlled and organised

Discussion: Pariticipant's Current and Future Project Vision

Nicolas' vision of OFBiz was that it was an ERP but also a Application development framework that was very strong on integration

Pierre's vision of OFBiz was that it was solution framework that was scalable. It provides a set of solutions that are not all complete. This means that we need to improve what we have to bring them up to a common standard. (NOTE: Pierre has added an additonal comment below expanding on this and other topics that were touched on during the discussion)

Jacopo's vision of OFBiz came from 3 distinct areas.

  1. The first was as an OFBiz user where he wanted to see a more modern framework that give the benefits such as flexibility, speed and efficiency. It would also make it easier to customise applications.
  2. The second was an OFBiz committer where he wanted OFBiz to be simpler to manage and less dependent on external projects
  3. The third was as part of the OFBiz PMC where he wanted to ensure that the OFBiz brand wasnt being misued. Also that we needed to define some strategies for general OFBiz users and the community . One example mentioned was a roadmap to upgrade from one version to another. (NOTE: It was noted that this could be a potential opportunity for someone to build an OFBiz upgrade tool that could be extremely useful to the community). He also wanted it to enable companies to contribute back to the project.

Anahita spoke from her experience as a new OFBiz user and said that she found it difficult to learn and get started with OFBiz. There seemed a lack of logic and organisation of information and it took patience and perserverance to get familiar with OFBiz. Once you are familiar with it then the idea behind the product is amazing and the potential is huge. She found the mailing lists really helpful and the community willing to take care of any patches she submitted.

Gil's vision of OFBiz also covered several areas:

  1. The first was that it was a technical development framework that has application components. The applications are examples and the goal was not to deliver an 'out of the box' solution. Each implementation needs to be deliver a solution for the customer.
  2. The second was that we need to ensure that the framework technology and applications need to be kept up to date (eg. refactoring where necessary, security etc)
  3. The third area was improved communication within the project so that people can see what is in progress and what is planned.
  4. The fourth area was to see improved documentation on the wiki and within the OFBiz product itself (so the online application help)
  5. The final area was to improve OFBiz marketing and also setup a simple end user demo

Olivier's vision was that OFBiz was an ERP and a set of application development tools.

  1. In the future he would like to see OFBiz having multiple distributions all based around a common base framework or "kernel".
  2. Each distribution would be made up of the common kernel and specific applications (e.g based on industry, sector or country). The common kernel would be the same for all providers and so could be common marketing materials could be used.
  3. He also wanted to see if the community could setup or link contributors to a particular OFBiz area (e.g. mini subject matter experts). These people could then give an opinion on processes , potential coding improvements or changes to that specific area.

Catherine's feedback was from an end user perspective. She currently uses OFBiz to capture requirements and process orders and invoices.

  1. She believes that very few customers want an OFBiz "out of the box" solution and to make a real business solution more customised or customer specific functionality will need to be added.
  2. She thinks the current community is very technically focussed and this needs to be balanced with business people so the project needs to attract business users. She thinks that project communication shouldnt be restricted to just the mailing lists (as having this face to face meeting is really good and we can easily discuss things and respond quickly).

Youssef's vision was that OFBiz was a framework used to build solutions because not many companies could use OFBiz "out of the box".

  1. Based on his experience he thought that trying to make OFBiz an "out of the box" solution that could work for everyone will be too hard and that in future we should focus on using these tools to build good business solutions
  2. He also saw it as important that the applications that are there need to include contextual help and integrated testing tools across the complete global process.
  3. He thinks that we need to bring more business users into the project and that there are not many active business users on the current mailing lists. OFBiz is a business product so we should have a mix of business and technical users across the community.

Discussion : Original Project Vision:

Jacopo mentioned that the original vision of the OFBiz was:

to have an Application Development Framework with a Data Model and some core skeleton applications with CRUD (create, read, update and delete) services that would be customised per implementation.

Over the years because of contributions from the community these 'skeleton' applications have become more and more complete. A User Interface was added and currently we think that we have the situation where OFBiz as an integrated ERP can only be used "out of the box" for specific cases.

 

As a project we need to look at what where we want the project to go in the future. Do we tidy up the applications to make them more business friendly? Do we standardise the applications to create a core set that can be customised for each industy or sector? Whatever we decide does this mean that we need to review the project vision and see if it needs to be updated.

Miscellaneous Discussions

Project Strategies

Sharan talked about the different strategies that projects generally have in place that she wanted to investigate for the project.

Planning and Project Roadmap

  • Currently there doesnt seem to be a roadmap or high level project plan in place
  • Work is being done on a task by task basis that is triggered by a reported issue or maintenance request (e.g. Tomcat upgrade etc)
  • An overall plan will help with communications to the community, give the project future direction and also give focus to work efforts
  • The planning could be broken down into the key areas (e.g. applications, maintenance/housekeeping, release planning, security, etc) 
  • We would need to investigate the Roadmap and.or Agile functionality that exists as perhaps it could be used to help manage the project

Communication

  • Curently the mailing lists, website and wiki are the main communication tools. Jacopo as PMC chair prepares project reports to the ASF on a regular basis.
  • We want to encourage more business users into the community so need to tailor the website and wiki.
  • We have found that meeting in person at events such as Apachecon have been really good in building community as well as communication links. What other

Risk Management

  • Risk Management strategies are used to identify, assess and react to any risks that impact the project. Risks can cover a range of areas including doing or not doing something. I think we need a strategy in place to deal with things that will impact the project. We need to identify them, assess them (because not all of them may cause a problems - some could be positive!), and then decide on how to react to them (this could something as simple as defining when to include it in a release or deciding that for the moment implementing something will cause more problems that it will solve).
  • Not sure that there is any risk management strategy currently in place
  • Currently OFBiz has a range of external dependencies that need to be maintained. Do we have someone allocated to keep a 'watching brief' for any retiring of a release that we are using, finding out about any new releases that we may have to implement at a future date
  • Does anyone assess the impact of not implementing a specific change or process for the project?
  • What is the project attitude to risk? (Does the project want to keep everything low risk because we need to be able to manage and conform to the Apache release process?)

Issue Management

  • All project issues are managed in JIRA
  • Users need to create a profile and can report an issue or submit a patch
  • Committers assign themselves to an issue and then follow it through to resolution (normally this is either fixing the issues themselves or applying a submitted patch)
  • Reports and statistics are available

Task Management

  • Future tasks or requests for improvements are also managed through JIRA

Marketing

  • No real marketing strategy in place
  • Need to aim to attract more business users
  • Look at tools available, may need to link this to communication strategy and also branding management

External Dependencies

There was a brief discussion about external dependencies (i.e. on other projects or functionality) and how they have been implemented in OFBiz. The aim is to have a flexible framework that works with the Apache release process. Any external product needs to be maintained and when a release is made the project PMC are responsible for signing the release which ensures that any external dependencies willl be correctly integrated and maintained for the release.

We currently have cases where some external products should not have been implemented to form part of release but can be made available if users want to integrate them into an OFBiz release.

Technical vs. Business Knowledge

A key point was raised that some of the people classed as technical (i.e developers or integrators) in the project also have very solid business experience too. We need to capture information about who knows about which applications and business processes so that we can encourage them to become part of our team of 'mini subject matter experts'.

Consolidated Ideas and Draft Proposals

These consolidated ideas / proposals are to be raised for on the mailing lists for community discussion and feedback. They will only be implemented if the community consensus is received.

  1. Proposal: Tidy up OFBiz Technical Framework or "kernel"

    1. e.g identify what needs to be tidied up and assign the work out to be done

  2. Proposal: Define and implement a process to manage the code that has been cleaned out

    1. eg to a sandbox location so could be used by users who want to pick it up and use

  3. Proposal: Tidy or Clean up OFBiz Business Framework

    1.  (e.g. ensure business processes have a use case to describe the process and that can be used for validation)

  4. Proposal: Implement OFBiz in Application Documentation

    1. We have been using docbook but two other proposals mentioned
    2. Idea 1: Use SVNPUB: This is committer controlled but may be able to switch to setup a business user expert with write access. This means that the "mini subject matter experts" could easier maintain their specific areas.
    3. Idea 2: Wikipedia style documentation where a page linked within the OFBiz application page (e.g. using the '?') will link to the wiki. This is more open and non committer controlled. Means more people can contribute

  5. Proposal: External Dependencies Refactoring

    1. specific workstream on refactoring external dependencies

  6. Proposal: Build a Project Roadmap / High level plan

    1. This will be used to show details of releases and how they are supported, details of work in development, updates planned.
    2. We need to look at tools available eg. JIRA has options to do planning and roadmap, also look for Roadmap and planning info on the Wiki as may be able to collate

  7. Proposal: Ensure Business Success stories are documented

    1. This is valuable information for potential users. We could ask users  to add their stories and also get them to list the applications used / implemented.
    2. Existing policy is that there should be no direct links from OFBiz website main pages so need to use the wiki. Investigate whether integraters are willing to share their client links and stories.

  8. Proposal: Marketing the OFBiz Demo to Business End Users

    1. Prepare an end user demo that can be based on roles (e.g accountant, HR manager, Order Clerk, Warehouse Manager etc).
    2. Link to user stories that can have a script or supporting documentation (e.g currently on main page there are no instructions about how to login to the demo just in case you are thrown out.
    3. Also default user if flexadmin which doesnt have all the permissions for all applications).

  9. Proposal: Build a set of Common Core OFBiz Marketing Material

    1. Put together some standard OFBiz marketing information that all integrators / users have access to.
    2. Integrators can then adapt it to suit their needs if required. Information could be white papers around supported industries etc.
    3. Will need to define what tool could be used to prepare the material as it needs to be accessible to a common audience. This is important as everyone will need to be able to edit it!

  10. Proposal: Housekeeping and Ongoing Maintenance

    1.  eg. Tomcat etc. Need to keep a watching brief on external products that are directly used by OFBiz and prepare a plan of when to integrate them

  11. Proposal: Establish a group of  "mini subject matter experts" covering business and technical

    1. i.e. dont have to be both but can be
    2. . Identify contributors and knowledge. Can refer to these people regarding their specific area

  12. Proposal: Work on a strategy to encourage more business users

  13. Proposal: Look at developing a full testing strategy

    1. Unit testing in isolation is not enough. We need to ensure there is an full end to end test flow

  14. Proposal: Actively Manage OFBiz branding and trademarks

    1. Need to review the process and contact sites that may be infringing on the OFBiz brand

Actions

ActionWhoDate OpenStatusDate Completed
Write up workshop notesSharan19/11/14Open26/11/14
Investigate using JIRA for managing the project roadmap and high level planSharan19/11/14Open 
Review and Approve meeting notesAll19/11/14Open26/11/14
     

 

  • No labels

9 Comments

  1. I see that there is something lost from what I said at the meeting to what is captured here. Maybe that is due to the speed at which I spoke, the surrounding noise. And not all that i would have brought to the table could be done, due my restrictions on time.

    What I said and intended to bring across is this:

    Project Vision

    This project started out and is still today a project that delivers both a framework to build applications upon and a feature set that delivers business functionality. The mission statement of the project in incubation and nowadays still describes it that way. Looking at what is in the works everybody can see that. That is the strength and success of this project and the achievement of its community members (past and present).

    We all must collaborate to keep it that way. The numbers of subscribers to our mailing lists and the numbers of participants in discussions from day to day shows that the project is more successful that other projects (even under the ASF umbrella) over the years and today. That we have had the diversity in talks at the Apachecon EU 2014 shows that we can bring together this diversity in viewpoints and approach. Given the attendance and the response shows that this diversity captures in the works of project is appreciated, again....

    Yes, us all keeping working together to improve the works from release to release is important. Neglecting issues (whatever kind) by all is detriment to the demise of the project. Luckily, we are not on that path. But we all must stay determined to keep the majority of functionality and contributors on board. Yes, we all have our individual viewpoints regarding what OFBiz is and what it could/should be. But remember, this is not a project of the minorit or working only for the consensus among the minority. This project was and is a project (as the ASF likes any project to be) achieving its goals for the majority, by the majority.

    If we allow the individual contributor to push forward his contribution, his commit without buy-in from the community, without consent than we slide on the slippery slop of alienation, of contraction. It is far better to take small steps forward together from release to release without losing community members, than to make great strides code wise and lose community wise.

    Diversity of Applicabilty

    The works of the project has this!. It provides a lot of services to develop business solutions upon. i provides base registers as Catalog, Party, WorkEffort and Financials (Accounting/OrderMgr) to extend business functionalities and use case. We offer solutions that cater to specific business domains (acocunting, agreements, content mgt, human resourses, manufacturing, marketing, sfa, warehousing, e-commerce, project mgr, etc). All this together is the ERP aspect of the works of the project.

    Now, some within our community may feel that one aspect should have more focus than another. Again, if this holds the consent of the majority who is to argue... But if it doesn't this will diminish diversity in the works, leading to diminished diversity in the community. Diminish the strength and adpotion of the project.

    Yes, we can do more with respect to the level of quality of the works (plan, documentation and code). And we are doing that, getting there. Slowly yes, but steadily.

    Organisational Aspects

    Our projects thrives by acceptance of the diversity in contributions that each contributing member brings to the table. Enabling each contributing member as much as possible will help to bring the result of our collaborations (releases and such) faster forward.

    This project depends on committers. This is how we are set up to collaborate. The persist the contributions into releases. This is a fact. But, the number of committers could be higher. More committers means more contributions persisted, more quality into the works (documentation and code). More shared workload.

    Some within our community feel that they must hold a tight reign over what the other member contributes. This is mostly felt when it comes to code, more specifically to contributions to the lowest stack (framework) and the base components (apps). These few, perceived through their expressions, work more on what holds their favor than on other elements of the works (code vs documentation, framework vs apps, e-commerce vs other domain solutions). That they must police what others do to maintain the high level of contributions. It can also be said that some like to work more with a few than with others, based on ............

    The organisation shouldn't be such that this policing by these few is required, or of consequence. Diversity in interest should be reflected at the levels of committers AND pmc. The responsibility of the project is the responsibility of all (or the majoriy at best) contributing participants.

    We have a lot of PMC members that aren't as active as they were. How can we uphold that they are representing the project? I believe that gets more difficult as the project progresses. We need to address this. Llife-time appointment as committer is in line with the Apache Way. It allows people to apply their individual schedules with respect to contributing to the project. Life-time appointment as PMC member is not in the best interest of all. The interests of people change over time. The PMC as an organisational institute of the project should reflect that. By having PMC members move in AND out on a more frequent basis, on votes and advice. And this should be maintained and upheld by the project's by-laws, policies and procedures.

     

     

  2. Hi Sharan, what do you put in "Risk Management" is it about security (understand vulnerability)?

  3. Hi Jacques - it's not only about security but about assessing the risk of doing or not doing something. I think we need a strategy in place to deal with things that will impact the project. We need to identify them, assess them (because not all of them may cause a problems - some could be positive!), and then decide on how to react to them (this could something as simple as defining when to include it in a release or deciding that for the moment implementing something will cause more problems that it will solve). I can put together an idea of what I'm thinking of.

  4. Your comment is interesting, thanks Pierre.

  5. I have reviewed the document and it looks good in general, thank you Sharan for the great work.

    There are some minor details about the summary of what I told during the meeting that should be slightly modified to better represent what I tried to express: but it is fine, I will have a chance to elaborate when we will discuss with the community.

    However I would like to clarify that the real value of the meeting (at least for me) was the fact that we could politely talk with each other without fighting and we had a chance to discuss and learn different point of views.

    We didn't come with an "approved" list of proposals, and this was not even the goal of the meeting, and I would like to make this concept clear: the community should not perceive that we agreed upon this and this and that the community should vote on them. The list of proposals is really an aggregated list with the proposal from different attendees.

    For example there are a few "proposals" that I am not sure about: for example the need to define a group of "mini subject expert matters": in my opinion the mailing list and the wiki are valid tools for an expert to help users in specific areas; over time, by contributing suggestions and helping answering questions, reviewing, writing documentation even a non-technical expert could "naturally" be considered an expert (and become a committer) without the need to formally assign a specific "area" to her/him.

    Also, I don't remember Pierre discussed most of the topics that are now in his comment as I would have provided my feedback on a few of them. For example, about the presence of inactive PMC members: this topic as been discussed in a few occasions (I initially also had the same idea of removing inactive members) but, because of the ASF rules, inactive PMC members (and committers) do not cause any trouble (i.e. majority within the PMC is never required for votes etc... only majority of actual votes)... in fact these rules were established by the ASF also to make sure that inactive PMC member do not slow down things. There are several ASF projects that have a long list of inactive PMC members/committers (and they don't even do the effort, as we do, to distinguish between inactive and active members) and they are doing just fine; in my opinion defining rules to remove (or even mark as inactive) committers/PMC members is not very useful and can be considered a very low priority concern.

  6. I review the document it seems ok for my point of vue, i agree Jacopo's comment.

    Each proposal has to be discussed, to get a consensus, with not too long messages I hope (smile). I think that Pierre has well expressed his view in his comment, that i didn't understand within the discussion in Budapest, I wonder if it is appliable for an ASF project. But it's not the place to discuss it.

    Again nice work ! Hope we'll manage to get something out of it.

  7. Hi Sharan,

    my point of view is well reported. I would only make a little change to the sentence "She found the mailing lists really helpful and the community willing to respond to her questions.", since, actually, I have never sent a question to the mailing list. What I have personally experienced is that any time I have provided a patch someone took care of it, even if they were about minor issues. And as a reader of the mailing list, I have never seen any question left without an answer.

    Thank you!

  8. Jacopo is correct in his statement about not remembering all the topics I addressed in my initial comment as being brought to the table in Budapest. Like I said in the third sentence: 'And not all that I would have brought to the table could be done, due my restrictions on time'.

  9. First of all, quoting Jacopo:

    'real value of the meeting (at least for me) was the fact that we could politely talk with each other without fighting and we had a chance to discuss and learn different point of views'

    I wholeheartily agree to that. It was one of my objectives regarding the get-together, that was the ApacheCon EU 2014 event and its OFBiz track.

    Jacopo said it well in his comment regarding the list of proposals. What comes out of each proposal is up to the entire community to decide. Let's get it over to the community and start finding consensus there on each topic.

    Thanks Sharan for bringing it together.

    Regards,

    Pierre