# Integration of BIM and GIS for the Digitization of the Built Environment
## 4 Results and Discussion
### Open-Source Environment  
The analysis of trends in methodology development examined the evolution of practices from closed-code to open-source models. It turns out that in the 1960s, with the advent of mainframe computers, companies sold integrated hardware and software. Due to the limited availability of commercial software, researchers turned to the open exchange of source code [85]. The introduction of email around 1969 further supported this free exchange of ideas. Subsequently, the unbundling of hardware and software by IBM, which began around 1969, made software an autonomous and increasingly sought-after product. In 1981, changes in patent law in the United States, combined with the advent of the PC, led to the source code of the UNIX operating system being closed. In September 1983, [PERSON] started the GNU project to create a UNIX-like operating system and introduced copyleft licenses such as the GNU General Public License [86]. OS later found a place among hackers, programming enthusiasts or software developers, with motivations ranging from the quest for freedom of choice to the desire to contribute to the good of society. The definition of open-source software development (OSSD) has been outlined by evidencing its distributed nature and the wide participation of contributors communicating through the Internet. Communities such as the Open Source Observatory (OSOR) [87] support the improvement of code quality and usability; the Software quality observatory for open source software (SOO-OSS) [88], which is flexible and accessible through different user interfaces, facilitates the effective inspection of OSS. In the event of collaboration difficulties, it is imperative that communication between developers be maintained at a high level in software development. In OS, however, this only happens over the Internet, which means that geographical distance and distributed collaboration can lead to a decrease in communication between developers. Another problem is getting users to contribute to the project to the end, as there is no obligation to do so, and they are completely free to decide whether or not to continue. Releasemanagement can be problematic, as the guidelines for managing releases are informal from the start of the project. In addition, the lack of suitable developers or interested users in OS projects can have a negative effect on the motivation of volunteers to maintain the project. In addition, all patches submitted to the project must pass the peer review process, which assesses code style, overall quality and interoperability with other parts of the application. There are also disadvantages to the use of OSS in business, which including version proliferation, complexity and the necessity for numerous licenses, implementation problems where there is no one person responsible for developing and solving software problems, and high short-term costs for OSS compared to lower long-term costs than those of the traditional model. Moreover, the economic challenge of OS in motivating volunteers to participate without remuneration is considerable. Furthermore, it is possible that for an extended period of time, there will be no updates to the system, forcing users to work with an older version of the software, as there is no guarantee that regular updates will be provided. A comparable issue arises with regard to support; in fact, there is no support for OS, in contrast to CS. In large OS projects, the contributions of developers may take longer to be exhausted, which can be problematic for volunteer developers. As shown in the proposal study, in the OS context, interoperability was achieved through the use of QGIS software. To integrate BIM models within this software, it was essential to use an external platform capable of generating a sharing link to be inserted into the attribute table of the polygon created. Only after this operation was it possible to view the BIM model within QGIS.