Home / FAQs / Applet, APP, SaaS and old systems
QUESTION & ANSWER

Custom Development vs. Open Source System

Processes are common, open-source products mature and licences allow for secondary development. When business differences, core architecture limitations or long-term upgrade costs are high, it may be more appropriate to develop from zero.

Answer the question.

First, give conclusions that can be used for decision-making

The key is the degree to which open source systems match core operations. If 80% of processes are directly available, only brands, privileges, a few interfaces and interfaces are required, and secondary development is usually more economical; if extensive changes are required to bottom-up data models, privileges and key processes, short-term, seemingly savers may be able to produce forklifts that are difficult to upgrade over the long term.

DECISION FACTORS

What conditions need to be identified before judgement is made?

The same question may have different answers under different business, data and project phases. It is suggested that the following conditions be checked and that the common findings on the web be incorporated into their own projects.

Whether licences allow commercial use, distribution and closed-source expansionLevel of compatibility of core processes with existing data modelsSustainability of community-based activities, security updates and critical dependenciesHow to combine upstream upgrading and control technical debt after secondary development
ACTION STEPS

Suggested order of advance

01

First, we'll be clear about the target and the border.

Select the most complex real process to validate in the open-source candidate system.

02

Validation Key Dependence

Review of licensing, architecture, reliance, testing, safety and deployment modalities.

03

Development of assessable outcomes

Costs of upgrading, maintenance and replacement are estimated over five years, rather than being developed for the first time only.

04

Make sure you decide the next step with the real results.

Custom layers and cores are decoupled as much as possible and upgrade and migration programmes are maintained.

PRACTICAL EXAMPLE

How do you understand it in the actual business?

Example used to illustrate the method of judgement

The company has to build a worksheet system, with open source products supporting worksheets, roles, and notifications, but the enterprise needs complex equipment protocols and offline APP. The core of mature worksheets can be maintained, with additional equipment and mobile modules added through the API; subsequent security upgrades will be difficult if the core is rewritten directly. Borders are usually better combined than overall modifications. Examples do not represent the performance of a particular client, and actual conclusions need to be verified in conjunction with the enterprise’s own business volume, sample, system and responsibility boundaries.

COMMON RISKS

The easiest pit to step on.

We don't think it's going to cost the software when we download the code.

Use of licences for commercial delivery without review

Too many changes to the core code without upstream upgrading strategy

ACCEPTANCE

How should we end up receiving and confirming?

The selection should include matching certification, licensing advice, scope of modifications, performance security checks, deployment programmes and three to five-year maintenance estimates.

When preparing to communicate with suppliers or internal teams, it is recommended that current processes, representative samples, existing systems, planning time and budget levels be brought. First, the unknown items are clearly marked, and then the decision is made to use diagnostics, PoC, fixed-range projects or ongoing research and development, which is usually more reliable than a direct demand for a price and duration without borders.

Uncertainty whether to develop from zero or to adapt to open source systems?

Description of operational differences, candidate systems and long-term maintenance requirements, with prior approval, depth of adaptation, upgrade risk and overall input.

Contact Us