How I came to collective intelligence

I plan to share some thoughts about Collective Intelligence from a software perspective. But this comes from an old story that I thought I should make public first.

The origins

When I first began to program web applications, it was mostly for my own needs as an activist (freedom of speech on internet, cryptography, and such matters). Around 1998 I had a fully working solution called ‘Collaborative writer’ or cWriter for short, written in PHP. It was like a sort of wiki geared towards small groups self-organization.

When I got to Claranet I deployed it as an internal solution, and worked on a full company intranet called ‘in’. It was the occasion to release cWriter as open source in 2000 on Sourceforge.

At that time it appeared obvious that my area of preference was about engineering collaborative work. I was putting a lot of thoughts into that. I had this clear understanding that the tool shapes the usages, especially in this new realm that was internet communication.

Later on, I dedicated my time in various projects, mostly Tikiwiki groupware in 2003. That experience was also rich in valuable experiments. I became leader in that community because being unemployed at that time, I took the occasion to just invest time in open source (being payed by labor insurance money). And I was just very prolific. I established various bases for that community that still thrives today. I had a recorded interview with the guys for the 10 years for the project in 2012.

The discovery

Somewhere in 2004 I met with JF Noubel, that had some need for help on his own Tikiwiki instance, called thetransitionner.org. His website (not available anymore nowadays) was dedicated to promotion and exploration of Collective Intelligence, following the work, among others, of Pierre Lévy.

I quickly identified this area of research as something that I was practicing and aiming at, without having formally identified it. So I got more and more interested into that field in the following years.

Jean-Francois became a friend, his approach evolved since then but I still got stuck with his original presentation describing the basics of Collective Intelligence.

Anyways it led me to some other kind of activism, revolving around some alternative currency projects (like openmoney), other projects concerning governance (like democracy 2.0, from Mikael Nordfors cited in the transcript on archive.org), and various other topics that would be too long to list here.

Ultimately it led to get involved in Angenius with Than Nghiem in a background of sustainable development between 2006 and 2008. Including going to live in a farm in Normandy. Which was amazing but I was just not made for it.

The migration

In 2008 I decided to leave France and go live in Taiwan. I wanted to take a break and learn Chinese. It was my decision for my 40th birthday. Since then I got various jobs in development and then in system administration, grinding more programming languages and technical skills. But I still kept all this time the background thinking on collective intelligence.

What I wanted to experience was just another cultural background. I wanted to see patterns a little better about open source communities and collaborative work in a different context. Well. This could be the topic for another post. I got some surprises.

What’s next?

Now, 9 years after, I feel it’s more than time I get back to my past ventures. Well, I didn’t live like an hermit, I’m involved in various local and global communities. But I feel I could share a little more about what I learned in my past experiments. Now that I reach my 50’s, maybe I just feel like I have to begin writing stuff.


The Interviews approach

Interview-based knowledge sharing

For years I noticed the difficulty to extract decent information from developers and craftsmen about their work. Developers clearly lack the skill or the taste for documentation. It extends to the specifications, which also provides an occasion to notice bad performance.

To work this around, specialized project managers have to fill this role, but it can create a gap between developers ownership and the final result. Sometimes luck creates the inspiration and developers produce a decent amount of documentation. But honestly, this is pure luck, and not a rule.

I found a way to mitigate this issue, that I began to experiment some time ago at work. It’s based on a recorded interaction between a project person and a person of the craft.

Here are the rules:

  • the project person organizes interviews with stakeholders from all specialties including developers, business people, operations people, sometimes users, the more diverse population possible. But it can also be done for no reason for sharing a certain kind of knowledge with an expert.
  • interviews take place by written interactive communication in a chat, in a way that enables logging (irc, slack, whatever)
  • it lasts 20 minutes more or less, but the format can extend to hours if the need is felt
  • once the interview is finished, the interviewer cleans up the logs, removes out of topic details, fixes typoes, removes elements that are purely belonging to the chat way of communication
  • the cleaned log is reviewed by the interviewee for consensual agreement on its publication
  • the log can then be added to whatever project space is dedicated to the topic at hand (documentation, specification annexes, study, paper)

