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 countless projects and, eventually, have a large influence on my career choice - not linguistics, but computer science!

In 2012, as my online involvement entered its tenth year, I started looking back on these projects and their evolution.

My Pre-project - 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 free 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 24 official languages (as of 2021), 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).

In Ido, Ido means "descendant". But for me, my Idist journey was the ancestor of all my activist projects. 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, even worse) 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 and proposals.

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!

The Project

Following Ido, I got involved in various free software projects. Besides the Tiki Software Community Association, I started participating in KDE e.V., the PHP Group, the Apache, Eclipse, Mozilla, OpenJS and Linux foundations, the GNU project and the Linux Documentation Project (TLDP), the Software in the Public Interest (SPI) umbrella project and several of its associated projects, countless more software projects, and even non-software projects such as Wikimedia. The rest of this page used to be a long list of projects I contribute(d) to, discussing their evolution, my achievements and the remaining challenges. As time went by, since my involvement in projects starts, ends and evolves constantly, this list became much less relevant and representative and badly outdated (even to the point of listing some projects I now prefer to distance myself from). It turns out that maintaining even a high-level picture of huge projects reasonably up-to-date is quite time-consuming.

So instead of merely updating the list but leaving it just as time-sensitive, I reflected on why I get involved in some projects more than others. After decades of computer administration and software development, one gets pretty good at choosing which software to use, and after nearly 2 decades of hacktivism, it's almost an expertise to evaluate to what point each component is worthy of contribution.

Identifying rating criteria could be most complex, but project quality factors can be fit in the following large categories. Don't forget there is no such thing as the ideal project; if you're picking a component or a project in which to get involved, use the following to compare options. And if you fail to find a satisfying project and decide to create one, just do your best to respect the following as much as possible. Be aware that if you envision any significant product, you will need help. Your first challenge should be to build a project (and its community), not the product, and even setting up a proper project will take much patience and effort. But there are tons of tools and services to do so, and perhaps even existing projects in which your product could be developed, or which could head your project, such as Software in the Public Interest (Disclaimer

Yes, Software in the Public Interest is one of my (meta-)projects
I also work or worked on several other projects mentioned below.

). Minimizing organizational debt will be a huge challenge and should be a top priority.

Foundations

Let's start with a broad category which contains infrastructure and other well-known basics.

If we're talking about a software project, the implementation technologies determine not only your learning curve to start contributing, but your efficiency at the top of that curve. It'll be much easier to recruit me in a project using modern languages, frameworks and libraries like Python and Qt than in a project based on Perl and Tk.

Where is the source code stored? Is there a version control system? Is it still using CVS? Can you be notified of commits? Can you easily see who's changed what when, and tell who reviewed each change?

Are source code comments written in Latin? And if there's an accessible auxiliary language and you want to get involved, how to communicate with other developers? Is there a web forum or just a mailing list? Is the mailing list open to everyone? Is there an IRC channel?

Are the software and its website hosted on reliable servers? Can documentation be consulted online? Is there documentation for developers? Is it in a wiki, and if so, can you easily discuss issues and perform changes yourself?

Transparency and reliability

After the basics, one aspect which we often initially overlook is transparency. Does the project have a mailing list for announcements or a blog? And if there are forums and mailing lists, are these all open? What share of the internal communications is kept private?

If the issue tracker breaks, are users directed to report to a forum, or to a private email alias, or even a specific person? Are the contact points transparent, or are you unable to tell who's behind, or if they've already been told?

Most importantly, does the project have at least one issue tracking system? Is the ITS presented as a mere bug tracker, or is its scope wide enough? Is there just an ITS for the software itself, or are documentation issues also tracked? Is there a place to see issues with the website? Can all users file tickets there, or is access restricted?

Some projects recognize the importance of transparency more than others, and can be particularly convincing. Point 3 of the Debian Social Contract is "We will not hide problems":

Although a project could claim transparency on paper and turn out more opaque in reality. Do you find many issues which developers marked as resolved but which actually persist?

And what can that issue tracker do? I am more inclined to help a project using Redmine than one which satisfies itself with Bugzilla or GitHub Issues. Does the engine try to track the number of affected users, or offer any way to sort issues by importance, or do you just get an indiscriminate list of thousands of issues? Can you at least filter out the issues which don't affect the version you use?

