In 1998, doing some schoolwork, I heard about constructed languages and Ido, about which I got curious. 3 years later, I satisfied my curiosity and learned Ido. Little did I know that this anecdotal decision would get me involved in many projects and, eventually, have a large influence on my career choice - not linguistics, but computer science!
Now in 2012, as my online involvement enters its tenth year, it's time to reflect on these projects and their evolution.
Table of contents
Ido, the universal auxiliary language
See first: Introduction to a common human language
I was 16 years old when I learned Ido, a constructed international auxiliary language. I knew French, my English was decent, and I still remembered quite a bit of Spanish. I found Ido to be extremely regular and concise and incredibly easy to learn. I fell in love with the language and its intellectual community, and Ido became the first project I was involved in.
Ido was created in 1907 but never had much adoption. Its popularity peaked in the first half of the 20th century and declined progressively in the second half, until the diffusion of the Internet to the public. The Internet saved the dying project, but came very late.
The Web was young when I learned Ido in 2002, and Ido's presence on the Web was very weak. The Idist community consisted of fairly aged people, many of whom simply weren't using the Internet. Most of those who did had limited knowledge of IT. The community used several small scattered websites. For readers who remember the regretted "Web 1.0", some of the main websites were hosted on—ahem—GeoCities and cough Angelfire cough…
My first project for Ido was to give it a central website based on a content management system. I chose Tiki, an open source CMS including a wiki engine. I started IdoWiki using Tiki, but I hit many problems with Tiki. In fact, Tiki was at the time a beta product. I ended up investing more time in Tiki than in IdoWiki itself.
Another problem of Ido was its lack of dictionaries. The French to Ido dictionary was only half digitized, and the digital format was inconvenient. I intended to provide Ido a dictionary platform and to finish digitizing the dictionary, but it turned out that the OCR software of the time did not perform terribly well with fonts from 1915… I never contributed anything to the dictionaries in the end.
The Idist movement obviously dogfooded Ido for its internal communication, and I wrote a little about technology, free software and how it could help the movement. I quickly realized that writing in Ido about specialized topics such as computers was very difficult. Ido has a limited technical vocabulary, in particular for concepts which appeared in the last century. In 2003, Ido had no official word to designate a computer. There was about one person working part-time to expand the vocabulary, which grew very slowly.
I came to realize that the project not only needed work to expand its learning resources and increase its usage, but all this needed to be done with a largely incomplete language, by a community which was tiny.
The European Union has 23 official languages (as of 2012), a number still on an upward trend. I never stopped believing that Ido would be a great solution for global communication, but as my perception of the efforts needed to achieve its goal changed, my interest in the project faded. I now believe that for a universal auxiliary language to happen, things must start with a realization of the problem and a political decision to do something (which—unfortunately—the World's current political system is not in a position to make).
I do not regret my involvement in Ido, but in the end, I did very little for the project. Ido probably had a more lasting influence on me. IdoWiki never came to light, but as I'm writing these lines, I note that the Uniono por la Linguo Internaciona's website is now powered by a (different) free wiki engine. Regarding dictionaries, Idists moved most of their efforts to Wiktionary, which was barely created in 2003, but is now mature and still developing strongly. This appears to have been a great decision. The movement seems to be going in the right direction, but very slowly. As of April 2012, only 8 new words were accepted since 2001. There is still no official word to refer to a computer in Ido, despite several discussions.
All projects to which my Idist adventure led me used English as an auxiliary language. I experience this problem daily in the poor quality of communications, and sporadically but strongly when statistics on the origins of contributors highlight how rarely non-Western individuals get over the linguistic barrier. I salute volunteers who continue to be involved in the Ido movement and in similar IAL projects. Samideani, esez kurajozega e maxim sucesoza!
Tiki Wiki CMS Groupware
I started a website for Ido in summer 2003 and picked Tiki, an open source content management system featuring a wiki engine. Tiki was then a new project, but it already offered amazing functionality and flexibility. Its only problem was its quality—or lack thereof… Fortunately, the project behind the product was very open. I started triaging issue reports and helping users. Before I had the time to realize Tiki was still in a beta phase, I was recruited as developer. To this day, Tiki remains the most open software project I have seen.
Eventually, I contributed a one-character change to a file, fixing an HTML syntax error, which became my first contribution to a real software project. Tiki would be the first project I would seriously help. I learned PHP and was then able to contribute to its stabilization. I enjoyed working on Tiki and spent a lot of time on it for a while, but I stopped my involvement in 2004 to focus on my studies.
Tiki was the first open source project I was involved in and it made me discover a lot about open source software, particularly its development culture. I started to use GNU/Linux during that time.
I came back to the Tiki community in 2009 as a freelance developer and consultant. The project had of course modernized a lot, was more mature, and has kept developing at a quick pace since. During the 3 years I worked with Tiki and AvanTech.net, I focused on maintenance and coordinated Tiki 8's release. I also worked on improving the support for Microsoft Windows, and got Tiki in Microsoft's Web Application Gallery.
Debian, the universal operating system
My involvement in Tiki made me discover GNU/Linux, which I started using in 2003. This was the first time I used an operating system other than Windows, and I found it quite challenging in the beginning, but persevered. I first used Mandriva, but in 2004 I was convinced to give Knoppix a try. Installing Knoppix to use as a main OS was not a great idea, but it led me to try Debian, which I still use as my main operating system.
I loved Debian's universality (modularity, flexibility, portability and comprehensiveness), its social contract and its quality. In particular, I found the suites system (stable, testing and unstable) fantastic. I have almost always used testing (mostly a rolling release) for my PC, allowing me to stay quite up-to-date without sacrificing too much stability.
The Debian project is run by volunteers. I was also attracted by the project's openness and transparency, and gradually got involved. The project's size and complexity is challenging, but I find it interesting. I never took an official role in Debian, but over the years, it became the project in which I invested the most time. I initially did lots of user support and issue tracking. Later I focused more on releases (tracking "release-critical bugs" and migrations to testing). I also did some work on documentation and communications. I continue to be involved to a certain degree, as free time allows.
In 2004, I joined a project in crisis. The next release, 3.1, would only get out a year and a half behind the originally scheduled date, and be largely outdated on release. Communication problems, conflict and dysfunctional teams plagued the project, and the belief in a cabal involving various people and teams was widespread.
As of 2012, releases remain somewhat problematic as for many software projects, but the problem is no longer critical. However, communication problems and conflicts remain too present. Debian's governance is theoretically fairly well designed, with a constitution giving each "Debian Developer" equal decisional power. This system can be considered as a basic form of meritocracy or as some kind of "democracy". A Condorcet method is used in votes. But in practice, the body of developers is only a pure direct democracy and the constitution defines a single representative, the Debian Project Leader. This officer, who represents a project consisting of 1167 official members as of 2012, is elected for a one year term. He is a volunteer, usually with a full time job in parallel. He is charged with representing members generally (both internally (as decision-maker) and externally (as spokesperson)). In the 12 elections from 2000 to 2011, the leader in office did not propose himself again 6 times, half of the time. The leader in office was reelected for a second term 4 times. No leader proposed himself again after its second term.
As for direct votes, the voting system is DeVoteE, an old, custom and email-based system. After a member proposes a resolution, other members must sponsor the draft resolution, the project secretary must intervene and a quorum (47 as of 2012) must be reached. The minimum time between a proposition and its adoption is generally 1 month. In the end, as of 2012, 34 proposals were decided in the 13 years under the constitutional system. Excluding those related to the project leader, 18 proposals were decided. In comparison, the system of hybrid democracy in Switzerland had 550 referendums from 1848 to 2011, averaging more than 3 per year.
In other words, decisions in Debian are less based on votes than on
The combination of weak representative decision-making and weak direct decision-making adds up to a weak decisional capacity. When contributors are not unanimous, choices are often decided solely by those with control over the relevant system. This conflict-prone system has made it difficult to maintain the motivation of volunteers. Likewise, communication of the project's official stance on some issue is very difficult, unless that issue is in the scope of one of the project's teams.
Problems with the release process were/are clear and acknowledged. Since 2004, the situation has improved tremendously. Library transitions were hugely facilitated with the introduction of library symbols files making dependencies much less restrictive, with the creation of several tools for transitions and with better coordination. The addition of version tracking to the bug tracking system was a huge step forward in testing's management. In general, improvements to the testing migration tool (britney) made testing easier to manage and the release team's work is getting less manual and more decisional. The tendency to let support for minor computer architectures hamper the progress of testing and therefore of the project as a whole largely disappeared. The workflow to interact with the team was also much improved. The team itself has improved a lot, expanding its membership, although the turnover is high, still more manpower would be needed and roles of members are not clear. One particular weakness which remains is planning and coordination with packagers. As of 2012, there is still no release schedule kept up-to-date. Overall, the release process is very far from the 2004 situation, and still improving.
As an organization, Debian is mostly transparent. Point 3 of the Debian Social Contract is "We will not hide problems":
Reports of bugs in Debian are indeed filed in a public issue tracker. Also, the vast majority of discussions about Debian's development happens on public mailing lists. However, some development mailing lists are private, most famously debian-private. Another problem which is less known but which amounts to a larger issue is the usage of several private email aliases by Debian teams. Core Debian teams (such as the archive maintenance team, Debian Account Managers and the mailing lists administration team) consist of a handful of members, usually with 1 or 2 of them active. The private operation of Debian teams makes it difficult to detect problems in teams and to know when intervention is needed, for example because no active member remains. Private email aliases are also a huge missed opportunity in comparison with forums that would passively ensure some knowledge sharing. Knowledge sharing starts particularly weak in an organization that has almost no oral communication among its members. The fact that the project has almost no physical meetings and no hierarchy also makes it very difficult to assess the health of teams which lack transparency. Finally, transparency, as a source of accountability, is extremely important since contributors have in general very little personal interest in contributing, and need to be convinced that the project operates efficiently and fairly to be motivated.
The project values openness, and therefore transparency. It is relatively aware of its shortcomings in the area. In 2005, it resolved to declassify messages to debian-private after 3 years. Usage of private email aliases is less seen as an issue, but the project leader gave advice clearly against it in September 2011, in private email aliases considered harmful.
The project is well aware of problems in its teams. In 2008, the project leader ran a survey of teams and published a "summary of a summary of the results". Results could not simply be published due to a promise of privacy to respondents. The results published were very summary, but allowed to confirm important problems in teams. The project leader then helped address some problems with broken core teams. No new team survey was done since. However, in 2011 a Google Summer of Code project worked on automating the monitoring of team health. Although the project wasn't completed during the summer, a new Google Summer of Code project to finish it happened in 2012. As of September 2012, the project has progressed and started to collect data and to publish it crudely, but is still far from having delivered an easily usable "teams health dashboard".
As for the debian-private mailing list, the project repealed its resolution to declassify it in 2016. There was also no action taken regarding private email aliases, as of January 2012. In general, the project has been fairly transparent for a long time even when compared to similar projects, but has been very slow to improve.
Discussion is another challenge for Debian. The project exclusively uses mailing lists for development discussions. Even though these happen on hundreds of different mailing lists, the general discussion list has a huge traffic. In March 2005, at the peak of the project's worst crisis, debian-devel received 2824 messages on 304 different topics. Although this example is one of the top months of activity on debian-devel, it is relatively representative of the volume of discussion. Simply following discussions takes a lot of time.
This problem was diagnosed by Jurij Smakov, who wrote Voting on messages: a way to resolve the mailing list problems in 2008. In 2009, he created the Debian mail voting project to address this issue. Although this project did not and - in my opinion - will not get anywhere, I'm hoping that a solution with a different approach will be implemented one day.
See also: Information overload and filtering
Decisional capacity has been discussed a little. In terms of improving leadership, some have suggested and campaigned promising to create a "DPL board". In 2006, project leader Anthony Towns named Steve McIntyre as Second in Charge (2IC).
In 2009, Steve McIntyre and Stefano Zacchiroli were the two DPL candidates. Zacchiroli's platform said he would look for a 2IC if elected. McIntyre ran with Luk Claes as (candidate) 2IC and was elected. In 2010 and 2011, Zacchiroli, possibly unimpressed with Claes's accomplishments, ran again but his platforms said he would not create a DPL board nor look for a 2IC. He was elected for these 2 terms.
After the second DPL election with a single candidate, I blogged about the downward trend of the number of candidatures in 2016.
As for improving votes, Jeroen van Wolffelaar started an unofficial experiment in 2005 to create a "lightweight" alternative to general resolutions, polls. Polls also use DeVoteE, but do not need a discussion period, and the results are live. In 2006, he conducted a poll about the issue of sourceless firmware. The poll's results were the same as the results of a general resolution on the same issue which followed. Nevertheless, this was the last poll conducted. After 3 polls, nothing more happened on that front. As of 2019, Sam Hartman, who was elected as 2019-2020 DPL, is trying to weight collective will using "consensus calls", through which he hopes to build consensus by acting as "discussion facilitator"... good luck with that, Sam!
I believe liquid governance would tremendously help with management issues and permanently improve Debian's decisional capacity. In fact, I believe Debian, already an early adopter of the Condorcet method, may be the ideal testing ground for a liquid governance system.
When a veteran Debian user advised me to drop Mandriva, in early 2004, he didn't advise me to install Debian, but rather a distribution merely based on Debian (Knoppix). Progress may seem slow to some at times, but a lot has changed since 2004. What happened to me (as well as many others) then would no longer happen. The work we've done in 8 years is amazing.
I dare to hope that by 2020 we can say the project solved many more issues and that the product has improved even more.
Wikipedia, the free encyclopedia
Introduction: Free content
I do not precisely remember when I discovered Wikipedia, but it was still in its infancy. Besides the home page, all pages were clearly part of a wiki in the old fashion, with red links all over the place. The project was so ambitious and still so immature that I did not add it to my plate at the time. I only started getting involved in 2004.
I never took an official role in Wikipedia, although I maintained some articles on the English Wikipedia. I found Wikipedia's rise to encyclopedic domination surprising, and still consider a wiki created by volunteers becoming the world's most valuable information resource as a very inspiring success.
Wikipedia nevertheless has important quality problems. History has shown that even though the open model probably gives lower quality, it gives better results than Nupedia's model (selective and "elitist"), but I think a balance between these extremes of editors selectivity and reviewing requirements is preferable.
As in all open wikis, troublemakers reduce quality and cause lots of wasted efforts from editors, often via vandalism. On the vast majority of pages, Wikipedia only has "soft security" to counter troublemakers. There is little defense against sock puppetry (related: Globally verifiable identity). However, Flagged Revisions (a MediaWiki extension) promises improvements to reliability by providing a (relatively) hard security while keeping articles (mostly) open to contributions from everyone. Pending changes are in usage on the English Wikipedia since 2012, but only on very few articles. Unfortunately, an August 2012 editorial uses Flagged revision to exemplify the Wikimedia Foundation's software failures.
The other major source of inefficiency and low quality is the lack of a collective decision-making method. As Wikipedia says, "Consensus is Wikipedia's fundamental model for editorial decision-making."… when no "consensus" (a clearly dominant opinion) exists, no collective decision is taken. Wikipedia's Arbitration Committee (its ultimate dispute resolution instance) acknowledges:
Establishing a wiki democracy or a meritocracy would largely solve conflicts. Unfortunately, setting up a democracy in an open Internet community is non-trivial, as one person can create several accounts and gain more than their due share of power.
Setting up a meritocracy is also politically difficult as it removes the current equality of status among the majority of editors.
If some division of power could be agreed on, voting systems could then be used to take decisions. Integrating such decision-making in the wiki engine would make edit warring a souvenir from a barbarian past and hugely increase quality and the productivity of contributors. Voting on changes discusses this idea, which isn't as futuristic as it may sound.
Progress made during the 10 past years was unprecedented. I cannot imagine going back in time just 10 years ago to work with the resources and tools available then. I'm excited by the work done on my projects and countless others, and I'm proud to have played a part.
For the decade to come, I wish the pace of progress can keep up, and I hope to be able to participate. Hopefully, my projects will keep improving and I can keep playing some part in that. I hope that many new projects will emerge and I hope to participate in some of them, in particular projects fostering better governance and modern decision-making. I would like to help developing liquid governance, in particular software tools to apply it.