This document tries to outline the requirements for a review of the FSFEs website, planned to happen in 2018. It outlines some of the thinking that has gone into this, but it also forms the outline for a tender which would be published to ask individuals or companies to make bids with proposals for how they would suggest to help the FSFE reach the vision of our website, and what this would cost the organisation.


The FSFEs website is our window to the world, a showcase of our activities and the entrypoint for anyone wanting to learn more about our activities, support us, or volunteer time to our cause. We do not expect everything to be published on our website: individual projects and activities may present their activities elsewhere (on the FSFE wiki, on a separate website, or other), but everything the FSFE does, from local activities to global actions, should be easily findable through the website.

Our website should be easy to translate, keep updated, and be available in as many languages as possible to allow people of different backgrounds to access information about our work in their local language. Being a translator is often the first volunteer job someone has in the FSFE, and supporting the translators in this work is important for our retention of volunteers.

We would prefer to build our website on tools which are readily available and which require little or no coding to implement for us. This makes maintenance easier and ensures the FSFE avoids lock-in to individual vendors. That whichever solution is used should be Free Software goes without saying.

Why we're doing this

Our website has been built, since our founding (with a rewrite in 2016-17), using an intricate build system relying on XSL transformations for website design and source documents in XML format. It is currently functional but relies on expert knowledge to maintain when it breaks. It only has limited tools in place to support our translators in their work, and it's become clear that it's also sometimes difficult for everyone to work with XML files, and we would favour other formats like Markdown for updating content.

We do not rule out the possibility that some of this work can be accomplished by rewriting, adapting or complementing our existing tool, but proposals which include building on our existing tool should take into account long term maintenance and provide reasonable indications the FSFE would be able to procure the necessary competency for maintaining the website from several different vendors in the future.


To support this work, we may create three or more tenders, a rough indication of which follows.


These are our overall requirements for our website. Some of this would be managed separately of the tenders above, and would be work the organisation needs to do itself. These are marked with the tag (OWN).

Design requirements

Technical requirements

We try to not include too many technical requirements, as we believe it must be up to those who actually know the technology to make the determination of what best meet our vision. However, there are a few topics which are particularly important to us.

Data format




CGI Scripts (OWN)

The current website makes use of a number of CGI scripts to perform certain functions. Most notably this is the case for our Expense Request system, Event Submissions and our Webshop. We envision that in the process, we would have to migrate these to other services such that they are no longer part of the website itself.

For instance, our webshop might then move to a self-hosted, simple, e-commerce solution, which would mimic the style of the FSFE website, but for all intents and purposes be run separately.

Editing part

I did not know where to put that, but wanted to make sure we do not forget about them.

Misc Points to be transferred to relevant sections

Teams/Web/Requirements (last edited 2018-01-03 15:16:26 by paul)