Follow up on January 7th community call

Community
1

Hello Moqui community and thank you for the engaging and informative call on Friday, January 7th 2022. There are some calls to action at the end so please be sure to read all the way through or jump to the action items first.

Our main topic was, “What do you want and expect Moqui to be?” It was great to hear the various ways in which Moqui is being used and to discuss the software landscape, where Moqui fits in, and how we can differentiate Moqui and drive adoption.
In summary, here are the current uses of Moqui that we discussed. Note that I have intentionally excluded individual or company names.

  • Industry specific software using Moqui as a foundation for financial services related products.
  • Industry specific software products targeting pharmaceuticals and food, and several other product lines under consideration.
  • Public sector solutions for covid traceability.
  • Commercial general purpose ERP and ecommerce.
  • Use of Moqui internally as an alternative to commercial ERP.
  • Also used internally with the specific use case to meter, rate and charge customers for consumption of a cloud service.
  • Moqui as a foundation for ecommerce service offerings to manage backend OMS, WMS, returns, etc. and integration with various storefronts.

I would generally categorize these as:

  1. Commercial software products that leverage Moqui as the foundation.
  2. Moqui as an operational backend for outsourced services (similar to the first, but a services model rather than commercial software).
  3. Internal use as a general purpose ERP and operational system as an alternative or in addition to commercial systems.

From an adoption perspective we discussed various audiences including developers, end users, and buyers / decision makers. We covered a number of topics ranging from pain points to targeting strategies.

  • Improving ramp up time for developers and “developer friendliness”
  • Initially targeting the technical audience to consider Moqui as a business application development framework
  • Improving user interface and user experience
  • Focus on differentiation in the marketplace as opposed to comparing and attempting to compete directly with commercial software vendors
  • We also got into a very interesting discussion near the end of the meeting around Moqui as an integration and data warehouse / data standardization platform to sit between various commercial software tools

Great discussion, so where do we go from here? We need some committees! Just kidding, I hate committees. But we do need to organize ourselves in a way that makes sense and can get some things done. Generally speaking, it seems to me that we need to formalize some roles, responsibilities, and activities that are designed to increase awareness, grow the community, and drive adoption. In parallel we need current members of the community to volunteer for specific activities to support the larger effort. Some examples based on common themes that keep coming up in the forum and on our calls are writing documentation, user interface design and development, API design and development, and more generally the UI/API tooling and how to leverage other popular tools.

I am out of my depth on much of this so I will defer to those more knowledgeable on the technical details. However I think we can state some principles to govern decision making and design. For example, we will continue David’s approach of keeping the foundation clean and avoid the fate of OFBiz. Individuals and groups can put whatever they want in their own components.

From an interface perspective (UI or API) I think the principle is that we design for Moqui to be “headless” and flexible enough for developers to use their front end technology of choice. I realize this is a VERY broad statement and will come with limitations and caveats. But I do believe that pursuing this principle will support the goal of wider adoption by increasing the appeal of Moqui to a broader technical audience. I also believe that to some extent this already exists, we just need to understand and document the details.

More tactically, we need to identify specific action items that we can collectively contribute to and execute on quickly. Here are some suggestions:

  • Developer documentation and training - There is already a lot of material such as “Making Apps with Moqui” and all the content on Moqui.org. Let’s brainstorm on how to best leverage this content. in addition to written content we can also do some things like guided training sessions and work on breaking material down into more consumable chunks. The “Quick Tutorial” on Moqui.org is a good example.
  • Business process / functional documentation and UI design - I am thinking about this in terms of general purpose use. If you are using Moqui to operate your business and / or you have strong functional knowledge and experience with other ERP systems then you are a good candidate to help in this area.
  • Planning - if our goal is to expand adoption then we need a plan. Directionally I think we agreed that we need to 1) improve developer onboarding, and 2) target the technical audience.
  • Document the pain points being raised around “interfaces” whether that be APIs or using other toolkits like React.

Please think about other specific things we can be doing as a community and add them to this thread. Also please bring any relevant artifacts you would like to share to our next call.

