Strategy : version 2 ways


#1

Hello to all of you,

Flectra has been out for about 1 year and has made many improvements over the community version, open source, of Odoo 11.

Flectra keeps benefits from patches, so stability and security, by regularly backporting patches from Odoo version 11… This is in my opinion an excellent thing but it will stop in the fall of 2020.

In fact, I think it is relevant to start the discussion on the after, and a possible version 2 of Flectra. What strategy could and should be adopted?

I see three possible ways. I will try to describe them, then I will give my own opinion:

Follow your own path

Flectra could decide, for its future major version, to follow its own innovations. It is the way of independence, it is the way Odoo has chosen for its software.
This is a way to maximize compatibility with existing modules and ecosystem can lead to great technical expertise.

On the other hand, this path requires very important efforts in research and development, with an enormous mobilization of skills because it is a question of maintaining and developing both the modules and the core: the Python framework, its access layer to the database and its public part (CMS), the Javascript framework which serves as the solution’s private interface, interactions…

Taking the best of open source

Another way could be to recreate/rethink the core of Flectra and rely on existing open source technologies, with their own community, to replace the things that were specifically developed by Odoo and are now used by Flectra. For examplePeewee orPython-SQL could be used for data access, the template engine could use a more common XML technology (such asGenshi for example), the JavaScript framework could be replaced byOpenUI, orView.JS

This way would make it possible to delegate low-level research and development costs to the communities in question, ensure a real and interesting technical evolution and it would be possible to update the use of common libraries with other open source ERPs such as ERPNext or Tryton.

However, this is an ambitious path, as it would break all existing modules, both internally and in the community. It would indeed be necessary to write solutions allowing a complete interoperability and therefore ensure that current modules made for Flectra 1 will still work. this represents an important and complex work.

Odoo 13 fork

The last way I think about would be to redo what had been done for Flectra 1, i.e. start from a recent version of Odoo (to fork). It would be to wait for the release of the version 13, in October 2019 theoretically, and to base on it to build Flectra 2. We would only take ** the low level** technical part, de facto delegated to Odoo S A and could benefit from about 2 years of patches recoverable on it.

Choosing version 13 would allow Flectra to allow 1 year to prepare version 2 before version 1 support is no longer provided through Odoo 11. The idea of taking only the core would make it possible to keep the modules as they are and to modify only the technical elements impacted by Odoo version 13, thus limiting the difficulty of operating the existing modules on these new foundations. This would also allow the community to allow up to 1 year to adapt its modules for version 2 of Flectra.

The concern of this approach lies mainly in the dependence on Odoo S A and the critique that can be addressed regarding the strategic and technical choices made (and in particular the fact of choosing to develop your own solutions).

My opinion

In my humble opinion:

  1. The first solution would be a bad idea. Flectra does not have the financial or community capacity to ensure such a burden, either now or in the long term;
  2. This second track would have my technical preference, because I consider it more relevant and logical, more open to other communities and allowing for a stronger independence. However, I fear that the complexity required to continue to operate the existing modules will lead to an effort that I don’t know if Flectra or the community would want to take over…
  3. The last proposal is the most pragmatic. Since the Odoo base is relatively stable, migration efforts for two major versions should remain moderated. It would allow Flecra to focus on the overall reliability of the current modules and their evolution for another year before working on the next version.

I welcome the point of view of all those who will read this topic, because I think that the strategy must be discussed and decided quickly in order to allow everyone to anticipate what a version 2 of Flectra will be, to contribute to its success.


#2

Hello, it’s a good approach for the future of flectra, I think if we want Flectra be a really alternative to Odoo the better way is the second track that you propose, mainly because we always can take the best on odoo and convert to flectra, obviously is more work, but flectra can have it own way to make things.


#3

