Using Open-Source Software in onOffice enterprise

Why Open-Source Software Matters to Developers

Some of the problems that we want to solve as programmers are unique, but many are not. And part of being a programmer means practicing logical thinking, which leads us to realise that cooperation is a very important strategy for minimising waste and getting work done. Who among us does not have Stack Overflow in their browser history?

But we also know that code does not spring fully formed onto the page. It takes work and time to create something useful. There is some tension, then, between recognising that code belongs to its creator and wanting to reduce unnecessary labour.

This is where licences come in. The author can decide to make the software freely available for others to use, provide it for a fee and/or with conditions, or keep it to themselves. Public resources such as the Open Source Initiative licence list and the SPDX License List can help teams understand common open-source licences, but every use case still needs to be checked carefully.

How onOffice Checks Open-Source Licences

Our team at onOffice is no different from other development teams in this respect. We use many third-party libraries, from the languages and frameworks we write and test in, to Google authentication, to our customer-facing text editor. When we are working on a project in which it makes sense to use open-source software, we are supported in doing so.

One major benefit of using onOffice enterprise ourselves is that we are able to make full use of all of the features we develop. Many real estate agents value the process manager for sending automatic emails to clients, but we can use it, among other things, to formalise the process for making a decision about whether to include external source code in our product.

The process works in a clear sequence:

1. A team member identifies external source code or an open-source library that could be useful.
2. The process points them to the regularly updated wiki article about software licences.
3. The wiki provides information about many commonly used licences and whether they are appropriate for our purposes.
4. In our case, the software must allow commercial, proprietary use.
5. If the code we want to use is covered by a licence not listed there, the process automatically creates tasks for the relevant decision makers.
6. The decision and any required follow-up steps are documented in the process.
7. Required copyright and licence information is added where it belongs.

We enjoy a very flat organisational structure at onOffice, and many questions are answered through a quick chat message. But the tasks created by the process allow for more focus. The team member who would like to use the software does not even need to know who is responsible for making decisions about software licences.

How We Acknowledge Third-Party Software

When using software created by others in our products, we acknowledge them in our “About Us” section. We do this not only because many licences require a copyright notice and a copy of the licence, but also because we respect others’ effort and value cooperation.

An important part of the process is a reminder to update this section. It is not enough to achieve a technical result. The process is not finished until every requirement is completed.

Why Documentation Is Part of the Process

Finally, the use of the process is self-documenting. The tasks themselves and the comments within them show the decision-making process. We do not expect any one person to remember all the details, or hope that they are written in a convenient place.

We know how to refer to this information in the future, if necessary. Documentation is very important at onOffice, but not for its own sake. It helps us make responsible decisions that remain transparent later.

Open Source, Cooperation and Responsibility

Bureaucracy is not one of our values, but entrepreneurship and cooperation are. It is very rewarding to work at a company that respects the development process and allows us creativity and agency in our work, while also valuing the contributions of the wider community.

Instead of reinventing the wheel, we can foster community and focus on the parts of our job that are unique.

Working With Responsibility and Freedom

Good software development is not only about writing code. It is also about using existing work responsibly, documenting decisions clearly and respecting the people who contribute to the wider software community.

At onOffice, this gives developers the freedom to use useful tools while keeping the process clear, transparent and reliable.