Retiring from LFS
Written at 17:03, on Wednesday 21 September 2005. Tags: personal .
This article was originally published on the 9th of December on my old blog. I’ve republished it here to prevent linkrot.
Today, I announced my retirement as the Linux From Scratch website team-leader and as maintainer from the FAQ. It was a hard decision, but now that I made it, I know it was the right one. I had been neglecting my work for months now, always promising to myself and to the community that it would be better when the CMS came. However, I began to realize that the CMS would not come.
When I began to redesign the old LFS website, my goal was to build a site which reflected the dynamic nature of the community. The old site was static, rarely changed, while all the action was happening on the mailing lists. Visitors of the site could never know what LFS actually was for insiders, except by subscribing to the mailing lists. It was my goal for the new website that it would show that, despite that releases were rare, the development was moving very fast and the community was very active.
My redesign tried to achieve this by two things:
- The home page would receive regular news items, which would summarize mailing list discussions.
- Under the news items we would show the latest developments which were checked in CVS (now Subversion.)
There were many other improvements:
- the information architecture of the site was thoroughly revised, giving each LFS-related project it’s own subsection
- FAQ and support was prominently placed on each page
- validation to XHTML-1.0 and CSS was achieved
- multiple layouts via CSS
- mirror usage was enforced, thus reducing bandwidth requirements
- the search functions for the mailing lists were dramatically improved
- accessibility via access keys
- a lot of content was rewritten or written from scratch
(More changes were collected at the website page)
The website reflected not only the community at that time, but also my personal skills in website development. I quickly got help from some people in the community to work on header graphics and help with some server-side coding. Nevertheless, even as it launced, the website had some minor flaws, like compatibility problems with Konqueror and Internet Explorer, although these were fixed incrementally. And it had some major flaws, which were harder to fix, or not fixable at all without major reworking of the basis.
The major flaw was the maintenance. Each page was completely hand-coded in XHTML. Adding a new page meant that we not only had to construct the new page, but we also had to adjust the sitemap and the navigation on pages in that section. Adding a new section was even harder. To glue the whole website together, various pieces were dynamically added from other repositories through scripts which would reconstruct the website and remove the old one. There were various incidents when the reconstruction didn’t work but the removing did. Another flaw was that news items were only added when there was a new release. Adding a news item was hard and error-prone due to arcane syntax. But we were working on something which would remedy all these problems.
The CMS was an idea which originated at the end of last year, when the burden of maintaining the LFS site actually became felt. We figured we should adopt an existing solution so we wouldn’t have to build anything ourselves; we already saw that we couldn’t keep up with the demands from the community. We started out with Wordpress and Drupal, and played around with it. The needs of the LFS community were very divers, and we wanted to integrate the website with the community even more then was done already.
At that time, I also gained interest in the Wiki concept, and tried to push it to the community, first as complementary system for the mailing lists, later on as replacement for the website. The idea was to give users control of the content. As discussions on the mailing lists became off-topic or reached closure, the knowledge which was gained from them was quickly forgotten. And not even long-time community members would always search the archives before posting a question or repeating a discussion which was long since closed. To remedy this, I proposed a Wiki which would receive this knowledge, and which would grow incrementally as the knowledge representation of the community.
There was just one problem: the community didn’t like the idea at all. The project is called “Linux From Scratch” and it teaches people how to get control of their systems. Most of the community members are control freaks, and a Wiki is the epitome of anarchistic proliferation of texts because it allows everybody to be not just a reader but also a writer. I never let the idea go completely, although I mellowed down after community critique. We chose TWiki because it didn’t require a database (and was thus easy to mirror), was extensible with plugins, had a template system to adjust its appearance and because it had rich access control lists. Many of the functions which the website performed could be easily fitted into TWiki, but with a lot of benefits. Adding of pages or sections was a matter of minutes instead of hours. It also didn’t require extensive knowledge of XHTML or the peculiar way the site was built. Adding dynamic functionality was a snap. The ACL’s could be hooked to the existing user management system on the server, which meant that project leaders and members would automatically gain the right to add or edit pages or sections.
Unfortunately, TWiki was never truly accepted by some members of the community. The Wiki part was a big factor in this. However, the biggest objection was that it was capable of doing too much. I never really understood this objection, and it was never completely articulated, until some other project members put forward their idea of the website. It featured very little content, no dynamics and resembled the original site a lot. Yet, it was welcomed because of its simplicity.
At that point, I realized that I worked towards a different goal then was required or even needed by the community. I saw no other choice but to quit as team leader. I still think the website should reflect the dynamic nature of the project and the community. However, the website should also serve the needs of the project, the community and its users. If a web designer can’t connect or relate to those needs, then perhaps it’s better the if he just quits. The fact is, I simply don’t have the time nor the interest anymore to be an LFS-er. I’ve learned a lot in the process, and I’m grateful for those who supported me. But it’s time for someone else to put his ideas forward, someone who is still very into building LFS systems, who is still very much a community member, and understands the needs of the community and the know-how to translate these needs into an effective website. There’s really not much more to say.
I’d like to thank Anderson Lizardo and Craig Colton for helping me build the website and sticking with me all the time. I’d also like to thank Gerard Beekmans and the LFS community for giving me the trust and freedom to built the website as I saw fit for the community. I’ve received many positive responses and have learned a great deal from it.
Comments closed | Permalink