The topic is very necessary.
To begin with, I think the authors and the Flectra community should answer the following questions.

  1. What caused Flectra?
  2. What problems are there now?
  3. What is the history of similar situations with other projects and what will be the difference from them? (For example, https://www.cubicerp.com/, http://hexya.io/, etc.)
  4. What driving forces will help to resist competition with peers?

For example, I appeared here as a result of a search engine for creating applications in the cloud. Revised many projects. Stopped on Odoo, as a possible tool. Then he drew attention to the Odoo policy regarding its product and community. Assumed that this behavior can not satisfy the aspirations of the community and should lead to a split. In one forum, I called them - sly ass.
I was informed that an alternative has already been created - Flectra
And here I am. In the hope that Flectra will have success and I will also contribute to this.

To popularize the Flectra platform and support those who are engaged in it.
Make it easier for users and developers to join Flectra
Intensify the creation and support of websites for developers and users on the resources of the Flectra community, national and other resources (hosting)
For example flectra.by, flectra.ru, flectra.app, flectra.pro, etc.
For this, it is possible to create preferences for active supporters.
These are not exactly technical questions. But also quite important.


#4

I agree with most of your points about growing the community. Main problem is lack of manpower, and we do our best.

My own answers on your four questions :

  1. Original authors have explained their reasons on first Flectra website version : goal of creating more technically and functionally strong product. There were also elements around end-user focus ;
  2. @parthiv and @thomi_ch may answer better than me. IMHO there are some key points : ensuring long term viability of the product, by Helping Flectra HQ to keep a good economical model and by building a dynamic community, focusing on priorities (to me it’s stability, batteries included, end user focus - so documentation, wizards, inline help…) ;
  3. Hexya is mostly a performance fork, a whole reimplementation from Odoo Python framework to Golang. I disagree with the need, as the main workhouse of Odoo is PostgreSQL, not Python, and there are mainly rooms of improvement for Python itself (Odoo S A demonstrates that in last versions). For CubicERP, it’s AGPL fork of v8 then v11 but v8 branch was private and v11 is still alpha stage. I think they really lack manpower (to provide / form an international community, even if there was an attempt of building a foundation around it). I have plans to contact them to see if Cubic 2018 and Flectra can converge / help each other.
  4. It depends which peers you are talking about. I think that Flectra inherits strengths from Odoo SA : good and efficient technical framework; great modularity, usability ; wide functional perimeter including ERP, CRM, CAPE, CMS, ecommerce … and greatly improved by Flectra HQ themselves (vs Odoo CE).

#5

Hello,

I personally feel the 3rd approach is more appropriate and it can be used as a launchpad and to popularize Flectra in the business world as robust and highly productive Odoo alternative!

But cloning each and every new version of Odoo (and then renaming it) is not the way to go. This approach is required to get started but then the core team will have its own vision for Flectra so they should diversify and built their own independent platform which is not a mirror reflection of Odoo.

One way to keep up with Odoo and its features after diversify Flectra is to add the best features of Odoo to Flectra as and when needed.

Regards,


#6

A consistent issue I see is the complexity of the system. I think either path 2. or 3 (mentioned above) both require reducing complexity. This effects both the developer and customer network. It is hard for me to recommend a very complex product that I know will need to be modified ( even more when the resources to do so are scarce). On the other side as a developer it would be hard to commit to learning a very complex product skills that would not translate well in other areas. The big companies are addressing the issue with things like microservices ( big undertaking, but it could be gradual). This would also bring a lot more people to the community as these skills are trending.
The big opportunity I see for a ERP player is in the Marketplace space. ERP next is going down this route, but have still missed some key parts from what I have seen in there forums.


#7

I agree : the third strategy could be used for v2, and the second strategy could be used for a v3…

I don’t quite agree : even if Flectra is an ERP, with wider functional perimeter (CMS related features etc), it’s still has low complexity, technical side (the Python framework + XML is 90% of the work for developers. JavaScript framework is quite simple, tied to Python side, and based on common libraries like Boostrap).

Although microservices seems attractive, I think they strongly increase architecture complexity and skills needed to manage them. They also tend to decrease performance, as each microservice should be independent and able to communique fully, and, as many technologies could be involved in the whole (different pieces with different programming languages and ecosystems), it becomes really hard for a company, without thousands of employees, to master the whole software.

Marketplace is IMHO interesting element. It can help in the global economical model of Flectra and a peer open source software like ERPNext has already bet on it. We may investigate this subject further.


#8

I like the path of going for option 3 then 2. :slight_smile:!

As for complexity my hope would be that there is a focus not just on adding new features but also future upgrade ability. I know this can not be perfect though.

As for Microservices I will just say they are much easier to deploy and manage then they were a year ago and will be even easier next year. I will also add there is a important marketing element to jumping on trends.


#9

First priority should always be on long-term support for the product instead of annual version upgrades and short-term support. Version upgrades should only come when there is big technical upgrades in the product. If annual upgrades can be made fully automatic then it does not matter. This is one of the weakest points in odoo for it’s community users.

I think the best path would keep Flectra close to Odoo versions for time being. Then focus on own modules and annual upgrades. When there is a larger community in Flectra then it can start going on it’s own road. This would also help companies to start building their business on top of Flectra. If something goes wrong in Flectra, you can always go back to Odoo.


#10

I talked a bit with those who keep records in Odoo. Many now stopped at odoo 8 and odoo 9 due to the fact that community policy has changed. In their opinion, not for the better. Some modules were unavailable. Also there are big problems with updating versions.
In this regard, I think that the Flectra community should stop at Odoo 11. During the year, work on reliability and automatic transition to new versions. Add basic functionality.
Then customers stuck on the Odoo 8 and Odoo 9 versions will be able to start further promotion on the Flectra platform. These are potential customers. We need to work with them.
In the near future to tackle the mechanism of localization of the product Flectra. Add visual tools like Studio, Reports, etc.
We must try to attract to the transition to the platform Flectra Cubic ERP


#11

I agree. 1 version per year is too much, moreover even with upgrade path. That’s why I propose version two for end 2020 (~3 years after version 1).

I understand but the way proposed is to only rely on new low-level framework, keeping all addons as they are (only technical update) and thus, avoiding breakage, regressions…

Both are on their way. Flectra HQ is working on translation platform (first step for localization). Visual tools will pop before the end of the year I guess, but as delayed release (not core). We will need to fund them if we want to get them into core.


#12

That is, it is supposed to release visual tools in the form of add-ons on a paid basis before the end of the year?

About the versions. I assumed the continuation of 1.5, 1.6, 1.7, …2.0


#13

Yes delayed addons have been announced few months ago. Work in progress View editor may be one of them.

For versionning, I’m in favor of semantic versioning. So 2.x should be major version with API breakage. In this case, 1.x should remain compatible with previous versions and seen as an unique stable release.


#14

The Flectra roadmap is really crucial. But I would go beyond version 2.0 with the strategy. An ERP system is usually introduced for at least 5-10 years and therefore a long-term planning should be presented here (at least on paper).

For version 2.0 I would consider the fork of Odoo v13 (variant 3) as the best solution. But starting with version 3.0 I would go for a stand-alone solution.

However, I could also live very well with variant 1 already from version 2.0, which makes it faster to detach from Odoo and to implement missing functions (e.g. a useful tree structure view, helpful mixins). How high the effort for creating a v2 based on v1 really is depends strongly on the goals of v2.

Switching to existing OpenSource frameworks is not an option for me personally. Here I prefer a code base which is built as one unit. Even if single frameworks are better in their areas. I use the same argument towards my customers. Even if an ERP has weaknesses, e.g. in production, the advantages of the all-in-one solution outweigh the disadvantages.

Finally, I would like to mention the following points for the strategy:

  • The quality of the core and the available modules is enormously important. Many of our Odoo customers feel that the system is only half finished because modules are not mature enough.
  • Translations and internationalization should be rated very highly.
  • The strategy should definitely include more than just product development. Documentation, marketing, sales and sales support, partner programs and much more are also part of the strategy. Right now, strategic sales promotion seems to be even more important than product development. Because the product itself is already really good and ready for hundreds or thousands of customers.

#15

Found an interesting link. Perhaps this will also be useful for the issue under discussion.


In my humble opinion, the values that were declared were violated.


#16

I would like to raise this topic.
Is it possible, at least somehow, to see plans for the implementation and further promotion of the Flestra platform?


#17

I’ve been pondering about this actually. It is important to get the cadence right because this is a project that is potentially going to be used in 1000’s of live businesses and the last thing they need is either EOL software or massive breakages in either key modules or functionality. This is aside from the developer portion of trying to target a framework that keeps on changing.

The move from Odoo 11 to 13 was non trivial and I expect 13 to 15 will be equally so with the added complications of more key functionality being locked behind subscriptions.

Of the 3 options I have to feel it should be 3 then 2 and if we get enough growth maybe attempt 1 after that. But the key should be on stability while pressing forward on features as definite roadmap.

For myself for example I know I will have to start righting specific modules for the UK to be able to sell it into any UK businesses because the tax system is moving totally digital and banking is following suit. This means there has to be a way to format and export data in a way that is compatible and consistent across releases.

Either way that is my vote fwiw.