Using Open-Source Software in onOffice enterprise

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 doesn’t have Stack Overflow in their browser history?)

But we also know that code doesn’t 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 licenses 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.

We need to make sure the licence suits our purposes.

Our team at onOffice is no different. 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 to send 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 points us to the regularly-updated wiki article about software licences, with information about many commonly used licences, and whether or not they are appropriate to use. In our case, the software must allow commercial, proprietary use. If the code we want to use is covered by a licence not listed here, the process automatically creates tasks for the relevant decision makers.

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 allows for more focus — and the team member who would like to use the software doesn’t even need to know who is responsible for making decisions about software licences.

When using software created by others in our products, we acknowledge them in our “About Us” section. Not only because most licenses require a copyright notice and a copy of the licence, but because we respect others’ effort and value cooperation. An important part of the process is a reminder to update this section. It’s not enough to achieve a technical result; the process isn’t finished until every requirement is completed.

Finally, the use of the process is self-documenting. The tasks themselves and the comments within them show the decision-making process — we don’t 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.

Bureaucracy is not one of our values, but entrepreneurship and cooperation are. It’s very rewarding to work at a company that respects the development process and allows us creativity and agency in our work, as well as 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.