There are various beneficial side effects to this endeavor:

  • actors have a better feeling of engagement in the project or topic at hand
  • it creates a bond between actors, facilitates future exchanges
  • it gives an equal chance for everyone to speak, even the shy ones, because the 1 to 1 context is much less frightening. In a meeting, there are people that never speak. Are they stupid? they are not!
  • it creates content that can be shared with other actors so that they have a better chance to understand the point of views of other parties.
  • it creates a useful reference for the project, a raw material which can be annexed and can be used for summaries. It also creates more content for an eventual search engine if the publication space has one.
  • there is less risk to cite someone out of context because the full context is provided.
  • it is much easier to organize interviews or hold them on the fly than setup meetings.
  • there is no feeling of loss of time like in a meeting: the time dedicated is intense and very interactive, there is no waste.

I had the occasion to try that technique in a context where internal communication is not optimal, for knowledge sharing at first, then for exploring options on a new project and set up specifications. I have been happy to notice that this formula creates pretty good output and generates a nice feeling in all parties involved.

Certainly more study will come on this approach. It’s a lot of fun.


Getting back into writing

Enough sleeping

A few months ago, I got tired of leading Greenruby publication and Xenor accepted to jump in and take the publisher role. I’m very grateful about it. But as a secundary effect, I lost that ranting channel I got used to abuse. Each week, I was getting somehow acustomed to send some rant with the list of links.

Now it’s time to get back into a publisher mood. I have various thoughts that could deserve sharing, or at least, publication. Well I don’t tweet much and I hate facebook, so my media coverage may be a little tiny.

But that’s not really a problem. It’s not like I have some agenda. I just wish to exercise my right to reflect aloud on various topics, bring to the open some personal and/or original thoughts. Nothing more. Whoever reads, do it in silence.


Greenruby 197

My lovely Chatbots, sick already?

Recently I have been to a meetup about chatbots. I was expecting something technical. But it seems that I was totally mislead on what chatbots are. They are visibly now more of a marketing tool than just a cool piece of technology.

I’m pretty convinced that web interfaces are going to die slowly in favor of more conversational interfaces. But in past technology shift we had some time between appearance and marketability. Like with the web, the social networks, etc. No more. Chatbots are immediate slaves for sales volumes. All the blooming of new services for ‘building your own bot’ are just totally geared towards customers management and acquisition.

My naive assumption was that assistive conversational interface could have a larger scope. But well, the market is driven by what sells, and what sells is what make more sales. I just hope it will have a nice border effect to improve chatbots as a tool or as a general interface to access information.

But my instinct warns me against the potential invasion of our social world online by all sort of aggressive automated peddlers. The same way we get robotic phone calls. Chatbots are going to be the new color of spam?


Greenruby 193

Is Facebook the new NPM?

This week there is a lot of noise in the JS ecosystem, on various trends. But the most noticeable is about Yarn. Yet another package manager for js, that states it opens a war against NPM (in soft terms but clearly enough). The long post from Facebook about it demonstrates a clear effort to push things forward about NPM shortcomings. The reaction on hacker news is pretty verbose.

It provoked a public response from NPM to try to explain that, nop, it’s not a war. But I keep feeling that Facebook is slowly taking over another piece of the javascript world. For now, it doesn’t seem harmful at all, but my instinct lights a various number of warning bonfires.

But for real, it was more than time that the supremacy of NPM was questioned. It has a lot of flaws and the number of posts about this event proves that the community was kind of waiting for something like this to happen. Like this cheatsheet, various articles like this one, this enthusiastic post from Yehuda Kats. But not everybody is happy about how things are done.

Personally, I like the technical direction it takes. But I hope that like io.js went back to node.js, it will eventually merge back to NPM, really. But I have the feeling it is not going to happen.


Greenruby 192

The JS toolback hell

This week I laughed a lot while reading How it feels to learn JavaScript in 2016. That article had a pretty good response, like it hits a nerve.

But seriously it’s clear that we are at a transition time in Javascript evolution, and there is a huge chaos of possible alternatives to everything. It feels like an ecosystem where the natural selection didn’t operate its magic yet. It’s like there are things in suspension that are going to fall in order at some point eventually.