1 Like
2

Vince, I think this is a great start. I look forward to working with you to develop this. In keeping with David’s HEMP book, I think a more fully developed business process story, and a glossary of terms as they are used in Moqui, would be a great place to start, along with, as you suggested, a “to do” or task list of topics where additional discussion and documentation is desired.

1 Like
3

Good call out Matt and a good reminder for everyone of existing resources like HEMP and Making Apps with Moqui. I will be reviewing both.

4

Quick follow up on a specific topic in our last call. When we were exploring the use of Moqui as a data integration / centralization platform I mentioned a few commercial products in this space. It is interesting how they position themselves now. Definitely targeting the business more than tech buyers who used to be the targets for data integration / transformation tools and “middleware”.
Some examples are Claravine, Openprise, Syncari.

5

I’m not sure if you already know, but there is a Moqui Board which is the primary “organization” that the Moqui Ecosystem has. Are you suggesting creating an alternate organization that’s primary purpose would be:

If so, that sounds like a lot of marketing. I’m certainly not against this, but an organization like that needs money or / and lots of volunteers.

If there is going to be an organization for the benefit of Moqui I feel like it’s primary purpose would need to at include:

  • Maintaining and Improving the Code (to support future development)
  • Maintaining and Improving the Documentation (to make everyone’s life easier)

I think that such an organization could exist, but I would think that for it to function it would need to be supported by the companies that benefit from Moqui (in people power or/and resources). For companies to support this organization, they would need to be able to ensure that their contribution is used appropriately and least benefits them in some way.

I think that such an organization could facilitate:

and be a place to coordinates place for a:

with incentive for 3rd parties to get the tasks done.

While also:

This is just speculative, but are people / organizations even interested in something like that?

6

The design of Moqui is mainly up to whomever puts the effort into it to make stuff happen. This is an interesting idea, but who’s going to make this happen?

7

As I said in the original post, I believe that to some degree this is already the case. For example @doogie described how they use React. However it is beyond my technical depth, which is why I included this action item:

1 Like
8

Well, the rest interface is certainly very helpful; it’s more when we find business logic hidden behind some backend html screen, and not just directly in the service engine. We feel all business logic needs to be services.

1 Like
9

Do you have a list of some business processes that you need to be used for your business?

If so, finding the appropriate services and exposing them isn’t much of a problem.

10

I think what @doogie is referring to is that there are instances when business logic is embedded in screens rather than in services. As a design principle we can agree that there should be a clean separation but in practice it is not always the case. @doogie , any specific examples would be helpful. And anytime you come across this I would encourage a) raising it in the forum, and b) making the appropriate code changes and submitting a PR.

1 Like
11

@vince.clark I figured out where the documentation is hosted: moqui-org/MoquiOrgPageData.xml at master · moqui/moqui-org · GitHub

Although the majority of it has just been updated in the moqui.org server.

12

Thanks @michael . So it sounds like the latest documentation currently resides in the wiki on Moqui.org. I assume the file you referenced in github is probably just an old export and not where content is actually written or maintained.
I have HiveMind access and am able to see the four wiki spaces containing the current docs, Framework, Applications, Business Artifacts, Ecosystem. It also looks like I can edit. So the question is, can we give people edit access but limit who can publish? This would allow for the community to contribute while also supporting a review process before publishing.
I like the idea of getting more users into HiveMind both for documentation as well as using requests and tasks. For example, it would be great to create tasks for sections of documentation and assign them to contributors.
One challenge I have had with the wiki is my login timing out while I am writing. I use it internally for taking notes in meetings and other things, and am constantly saving to avoid losing content. So I think for us to use the wiki more broadly we need to implement an auto save capability.
So the open questions I have in order to proceed with the wiki for documentation are:

  1. Can we support a separation of responsibilities that limits who can publish
  2. Can we add an auto save feature to prevent loss of content while drafting
  3. It would also be helpful to “at” mention people in page comments, which would be a nice feature in other areas of Moqui as well. I think if we proceed with the wiki and get more people writing documentation we will have several enhancement requests like this.
1 Like