Floss in Cadastre and Land Registration

Expectations and the reality

There is an interesting aspect of open-source projects: you can change every-

thing you want. Obviously this is because you have full access to the source code 

and are given full freedom to act, respecting the open-source license. This aspect 

offers both opportunities and dangers.

The opportunities are obvious. You are not dependent on one supplier to adapt 

the application to cover your specific needs. You are also not dependent on a  single 

supplier to understand and fix unexpected behavior or bugs in the software.

The dangers are less obvious, but are significant and need serious consideration 

from both the client and the solution provider. The freedom to change everything 

you need can cause you to invest significantly in custom functionality that has no 

wider uptake. Maintenance of such functionality can become a seriously costly 

practice. It creates the need to go through expensive migrations for every new 

 release of the core software. This process includes a number of new test and bug 

fix cycles and can cause serious frustrations to software developers, project man-

agers and end users. Software developers are faced with the not so interesting 

task of merging code; project managers are faced with longer release cycles and 

higher costs while end users see recurring or unexpected bugs and also face  longer 

release cycles. The practice of creating highly customized applications can lead to 

effectively forking a project. Forking is in almost all cases not in the interest of 

both the development team and the end users.

---

38

Some practices should receive serious upfront consideration from both project 

managers and solution providers. Solution providers have the responsibility to 

warn their clients for potential forking and the related high cost of software 

 maintenance. Both maintenance of a fork or maintenance of the alignment of a 

highly customized version to the core software deplete scarce resources and 

should be avoided.

Clients should focus on investing in new functionality that covers a common 

need. Such investment will see highest return on investment since it is more likely 

that others will invest in the same functionality for prototyping, development and 

maintenance. The resulting functionality will be more robust and better thought 

through. Often requirements a client puts forward should be evaluated with a 

highly critical eye; do these new requirements really cover a need, or can the need 

be covered by functionality already present? The solution providers should assist 

their clients by guiding them towards this goal and should accept only limited 

amounts of custom work. This seems to contradict their interest in getting more 

work, but will prove in their interest in the long run. Their clients will see a better 

return of investment and will thus be happier clients. The solution provider can 

 offer a more standard solution and can focus on making that core better instead 

of spending resources on boring migration tasks and testing of exotic function-

ality.

The real challenge is in accepting the limitations of the existing product and in 

 deciding what new function you really need to ensure it becomes widely adopted 

as a core component of the open-source project. This will make both client and 

provider happier.