Is the first important issue you hit already reported? If so, is the report properly handled? Are workarounds clearly documented? Can you subscribe to be notified of new developments?

And what if the project is so fresh it still doesn't have any ITS? Does it at least recognize it needs to setup one and ask for help? Does it have a roadmap?

All projects have to start somewhere. Many will release incomplete products which are far from maturity, hoping to attract users and potential new developers. If the project is still buggy, is it fully transparent about it? Are announces written by a marketing group? Does it announce a new version as stable when it's still full of bugs? Does the website present the product as secure, even though the ITS shows tens of major outstanding security holes which have been reported for months? Will you feel right being associated with a project who claims a top quality product when the issue database shows reports of serious data loss?

Developers are humans, and all projects want to attract new users, speeding up development and attracting in turn more new users. But each project has its own integrity standards. Learn to distinguish reliable information from marketing, and make sure you're comfortable with a project's level of honesty… and that you're not being fooled yourself.

Appropriation

The most performant peer production projects are commons-based, i.e. their products are not owned privately. In the software world, this is achieved thanks to open source licensing. To avoid appropriation, I only contribute to projects whose products are free. OSI licenses and Creative Commons are wonderful tools to prove users that their investment is appropriation-proof.

But even product licensing can be complicated. Many products which are offered under FLOSS licenses come in different editions, some of which are proprietary. And appropriation can go beyond software. Often-overlooked aspects include documentation and dependencies. Do you want to contribute to MySQL's documentation if it's not free? And do you even want to contribute to a DBMS which has no free documentation?

Software dependencies, such as KDE's reliance on Qt, could also lead to appropriation. It's one thing for the software to be free, but its dependencies could not be, as was the case for KDE before Qt was freed.

And even if you're fully protected from appropriation as a user, forkability could be suboptimal if project infrastructure is unduly proprietary. Many projects fail to license developer documentation and wiki contents. The more forkable a project will be, the most resilient its products will be, and the more developers it will attract. And don't neglect project infrastructure. Freely licensing tickets and using a free ITS engine ensure even greater forkability, just like licensing messages on forums.

Governance

But no matter how hard a project tries to maximize commons, minimal appropriation will remain. Hardware used for at least servers, and some intellectual property like trademarks and domain names are not public domain. Do these belong to various entities, or is there a single entity which has control on the whole project?

And what would that entity be? Is it a corporation? If so, is it a company using the software which licenses it freely hoping to attract developers which will spread development efforts? Or is it a software corporation which considers the software as a product at the core of its business model, hoping to find a way to monetize? Does the project have a charter or at least documentation about governance, or does it prove difficult to answer these questions?

Do project resources belong to a single individual? Did that person really create the project by pure altruism? I will be more inclined to join a project led by Martin Michlmayr or Benjamin Mako Hill than the same project led by Richard Stallman or Jimmy Wales. Is that leader aware of the importance of governance, and willing to transfer resources to an NPO if the project has significant ambitions?

Who's allowed to approve changes, and how are those vetted? While it's been criticized for its duration at least at times,
the highly transparent Debian New Member process remains my reference in this area in terms of quality, controlling not just skills, but results, identity and more. If your project admits new developers easily, does it at least get rid of bad apples proactively?

Debian and Wikimedia are examples of projects which are entirely disinterested, but even projects which have a foundation−like Mozilla−can be associated with corporations and eventually derail. How does the foundation operate? Is there a silo mindset and hierarchy? And if not, is decisional power equal for all contributors, or distributed proportionately to each contributor's skills and commitment?

Is decisional capacity sufficient for the project's size? What happens when there's a disagreement? Does it turn into a flamewar where each party tries to have the last word, or is there a mature settlement process? Would polling members involve trying to authenticate mails sent by everyone to a mailing list? Or are developers accustomed to using a secure and efficient voting system which allows them to change their votes whenever they want? Does it support votes advanced enough for the challenges? The Debian project, an early adopter of the Condorcet method for elections and other votes, could once again be considered exemplary in that regard. However, its voting software is not oriented towards convenience, so votes are precise but costly to carry and infrequent.

Purpose

Obviously, defining one's ideal project can't conclude ignoring project goals. This aspect is personal as of course we all have different interests. Mine are mostly development, knowledge, productivity, collaboration and collective decision-making. I would like to help developing liquid governance, in particular software tools to apply it.