My personal bet is that things like elm will win the race, because with its embrace of functional programming it seems like it opens the door to interpretation with yet-to-be-written faster and more direct compilers (rather than transpiling to js). But that’s just a hunch.

In the while, front-end craft is now a wizard arcane art. It can’t be acquired by pure reasoning and logic, or reading a doc. You need the map of the landscape for knowing the possible choices and alternative intermediary solutions. For part-time front-end people, it’s just hell. For now.


Greenruby 191

I’m in holidays

Great occasion to kick thunderbird byebye and spend some time on configuring my mutt to make it real again, after 6 years of click-click for mail. I was a mutt user for a very long time, and my pause for trying a GUI mail client just had to have an end. But the mail has clearly become something else now. Actually much more volume, but much more automated things, and news feeds. Or it’s just me?


Greenruby 190

A stress-free life

Next friday, I’ve been told that I have to stop working for 2 weeks. Well, for people that have a normal life and/or kids, it’s a pretty good news. For people that get heavy pressure from their work, it can give some air. But I wondered why I didn’t feel like I ever felt the need for holidays. I take them by principle, but I’m usually not really eager to get them.

After some consideration, it all sums up to some kind of discipline. I refuse stress on a daily basis. I want each day at work to be enjoyable and debt-free. It’s a bad news for some category of employers. The same way those consider it’s acceptable to accumulate technical debt, they apply the same principle on human-life debt. Put people under pressure, get a loan on their health, that will never be repaid. So, I just refuse pressure, the same way I would refuse to eat meat if I was really vegetarian (which I am only part-time).

Really I have more trouble with holidays because they bring a gap in the continuity of work. You get back and there is a lot to catch up on. I would prefer to have just one hour work less per day than week-long breaks. But that’s just me. It would be totally different if I wanted to travel for fun or if I had kids. My case is not reproducible.

But the baseline remains valid. whether you have plans or not for holidays, they should not be required for having a balanced life. Stress has to be fought on a daily basis and not by using breaks. Breaks, in such case, are even more enjoyable, if you have the context for it.

The best way I know to push stress away is to put my efforts into what I do, in a way that I’m self-aware that I’m really doing what I can to fulfill my duties. If someone is not happy about the output, that’s their problem not mine. If it leads to some awkward context, then it’s broken and I will reach out to find a better work context. I apply that principle for more than 20 years now and I can’t remember last time I felt stressed.


Greenruby 189

The art of learning

In my review this week I read that Old Geek post, which has a lot of comments under its feet. This is quite interesting. But I feel there is a confusion here.

From my experience, age is often related to stagnation. The more you accumulate, the heavier you are. It’s heart-breaking to abandon years of investment in one type of knowledge. Therefore, generally speaking, older people are less flexible and less likely to surf on the waves of the new technologies.

But I can tell you as a fact that this is just a natural human law, that, like many others, can be bended. Bended by discipline, the same way we overcome our animal instincts. There are many old practitioners of our skill that became master in the art of change. The sacred art of eternal learning. The wisdom of daily questioning of previously acquired knowledge.

Obsolescence is not a question of age, but just a question of personality, environment and priorities. I know a handful of such oldgeeks that didn’t yet reach their 30’s. And personally (in my 49), I won’t stop surfing any time soon. hahaha.


Greenruby 188

Observability and Digestibility

This is a word I love. I found it again in a recent blog post about system blindness and it reminded me how critical this need is. Our systems get more and more numerous and small. The reliability and debugging of a platform now goes into various loops given the multiplication of actors.

Observability should be one core pre-requisite when designing a service oriented architecture with micro-services. But just having everything plugged to some ELK is not going to help that much. I feel that there is a new job in there. Some function that has to be fulfilled. Something to reduce that vast amount of data into something that makes sense. An intermediary that will correlate logs from various sources. It would put them together and reduce them to some meaningful ‘events’.

So I think observability is not enough. Digestibility is what makes observability worth it. Maybe such tools already exist? Hmm, probably in the containers worlds there is something like that. Is there not?