Tender to implement Curl based HTTP/WebDAV UCP (#202104-01)

Note: for questions asked about this tender and their respective answers, please see the bottom of this page


We are extending the application deadline.

The deadline for questions stays as in the original tender: June 15, 2021
The deadline for applications has been extended to: June 24, 2021


The Document Foundation (TDF) is the charitable entity behind the world’s leading free/libre/open source (FLOSS) office suite LibreOffice.

We are looking for an individual or company to implement Curl based HTTP/WebDAV UCP.

The work has to be developed on LibreOffice master, so that it will be released in the next major version.

The task consists of addressing two problems. All of the mentioned features and requirements are a mandatory part of this tender and therefore have to be part of the bid. This tender does not contain any optional items.

Problem description #1 – Currently we need to bundle crypto libraries

  • TDF releases of LibreOffice bundle both OpenSSL and NSS, but both libraries have a high number of security issues.
  • On macOS and Windows, neither OpenSSL nor NSS integrate with the crytographic APIs supplied by the operating system, so they will use a bundled hard-coded set of trusted certificate authorities (CAs), that is different from what the operating system itself would trust. This hard-coded set of trusted certificates is also not user-modifiable.
  • Additionally, OpenSSL cannot ever be used from the system because it has no application binary interface (ABI).

Problem description #2 – Currently we duplicate and use different HTTP/WebDAV UCPs

  • One which is used by everybody, including TDF releases, using a bundled Neon WebDAV library. This requires OpenSSL and cannot be used on a hypothetical Apple iOS port.
  • Another (for a hypothetical Apple iOS port) using a bundled Serf library. This requires OpenSSL.
    • Serf does not actually support WebDAV directly, only HTTP, so the UCP itself implements the additional WebDAV protocol features.
    • It is complicated to build, as it drags in two other bundled external libraries.
    • Additionally, this cannot be upgraded to a current version without introducing a new build dependency on the “scons” tool.
  • TDF releases also bundle the Curl library.
    • This can can do HTTP, likely similar to Serf.
    • Also, it can use native operating system cryptographic APIs and trusted certificate authorities (CAs) on Windows, macOS and Linux.
    • It can be used on Apple iOS without problems. (iOS deliverables are not part of this tender.)

The solution we seek, and as such the scope of this tender, is to implement a HTTP/WebDAV UCP with Curl, possibly based on code from the Serf UCP, to solve these issues, by getting rid of four bundled external libraries and one hard OpenSSL dependency. Besides addressing the above issues, the new Curl-based implementation needs to be at least as functionally complete as the existing Neon-based one.

All technology standards of relevance, as well as their targeted versions for this tender should be declared or defined in the offer’s description of implementation (e.g. name and version of the cryptographic API on the respective operating systems).

A key item of the deliverables for this tender, and therefore also a decision criteria – besides qualification, references, price, and completeness of fullfilment – is extensive documentation about the approach chosen to implement the above items, covering more than just the pure implementation. We expect bidders to provide documentation on both the code and the non-code parts of this tender, e.g. methodology, structure and technical aspects.

The Document Foundation will publish this under a free and open source license and make it available to the general public. Another criteria for the evaluation of the bids will be the description of the required test activities and the delivery of (automated) tests supporting work items for the described tender implementation or feature specification.

Required skills

  • Extensive knowledge of C++
    Experience working on the LibreOffice source code

Other skills

  • English (conversationally fluent in order to coordinate and plan with members of TDF)

We use free, libre and open source (FLOSS) software for development wherever possible, and the resulting work must be licensed under the Mozilla Public License v2.0.

TDF welcomes applications from all suitably qualified persons regardless of their race, sex, disability, religion/belief, sexual orientation or age.

Bidders will get a preference for including a partner or independent developer who has not been involved in a successful tender before. For such developers, who have not yet been part of a successful tender bid, we aim on a best-effort basis, but without any guarantees whatsoever, to provide some mentoring in understanding the code base and the process in contributing to the code. We expect that time and efforts on the bidder’s side for this should not be part of the paid work for this tender. Please mention such need of LibreOffice development mentoring in your offer.

As always, TDF will give some preference to individuals who have previously shown a commitment to TDF, including but not limited to certified developers and/or members of TDF. Not being a member, or never having contributed before, does not exclude any applicants from consideration.

The task offered is a project-based one-off, with no immediate plans to a mid- or long-term contractual relationship. It is offered on a freelance, project basis. Individuals and companies applying can be located anywhere in the world.

When budgeting, we anticipated that this project (all items combined) to take in the region of 40 days of work. Should bidders’ assessment result in a significantly different number, please reach out to us before sending your bid, so we can clarify upfront.

TDF is looking forward to receiving your applications for the aforementioned tasks, your offer in form of a fixed-time, fixed-budget approach, and the duration period for the implementation in calendar weeks after the final awarding of the tender, via e-mail to a committee at tender20210401@documentfoundation.org no later than May 31, 2021.

Applicants who have not received feedback by June 30, 2021 should consider that their application, after careful review, was not accepted.

All bidders are invited to ask their questions on this tender until June 15, 2021. Questions can be sent informally to the above e-mail address, and answers will be made public in a collected and anonymized form.


We received the following question:

“getting rid of four bundled external libraries” – Could you please clarify what these four libraries are?

Answer: the text only indirectly mentions that serf “is complicated to build, as it drags in two other bundled external libraries”, which are apr and its dependency apr_util (both in external/apr/). So the “four bundled external libraries” would be apr, apr_util, neon, and serf. (There are still other dependencies on openssl, like ExternalProject_python3 and ExternalProject_xmlsec, so we will not get rid of it through this tender.)


We received the following question:

Could you please expand a bit on:

1. the meaning of ‘extensive documentation’, e.g. number of pages or words, and level of detail (classes, functions, line-by-line) that would meet the acceptance criteria?

2. the target audience (e.g. certified LibreOffice developers, or more general?) and purpose of the documentation (e.g. teaching, reference, new implementations, maintenance), as well as form (document format) and acceptable publishing location (e.g. inline, separate-but-within-the-code-base, wiki, or elsewhere)?

Answer: There is no fixed criteria for the documentation. Our goal is to share the knowledge about the approach chosen to address the problem and/or implement the feature, in order to make that information available to the general public.

The target audience is a suitably skilled developer. As such, industry-standard inline documentation in the code, targetting experienced and/or certified LibreOffice developers, plus documenting any non-obvious design choices in an accompanying README file, would be sufficient.

Update on tender for a built-in UNO object inspection tool in LibreOffice

In July last year, we launched a tender to implement a dedicated, built-in UNO object inspection tool in LibreOffice. UNO refers to Unified Network Objects, the component model used by the software.

Tomaž Vajngerl was assigned to work on the tender, and has blogged about his progress. He discusses the point-and-click functionality to inspect selected objects in the document, and his next steps.

If you’re interested in the technology “under the hood” in LibreOffice, check it out!

Join the LibreOffice Team as a Developer Community Architect (m/f/d), 20-40h per week, remote (#202101-01)

The Document Foundation (TDF) is the non-profit entity behind the world’s leading open source office suite, LibreOffice. We are truly passionate about free software, the open source culture and about bringing new companies and people with fresh ideas into our community, especially as we are about to enter the second decade of our project.

To grow the LibreOffice community and to enlarge the associated ecosystem, together working on office productivity for over 200 million users around the globe 🌎, we’re searching for a Developer Community Architect (m/f/d) to start work as soon as possible.

As our future Developer Community Architect, you work with a great team of currently eleven to:

  • Attract new contributors by promoting the LibreOffice project

  • Identify and onboard them, by building relationships between new coders and the community

  • Introduce them to our communication channels where they meet fellow co-hackers

  • Affirm and encourage everyone’s contribution and show community members ways to grow

  • Bring skilled contributors in contact with existing experts in the various fields for even deeper learning

To succeed in this new role, you ideally already have some of the following skills:

  • Previous experience in remote work

  • Self-driven and an excellent team player, who is interested in working as part of our team

  • Patience and kindness to work with potential contributors of various skill levels

  • Been a long-time contributor to one or more FLOSS communities, with coding experience in at least one FLOSS code base – ideally LibreOffice, of course! 🙂

  • Demonstrable C++ coding experience of at least five years, or a comparable language like C#, plus active knowledge of at least one more language used in LibreOffice, like Python or Java

  • Excellent communication abilities, that help you transport your enthusiasm for LibreOffice and our community

  • A quick learner with good self-starting capabilities (demonstrable quick learning is a good compensation for immediate lack of LibreOffice knowledge!)

  • Experience in web development and/or mobile technologies is a plus

  • When possible again, willingness to regularly travel to Hackfests and conferences in Europe and globally. In the meantime, you are excited to create virtual events on a regular basis, with the excellent infrastructure offered by TDF.

  • Fluent written English for e-mail and chat, with good speaking and comprehension is a mandatory requirement. Fluency in another widely-used language like e.g. Spanish or Mandarin would be considered an advantage.

Here’s how a typical day in your new role might look like:

You start your day by looking in Gerrit for unreviewed patches. There, you help to onboard new contributors, by positively reviewing their code contributions, which also involves syncing the coding style of their patches with LibreOffice’s. Your goal is to work with them and help them grow their skills where needed, like C++ programming, design and coding, and encourage them to bring up their own ideas how to implement a new feature or fix a bug in the codebase – in short, you are their guide to make their ideas become a reality. Especially for new contributors, you will introduce them not only to our community culture, but also to our variety of tools, which you regularly review and make proposals to improve or unify them.

One way to attract new contributors is to lower the entry barriers. You design and define easy tasks (“Easy Hacks”) for coders, that help them to learn about the code, our toolchain, the LibreOffice build system and leads them step by step into growing mature in the repository, so that they can ideally work on more advanced tasks.

Apart from the individual mentoring, an important part of your role is about knowledge sharing with the general public by writing and updating our technical documentation, like the developer guide, our wiki articles and also code comments. You master that thanks to your ability to write comprehensive texts for technical people.

The role you will fill gives you a lot of freedom and flexibility to shape our mentoring program. That requires you to work goals-oriented and with a laser-sharp focus to grow excellent LibreOffice core contributors. As our successful Developer Community Architect, you will come up with creative ways of finding and attracting volunteers who will stay in the community!

All jobs at The Document Foundation are remote jobs 🌟, where you can work from your home office or a coworking space. The work time during the day is flexible, apart from very few fixed meetings. The role is offered both as part- or fulltime, with the option to grow the hours later, just as you grow into your role.

Are you interested? Get in touch! We aim to schedule the first interview within two weeks of your application. You can also approach us anytime for an informal chat to learn about the role or in case of questions – and you can directly join our virtual FOSDEM DevRoom on February 7 to see what’s going on in the community!

TDF welcomes applications from all suitably qualified persons regardless of their race, gender, disability, religion/belief, sexual orientation or age. Don’t be afraid to be different, and stay true to yourself. We like you that way!

We are looking forward to receiving your application, including information about you, when you are available for the job, and of course your salary expectations. Please send us an e-mail to mentor.application@documentfoundation.org by February 18, 2021. A final decision for the role will be made by March 18, 2021.

Note: We do not accept agency resumes. Please do not forward resumes to any recruiting alias or employee.

Tender to finish transition of LibreOffice to ODF 1.3 (ODF 1.3 delta) (#202010-01)

The Document Foundation (TDF) is the charitable entity behind the world’s leading free/libre open source (FLOSS) office suite LibreOffice.

We are looking for an individual or company to finish transition of LibreOffice to ODF 1.3 (ODF 1.3 delta).

This tender builds on the previous ODF 1.3 tender and aims to implement additional features.

The work has to be developed on LibreOffice master, so that it will be released in the next major version.


The following required features (section A) need to be implemented:

  • chart:data-label-series. Missing feature. It is needed for import from Excel.
    • Relevant bugs in TDF’s Bugzilla: #94235, #133176
    • OASIS reference: OFFICE-2117
  • chart:regression-moving-type. Implementation of types “center” and “average-abscissa” is missing. It is needed for interoperability with Gnumeric.
    • For this feature, there is existing code that can be extended.
    • Relevant bug in TDF’s Bugzilla: #133423
    • OASIS reference: OFFICE-3959
  • <text:index-entry-link-start> and <text:index-entry-link-end> in user-index. The link marks exist, but the function itself is not implemented.
    • For this feature, there is existing code that can be extended.
    • Relevant bug in TDF’s Bugzilla: #121842
    • OASIS reference: OFFICE-3941

The following are desirable features (section B):

  • draw:fill for background of pages. Attribute draw:background-size specifies whether a background fill covers the entire page or only the content area of the page. It belongs to element <style:drawing-page-properties>. ODF 1.3 has extended its use to all kind of pages. Some related bug reports have been set to “fixed”, but the problem is not completely solved, details in the bug report.
    • The respective attribute seems to get written by LibreOffice already. All Writer documents are now the entire page.
    • Relevant bug in TDF’s Bugzilla: #134734
    • OASIS reference: OFFICE-3937
  • draw:z-index more precise with increase from back to front. Problem needs to be solved too for cases when converting from docx to odt.
    • Relevant bug in TDF’s Bugzilla: #133487
    • OASIS reference: OFFICE-2122

The following features are nice to have (section C):

  • Wrong icon of master document template in Windows Explorer
    • Relevant bug in TDF’s Bugzilla: #133285
    • OASIS reference: OFFICE-2580
  • pivot table based on named range with local scope
    • The previous implementation didn’t work out. This is a rather complex task.
    • Relevant bug in TDF’s Bugzilla: #37268
    • OASIS reference: OFFICE-3665

The following features are purely optional (section D):

  • Adapt function wizard to the fact, that the second parameter of DCOUNT and DCOUNTA may be empty (i.e. optional)
    • This can be qualified as an “EasyHack”.
    • OASIS reference: OFFICE-3906
  • chart:coordinate-region. There is no help about this topic. There exists no option to not use this kind of position and size reference.
    • That feature was handled differently until OpenOffice.org 3.0, where the coordinates included the description, now they are without, i.e. the reference changed.
    • OASIS reference: OFFICE-3928
  • fo:min-height as attribute of draw:text-box. LibreOffice does not use that attribute and ignores it on file open. Missing feature.
    • That element seems to be written by Word, but likely not yet by LibreOffice.
    • OASIS reference: OFFICE-3735

The following feature is purely optional, and not trivial from a UX point of view (section E):

  • svg:stroke-linecap at object style vs draw:style in element. Implementation of draw:style is incomplete. Especially there is no UI to define a line style with round dashes.
    • Relevant bugs in TDF’s Bugzilla: #133499 (Implementation has error), #127509, #127348, #127266, #123349, #53276, #127207
    • OASIS reference: OFFICE-3742

Required skills

  • Extensive knowledge of C++
  • Experience working on the LibreOffice source code
  • Knowledge of the OpenDocument Format standard, particularly in version 1.3.

Other skills

  • English (conversationally fluent in order to coordinate and plan with members of TDF)

We use free, libre and open source (FLOSS) software for development wherever possible, and the resulting work must be licensed under the Mozilla Public License v2.0.

TDF welcomes applications from all suitably qualified persons regardless of their race, sex, disability, religion/belief, sexual orientation or age.

Bidders will get a preference for including a partner or independent developer who has not been involved in a successful tender before.

As always, TDF will give some preference to individuals who have previously shown a commitment to TDF, including but not limited to certified developers and/or members of TDF. Not being a member, or never having contributed before, does not exclude any applicants from consideration.

The task offered is a project-based one-off, with no plans to a mid- or long-term contractual relationship. It is offered on a freelance, project basis. Individuals and companies applying can be located anywhere in the world.

When budgeting, we anticipated that this project (sections A-E) to take in the region of 32 days of work.

TDF is looking forward to receiving your applications for one or more of the aforementioned tasks, your financial expectations and the earliest date of your availability, via e-mail to a committee at tender20201001@documentfoundation.org no later than November 10, 2020.

Applicants who have not received feedback by December 8, 2020 should consider that their application, after careful review, was not accepted.

Tender for implementing support for a dedicated, built-in UNO object inspection tool in LibreOffice (#202007-02)

The Document Foundation (TDF) is the charitable entity behind the world’s leading free/libre open source (FLOSS) office suite LibreOffice.

We are looking for an individual or company to implement support for a dedicated, built-in UNO object inspection tool in LibreOffice, to start work as soon as possible.

In order to make working with UNO objects easier and to avoid the need to always install extensions before debugging, it is necessary to be able to inspect UNO objects in a running LibreOffice instance effectively.

This task involves reading the existing Basic IDE Watch code, evaluating how it can be improved based on ideas implemented in external tools like xray and MRI and extending the Watch code to be a first-class inspector that allows focusing the relevant part of the UNO API for opened documents and also based on your current selection (similar to what is possible in web browsers).

A good part of the features are implemented already. Work carried out under this tender will therefore mostly consist in making the features more accessible and more stable, adjusting the UI and refactoring things.

The work has to be developed on LibreOffice master, so it can get released in the next major version.


The following required features need to be implemented:

  • Dockable toolbar that can appear at the bottom of a document frame, similar to find-bar.
  • Left-hand side of the toolbar exposes a snapshot of a useful subset of the DOM as a tree view: Writer paragraphs, Calc sheets, Impress slides
    • This tree widget should populate its content on-demand whenever possible in order to ensure performance.
  • Point&click inspect mode (similar to F12 in Chrome): combine Help -> What’s this (point on something & then an action) and normal selection, so it’s possible to point on something (e.g. an image), make it the current selection and automatically launch DevTools on it. Perhaps rename ‘DevTools’ to something else.

    Note that this is mostly UI work, ThisComponent.CurrentController.Selection in Basic already gives access to the current selection in a not-so-convenient way.

  • Right-hand side: show details in a table about the current selected item in the “DOM tree-view”, which is implemented as part of the watch window in the Basic IDE:
    • object’s UNO properties
    • object methods
    • supported services and interfaces
  • User documentation for the new dialog is mandatory.
  • Brief developer documentation for the newly introduced classes is required.
  • Whenever adding new functionality, it should be considered if it’s possible to test the functionality with automated tests with reasonable amount of effort.

The following are optional features:

  • Configuration support: remember which tabpage was open last time (properties, methods, etc.)
    • Remember sorting settings (prioritize paragraphs/sheets/slides and other relevant properties or sort alphabetically)
  • Click on value for details: primitive types
    • This is useful if the user selected lots of text for inspection, we can’t show all the content in a table cell, but can if a multi-line edit replaces the table widget.
  • Click on value for details: re-launch DevTools on a sub-object on the right-hand side. This is already handled to a large degree in the existing watch variable code, which represents the object already as a tree.
    • This allows recursion: double-click on a value with a complex type, which has its own properties, methods, etc -> inspect it.
  • Show implementation name of object
    • If a consistent name is provided by the object, this can allow jumping to the relevant C++ code from DevTools easily.
  • Copy&paste support:
    • Normally content of a table in a widget is not easily copy&paste-able. It can help debugging if add explicit support to copy the table content still, e.g. all property names and their primitive values.
  • Improved presentation of the DOM for Writer/Calc/Impress:
    • The inspector tool could be just a generic presenter for any UNO object, but in practice macro and extension authors are interested in a subset of the extremely rich and generic API we provide.
    • The idea is to select a few key properties for each component, so it’s trivial for the user to see how to access the most important details of a document:
      • Writer: style families, paragraph list, text portion list, etc.
      • Calc: sheets, columns, cells, named ranges, etc.
      • Impress: slides, shapes, etc.

Required skills

  • Extensive knowledge of C++
  • Experience working on the LibreOffice source code
  • Knowledge of UNO

Other skills

  • English (conversationally fluent in order to coordinate and plan with members of TDF)

We use free, libre and open source (FLOSS) software for development wherever possible, and the resulting work must be licensed under the Mozilla Public License v2.0.

TDF welcomes applications from all suitably qualified persons regardless of their race, sex, disability, religion/belief, sexual orientation or age.

Bidders will get a preference for including a partner or independent developer who has not been involved in a successful tender before.

As always, TDF will give some preference to individuals who have previously shown a commitment to TDF, including but not limited to certified developers and/or members of TDF. Not being a member, or never having contributed before, does not exclude any applicants from consideration.
Further discussions on this tender took place on the public board discussion mailing list of The Document Foundation.

The task offered is a project-based one-off, with no immediate plans to a mid- or long-term contractual relationship. It is offered on a freelance, project basis. Individuals and companies applying can be located anywhere in the world.

When budgeting, we anticipated that this project (incl. optional tasks) to take in the region of 60 days of work. Bidders are free to bid on the required features only. Bidders who bid on both the required and optional features are asked to provide a breakdown in terms of costs for each.

TDF is looking forward to receiving your applications for one or more of the aforementioned tasks, your financial expectations and the earliest date of your availability, via e-mail to a committee at tender20200702@documentfoundation.org no later than September 1, 2020.

Applicants who have not received feedback by October 15, 2020 should consider that their application, after careful review, was not accepted.

Join our team! Job Search for a Development Mentor (m/f/d) – #202007-01

The Document Foundation (TDF) is the non-profit entity behind the world’s leading open source office suite, LibreOffice. It’s comprised of a team of highly skilled and motivated people, working on infrastructure, design, documentation, QA, marketing and other tasks. We’re passionate about free software and bringing people into our community.

To grow our volunteer community, in particular for code contributions, we’re searching for

a Development Mentor (m/f/d)

to start work as soon as possible. If you’re interested in the role, which is offered on a part- or full-time basis, you ideally have:

  • previous experience in remote work
  • been a long-time contributor to one or more FLOSS communities
  • excellent communication skills, with enthusiasm for mentoring – a fluent command of the English language (written and spoken) is expected
  • coding experience in several FLOSS code bases and programming languages, including LibreOffice
  • demonstrable C++ coding experience of at least five years, plus active knowledge of at least one more language used in LibreOffice (e.g. Python or Java)
  • willingness to regularly travel to Hackfests & conferences in Europe and globally
  • self-driven and a good team player; interested in working together with our team

The remote job role involves working from home at your location and includes among other items:

Work with our existing team in the LibreOffice community on topics including:

  • building relationships between the community and new contributors
  • identifying and on-boarding new contributors
  • affirming and encouraging their contribution
  • encouraging them to join IRC and other communication channels to meet the community
  • building relationships with domain experts for deeper learning
  • attracting new contributors by promoting the project
  • interaction with UX volunteers

Shape and create development mentoring including:

  • helping to onboard new contributors by
    • positively reviewing their code contributions
    • improving their C++ programming skills & design, and coding style
    • introducing them to our tooling and culture
  • designing, and define easy tasks for new contributors
  • maintaining our technical documentation, e.g.
    • developer guide
    • wiki articles
    • code comments
  • helping to review the results of development tenders produced by TDF
  • goals-oriented and with a laser-sharp focus to grow excellent LibreOffice core contributors, our perfect candidate will come up with creative ways to find and attract volunteers

Previous experience with such tasks is highly welcome, so is using free software. Speaking and writing English fluently is a mandatory requirement.

The work time during the day is flexible, apart from some fixed times when availability is required (e.g. during meetings).

TDF welcomes applications from all suitably qualified persons regardless of their race, gender, disability, religion/belief, sexual orientation or age.

As always, TDF will give some preference to individuals who have previously shown a commitment to TDF, including but not limited to members of TDF. Not being a member, or never having contributed before, does not exclude any applicants from consideration.

TDF is looking forward to receiving your applications, including curriculum vitae, your financial expectations, and the earliest date of your availability, via e-mail to tender20200701@documentfoundation.org no later than September 15, 2020.

If you haven’t received feedback by October 30, 2020, your application could not be considered.