20 years ago tomorrow, the website for the first IMC (Independent Media Centre) went live at www.indymedia.org, providing a globally accessible platform for independent media coverage of the protests against a WTO summit in the US city of Seattle. Appearing even before the creation of Wikipedia and its MediaWiki software, Indymedia.org was a pioneering example of the then-novel concept of the web as a read/write medium - where anyone could contribute using basic cut’n'paste skills - rather than just a collection of read-only pages made by geeks. Seven years before the founding of Wikileaks, the open-publishing newswire on indymedia.org was one of the earliest forerunners of “citizen journalism” platforms. It can also be seen as one of the earliest experiments in both the practices and technologies of “social media”, producing among other innovations, the technology that gave birth to Titter.

That drive to empower people to create and share was reflected in a commitment to using software that was open source (a newly coined term at the time for Free Software, or as I tend to call it free code) and this became one of the core Principles of Unity for the emerging IMC network. Indymedia.org started out running on a patchwork of webserver software known as Active, originally strapped together by a collective of hackers in Australia, for a local cluster of activist news and event announcement sites. As more IMCs started up to run open-publishing activist news sites for their city or country, this bleeding edge software was gradually replaced by a variety of CMS (Content Management Systems) written specifically for Indymedia, before these were in turn replaced by more general purpose free code CMS like Drupal.

I could into much more detail on all of this from an insiders perspective, and in some ways this would be the ideal time to finish writing up a detailed retrospective article I’ve been planning about the Indymedia network and my time as a founding volunteer for the Aotearoa IMC (which ironically seems to be down today - maybe because it’s already N30 there?). However, I’m currently busy preparing for a long international trip, home to Aotearoa to see family and friends, and then back to China via the FOSS Asia Summit in Singapore. Besides, I’m already seeing plenty of articles being published to mark the 20 year anniversary, so I think I’ll keep my powder dry, read a bunch of them, and focus my piece on any aspects of the Indymedia story that don’t get as much attention or fanfare as I think they deserve.

It has to be said that at 20, the Indymedia network is a shadow of its former self. Many of the sites that served the news gathering of local IMCs, as well as most of the servers that provided collaboration tools for global networking, are long shuttered and gathering digital dust. I haven’t been actively involved in the Aotearoa IMC I co-founded since about 2007, and although the site continued to operate (at least until very recently), I stopped publishing there altogether when the newswire became a flood of seemingly unmoderated noise, dominated by a handful of chronic spammers. But there are signs that a phoenix could rise from the ashes. Indymedia.org, which had until recently been frozen in time since 2013, now bears as promise that “Indymedia.org is being rebuilt”, along with links to a bunch of 20 year anniversary articles.

As with the CMS, so many of the technologies Indymedia activists wanted and needed during the first few years of the network have now been developed to greater maturity by open source communities.

When activists started publishing their videos on YouTube to get them to a larger audience, and to reduce the strain that streaming large media files placed on Indymedia servers, Indymedia geeks dreamed of having a decentralized, free code tool like PeerTube. One that can be used to run video-publishing sites that are independent, but federated into a larger network. Where videos can be found and viewed across the whole federation, not only on the one where it’s first published. Where sites can mirror each others’ videos to route around attempts at censorship. Where users contribute a little bit of their own bandwidth to help the servers if a video goes viral, avoiding the lose-lose scenario where every time you get a video out to a large audience you lose money, or risk having servers go down and sites go offline. Where video channels can be followed and videos commented on by users on other federated platforms like Mastodon. 

But technology was never at the core of Indymedia. The sites we ran were more than blog farms, they were always understood as  a means to a larger end. When we said “don’t hate the media, become the media”, Indymedia activists were articulating a vision of democratized media that could have a democratizing effect on a rapidly globalizing human world, one whose politics and everyday life was becoming increasingly ruled by corporations.

As the public - and especially activists - become increasingly aware of the downsides of Surveillance Capitalism, we have a unique opportunity to remind them of this vision. It’s also worth reflecting on the Achilles Heel of the Indymedia project; it’s lack of a sustainable economic base, and the resulting dependence on donations and volunteer time to keep its growing infrastructure running. For the grander vision that animated Indymedia to be realized, sharing economic solidarity strategies like forming Platform Cooperatives will be just as important as promoting the potential of decentralized technologies like PeerTube and other fediverse tools like PixelFed and Mastodon, perhaps even more important.

Here’s the report for our fourth voice chat testing session. So far we’ve been publishing these reports on write.as, which theoretically allows them to be seen from the fediverse, although I haven’t yet figured out how that’s supposed to work. One of our members has set up a Hubzilla group, which we intend to start using for organizing ourselves and publishing our reports in a way that will be easier to find and search through. More details once I’ve figured out how to join and use it myself ;)

Despite growing the number of people lurking in the Matrix room, we only managed to get two of us together for this test. Three people is enough to determine whether an app can do group chat at all, but to really stress test group chat functionality, we need groups of 5 to7 people, if not more. Hopefully we can get some larger groups together for testing sessions after the holiday season is over, and folks aren’t so busy.

Sunday 9 November, 2019, 12:00 UTC

Candidate: Linphone

Previous Session: Test Session #3

Comments by: @strypey@mastodon.nzoss.nz

VOICE (VOICE Organized Investigation of Chat Engines) is an informal app testing group, trialing free code apps to see how well they handle voice chat, especially with groups. We aim to have a group chat testing session at least once a month, usually during the weekend, although other times can be set up if anyone is keen. We currently use a Matrix room to confirm the timing of testing sessions, as well as for discussion about available apps and related topics: #voicechat:matrix.org

For our fourth testing session we had only two testers, one in Europe, and one in China. Both testing with desktop GNU/Linux and an Android/Linux mobile device. We had decided to test Linphone, which began as a desktop voice calling app for GNU/Linux (thus the name; Lin[ux]phone) that works by connecting to a SIP server. As the project evolved, it has developed mobile versions, added video chat, and more recently text-based instant messaging too, all using the SIP protocol.

As far as I understand how SIP works, we would have been able to chat to each other using accounts on different SIP servers. But for the purposes of this test, we used SIP accounts provided by linphone.org, to ensure that unusual compatibility issues between Linphone and a third-party server didn’t prejudice the results of the test. Because only two testers were available, we weren’t able to test group chat, so this report focuses on the overall UX and the performance of the one-to-one group chat.

The first thing that became very clear is that the GNU/Linux version of Linphone doesn’t get the same level of developer priority as the other versions. I have been unable to get GNU/Linux Linphone to connect to linphone.org at all. Whatever I tried, it would say it couldn’t open the port it was trying to connect through. In my case, that may have been because I was using an outdated 3.6.1 release, installed from the Trisquel 8.0 repos (based on Ubuntu 16.04). But Naughtylus was also unable to get Linphone working on GNU/Linux, using the 3.12 version available on Nix. In the end, he resorted to using WINE to run the Windows version (4.1.1, using Qt 5.9.0 and “Core” 3.12.0).

After I gave up trying to get the GNU/Linux app connecting, I switched to the Android app, which I installed from F-Droid. I had an odd issue where it wouldn’t install the latest version (4.0.1), so I installed the last version before that, hoping I could then upgrade. Nope. A few days later I refreshed my F-Droid app (long story) and was able to upgrade, no idea why it wouldn’t work before that. Anyway, for this test, I was using Linphone 3.3.2 for Android.

I found the Linphone app to be very demanding of permissions that I’m not sure it needed. It’s totally understandable that it asked for access to the microphone when I actually started a call. But as soon as I opened the app it wanted permission to use my camera, and asked twice. As soon as I tried to add Naugtylus as a contact so I could try calling him, the app wanted permission to access the device’s default contacts app. This is the first chat app I’ve installed from F-Droid that seems unable to handle its own contacts without demanding contacts permissions.

So I got Naughtylus to call me instead. We were able to have a sustained voice chat for more than half an hour at a time, with me on Android, and him calling from both the Android version of Linphone and the Windows version running in WINE. I’d be curious to test Linphone again with a group, after we’ve done some investigation on how to get the latest versions installed and working, and maybe set up SIP accounts on different servers, so we can test SIP federation.

Overall, I’d rate my first voice chat experience on Linphone as about equivalent to using Jami or Tox. On all three, audio quality and call reliability is pretty good, but the UX has room for improvement. I wouldn’t recommend any of them to a non-geek average user at this point in time. But in the case of the Linphone team, that probably wouldn’t cause many tears, as it seems like their main target users are businesses paying for support contracts.

Filed November 27th, 2019 under free software, open source

 There’s been a lot of wailing and gnashing of teeth over the last few months, about how to deal with an infamous, far right social network site. Before I say anything else, I want to make it clear that my politics have been staunchly leftist and anti-racist since my childhood. I find the politics of the site in question appalling, and I have no intention of promoting their toxic brand, even when criticizing them, so I will refer to it here as Cess.pit.

 A little background. As my three regular readers will know, I’m an excitable champion of the federated social web, the fediverse to its fedizens. Unlike users in centralized platforms like FaceBook or Titter, users of the fediverse join an “instance” - a server running web software compatible with fediverse protocols like ActivityPub - but they can follow and communicate with users on other instances, run by completely different people. A few months ago, Cess.pit moved its users to a fork of Mastodon, one of the most popular of the various software projects that use ActivityPub, potentially allowing them to recruit from and harass users on other instances.

 The admins of many instances responded to news of this by adding cess.pit to their blocklists. This isn’t unusual. The servers that host our email use blocklists all the time against mailservers that send lots of spam or virus attachments. I believe that the power to block users and instances ultimately belongs in the hands of the users of social network software, but given the current state of federated network software, I’m fine with instance blocks. So long as they’re being used by admins to prevent things like spamming, flooding, and harassment, for the benefit of their users, not to police who their users can communicate with, for ideological reasons those users may not agree with.

  I think it’s worth pointing out that treating all Cess.pit users as if they were all committed fascist organizers does have downsides. A lot of young or politically naive people wander into online spaces like Cess.pit without really understanding how deep those particular rabbit holes go, and these are the “prospects” the actual fascists hope to indoctrinate and recruit. If Cess.pit is federated with at least some instances that aren’t full of fascists and sympathizers, prospects will be much more likely to get access to other perspectives, making it more likely that they will broaden their minds, realize who they’re hanging out with, and get out. If the only people users on Cess.pit can talk to is each other, chances are that actual fascists will find indoctrination and recruitment much easier.

 The other thing that happened is that the developers of Tusky, one of the mobile apps that can be used to connect to instances of Mastodon (and other fediverse software that uses the same system for communication between apps and servers), decided to add a blocklist to their code and add Cess.pit to it. I wasn’t the only person who was sympathetic to their reasons for doing this, but concerned about the possible unintended consequences. Let’s unpack that a bit.

 Let’s say a Bad Actor wants to shut down queer leftist GroupX and stop them communicating online. They publicly smear them as “terrorists” or “spreading kiddy porn” or whatever, and start approaching hosting platforms and software developers, demanding they take action to stop GroupX using their tools.

 Let’s say they approach Mozilla about building anti-GroupX blocks into Firefox, during the time when Brendon Eich was CEO. Brendan is going to say “no”. Because even though he’s right-leaning and may well disagree strongly with the politics of GroupX (which is why he was forced out of the CEO role at Mozilla), there is a longstanding principle in internet tech that we don’t implement political blocks at the level of code and network protocols. Those are decisions to be made autonomously by users (network or “bottom up” decision-making), not centrally by engineers or system administrators (pyramid or “top-down” decision-making).

 The principle does mean, in theory, that free code developed by leftist anarchists could end up getting used in some way by fascists. But unless you empower the state to maintain a register of fascists and stop them using the net at all, it’s unavoidable that they are indirectly using all sorts of free code, developed by people from all sorts of backgrounds, who have all sorts of reasons to be horrified by the idea of fascists using their code.

 When you stop and think about it though, its obvious that the opposite is going to happen much more often. Radical leftists do not develop the majority of free code software. Every day we are directly and indirectly using all sorts of free code, developed by people from all sorts of backgrounds, who have all sorts of reasons to be horrified by the idea of us using their code. But they don’t try to stop us, for the same reason I believe Brendan Eich would have said “no” in the hypothetical example above. They understand that the whole purpose of defending software freedoms is to prevent powerful groups from using their monopoly on the money and infrastructure that funds most software development, to enforce their politics on its users.

 So what happens when developers start implementing political blocks at the code level, as Tusky did? Do the ends justify the means?

 In the short term, even if every fediverse app followed the Tusky example, life becomes mildly inconvenient for the Cess.pit folks, who can just start distributing their own forks of their preferred apps from their own websites. In fact, they’ve now set up their own app store. No real harm been done to their operations. But in the long term, it starts to normalize the idea that its OK to use the roles of developer, engineer, or hosting provider, to police other people’s politics.

 Imagine if all the technical folks who disagree with radical left views started doing the same things to us, that some of us have done to the users of Cess.pit. Imagine centrist liberal CEOs at Mozilla, Goggle, Apple, and Microsoft, building blocklists of radical left websites and media outlets into Firefox, Chrome, Safari, and Edge. Imagine we had to develop all our own software and host all our own infrastructure, and try to convince other users to only use fringe apps and hosting platforms that don’t have built in censorship of our politics. This is incredibly threatening to the radical left - far more threatening than Cess.pit itself.

 This is why a lot of people in the ethical tech community disagreed with the Tusky dev’s decisions, even though we respected their right to make it, while the developers of other apps decided instead to respect the longstanding principle of political neutrality discussed above. This is why many of us were horrified when developers who chose not to hardcode blocks into their apps became the target of coercion by some radical leftists, like those who tried to get Fedilab removed from app stores by claiming its developers “explicitly chose to enable hatred and violence through their app”.

 These smear campaigns and false accusations are appalling in themselves, exactly the tactics of the Bad Actors I described above. But even worse, to the degree that they are successful in the short term, they risk massive damage to the prospects of the radical left in the longer term, for reasons described above. They also do massive damage to the sense of goodwill and common cause that convinces people who could earn massive salaries in the corporate tech industry, to spend their spare time - or take more precarious jobs - to write free code that benefits all human beings. Including radical leftists.

… and yes, sometimes including fascists. But for the reasons discussed above, I think the benefits of that far outweigh the costs.

Filed November 20th, 2019 under open social networks, free software, open source

A lot of people in privacy advocacy circles have been tut-tutting about the trackers that were identified in Purism’s Librem Chat software, a distribution (modified version) of the source code developed by New Vector for the Riot chat app. According to the Purism folks, they inherited these trackers from the Riot source code and while they failed to completely remove them from that version, newer versions have succeeded and are tracker free.

Some folks seem to think that this situation looks bad for Purism. Initially, there was the claim that they’d been caught not really caring about privacy, despite their marketing to the contrary. Then, when it was revealed that Purism hadn’t added the trackers themselves, they were accused of failing in their duty of care, by putting their brand name on a piece of software without noticing the trackers in it. No doubt, as the news filters out that they did notice them, but failed to remove every trace of them completely, the claim will change to one of incompetence.

But is that really fair? Another way of telling the story is that Purism put in significant effort to clean up free code produced by another company, resulting in a more privacy respecting chat app for users. One they don’t even charge for, because they make their money from selling hardware and running online services that they charge a subscription for (including the Librem Chat service that their distribution of Riot connects to by default). OK, they didn’t get it right the first time, nobody is perfect, but they were upfront about the problem and got it fixed.

Even if they hadn’t thoroughly audited the code, that’s not always considered necessary. Does every GNU/Linux distribution check every line of the Linux kernel before releasing it with their name on it? Some of them might (eg the ones that use the deblobbed Linux-libre fork of the kernel), but mostly the Linux kernel team are trusted to know what they’re doing. The same goes for a lot of other core components of GNU/Linux.

There was a time when the amount of source code being released under free licenses was so small, and the people using it so geeky, that a lot of it did get checked quite thoroughly before being used, let alone reused in other software. Generally, it felt safe to trust that the potential for dodgy stuff in free code to be discovered, and its creators publicly shamed, was enough to discourage anyone from putting it in there. With so much free code now being released by random people on the net, this is no longer a safe assumption, even when it comes to established open source communities and companies. But still, we generally give well established open source communities, like the Riot team, the same benefit of the doubt. As a user called Shilu put it in a discussion on the PrivacyTools.io forum:

“[It] seems bizarre that Riot would include these trackers by default.”

The other problem is the massive pressure on people developing software to ship it yesterday. One of the many consequences of this, as software gets more complicated and more modular, is more reuse of code by importing modules or plug-ins, and especially updates to them, without checking anything but their license and maybe who maintains them. So as with the trackers from Riot, stuff slips though, and sometimes with much more serious consequences.

Source code being available makes this less likely, and easier to identify and fix, but it can’t and doesn’t stop it completely. As with the Amazon Lens debacle, we also need to make sure that someone other than the author and their collaborators reads the code, carefully examining what the software does, and talks publicly about any problems they see with it (after a responsible delay to give the authors a chance to fix the problem). This is precisely why the four freedoms laid out in the Free Software Definition are important, and why laws that make some aspects of studying technology illegal, like the “anti-circumvention” provisions of the US DMCA (Digital Millennium Copyright Act), are so backwards and need to be thrown out.

Filed July 10th, 2019 under free software, open source

FarceBook have been getting a lot of heat since the mosque shootings were livestreamed on their platform. But the software freedom movement seem to be able the only people talking about the ambitious solution that’s really required; replacing FB with ethical services controlled by the people who use them, not a tech corporation and its data buyers and advertisers. There are a people saying that we need a federated replacement for FB, using free code software. But is that really a viable solution? Here’s what I think would be required to create one.

First, we’d need a large-scale, crowdsourced UX (User eXperience ) design project. This would involve current FB users explaining exactly what features they use and how they use them, and a group of designers gradually building up mockups of a replacement UX. The designers would go through a number of iterations of presenting their mockups to the users for feedback and tweaking their designs in response. The outcome of this project would be a coherent UX design for both a website and native apps for desktop and mobile platforms.

During the course of the UX design project, a list of required features/ functions would need to be compiled. Decisions would need to be made about which of these could be implemented on the client-side (as many as possible, particularly data storage) and which would need remote servers. The second part of the project would involve identifying which of the features required by the UX could be implemented using existing free code components, which ones would need new code, and how the whole service could fit together efficiently. This would be a complicated set of decisions, because although building completely from scratch would be reinventing the wheel, the alternative requires evaluating hundreds or thousands of potential dependencies for code quality, and how likely it is to be maintained effectively in the long term.

The third part of the project, once the choices about initial design and back-end component re-use/ development had been made, would be to put the whole thing together as a proof-of-concept service. At this point, people who participated in the original crowdsourced UX design project could be contacted to see if they would like to be beta testers. Again, there would need to be a number of iterations where the service and UI was tweaked in response to tester feedback.

Unless there is some way to make our FB replacement an entirely serverless system like Jami or Briar, the long-term organizational and financial durability of instances (servers running the federated server software) is a problem that needs to be solved before federated social networks are ready for mainstream use. During the prototyping phase some serious thought would need to be given to how to provision the servers the production services will rely on. Our experiences with the fediverse so far have shown that we can’t just rely on random people setting up instances, which may vanish without a trace at any time. If our FB replacement ties users to a domain name, as the ActivityPub fediverse does, there will need to reliable organizations running instances (like cooperative businesses, associations with paid membership, or well-funded charities). It would be better if it used Zot (like Hubzilla and Zap), configured in such a way that every user’s account exists on at least two instances at any given time, so if one goes down, the account is automatically copied from the surviving one to another one.

Once the alpha and beta phase of prototyping was finished, and a stable 1.0 release of both the client-side apps and server-side software was available that included tools for importing users’ data from their FB account (a tasks that I imagine FB do everything in their power to make as difficult as possible), there would need to be a massive organizational and promotional effort to get reliable instances set up, and convince groups of users to set up accounts and start using them.

Some might say I’m making this seem way more complicated than it needs to be. After all, we’ve already created a federated replacement for Titter. But my whole point is that FB is a much more complicated system to replace and people are much more dependent on it. Titter has only two features, a public micro-blog (short text messages published on the web), and private text messages, and the fediverse as a whole has only implemented the first one. Some fediverse apps have “private” messages, but they don’t yet federate reliably across all apps and most (eg the Mastodon/ Pleroma DMs or “Direct Messages”) are private only in the sense they are not displayed publicly on those platforms. DMs sent to servers running other fediverse apps are liable to just treat them like any other public post. Only servers running Zot apps have any kind of encryption or proper controls over private messages and media.

FB consists of a wide range of features; not just posts, but an event system, encrypted realtime chat (including voice/ video), photo-sharing and galleries, web video and video livestreaming, pages, groups, and more. Many of these features have both public and private versions. While FB’s privacy protection is far from exemplary, a system being promoted as an ethical replacement would need to take this seriously. Many existing free code projects offer some of the elements needed to create a FB replacement, but none of them are anywhere near incorporating them all, and the problem of hosting remains unsolved.

In summary, I’m sceptical about trying to replace FB with a single service. I think we’re more likely to succeed by disaggregating its many features, replacing them with apps that do one thing well; chat clients, media-hosting services, events systems etc, and finding ways to bundle them together into community-hosted services that can each inter-operate with each other.

Firstly, my heartfelt condolences must go out to everyone affected by the tragic events in Ōtautahi (Christchurch) last Friday. Secondly, I’d like to express my admiration for all the young people who took part in the School Strike for Climate activities that same day. Even while we express our sadness at being in the shadow of a dark cloud, we must remember that there is so much more power in the sunshine than in the darkest cloud.

Laura O’Connell Rapira, Director of ActionStation.org.nz, sent out a wonderful email about how we can support the survivors of Friday’s tragedy, which I totally endorse, with one very important exception. Here’s my reply:

 

Kia ora Laura,

Thanks for your compassionate and helpful email at this difficult time. I have signed the petition on banning public ownership of semi-automatic weapons in Aotearoa. I note that having Police roaming the streets with guns in their cars did nothing to prevent this tragedy, while that policy has led to a number of tragedies of its own making. I hope to see ActionStation campaigning to end the policy of providing beat cops with firearms, and redirect resources into making sure our appropriately trained Armed Offenders Squads have everything they need to respond quickly and effectively when things like Friday’s tragedy happen.

Moving on to the rest of your email, I agree with most of what you say, but as I’ve expressed in previous emails, I have some serious concerns about this part:

“TAKE ACTION TO END HATE SPEECH 

For the last few months, our team has been researching the links between online hate, online misinformation and the rise in hate crimes

One thing is abundantly clear: Extreme words lead to extreme actions. We need to do all we can to stop both.

Sign this petition that we’re delivering in a couple of weeks if you want our government to crackdown on online hate and misinformation

I support an end to hate speech and misinformation online.”

I certainly share this goal, as an activist who has been involved in running internet forums since the 1990s, including about 7 years in the editorial collective of Aotearoa Indymedia. But with all due respect, I have to say I think you are going about it exactly the wrong way.

I strongly believe that venues where people can express ignorant opinions and have them firmly but respectfully challenged are - aside from being essential to a functioning democracy - also an essential safety valve that can help to prevent more tragedies like what happened on Friday. What better venue could there be for this than the internet? On the net, arguments can’t escalate to physical violence between participants, as they can in person. Online, we can all make informed decisions about whether or not to engage in the spaces where these kinds of discussions take place, and if we do, use the opinions expressed as a guide to who we might want to connect with, ignore, mute, or even block from seeing or contacting us. Online discussion platforms need to be engineered to put that power in the hands of us, the end users, not corporations or governments. For example, the open source community designing software using the SSB (Secure Scuttlebutt) protocol have a set of principles for how they are going about that.

I think the censorship strategy ActionStation is arguing for is not only ineffective in achieving our shared goal, but counterproductive to it. Why?

For a start, I don’t accept your generalization that “extreme words lead to extreme actions”. I think it’s just as arguable that extreme actions can result from an inability to blow off steam through words, or from feelings of frustration, alienation, and injustice, that can arise in people unable to openly express their honest opinions.

It’s also important to consider the psychological principle of “negative reinforcement”, which states that whenever any behaviour earns someone attention or reactions it is encouraged, even when that attention is negative. Positive Parenting courses integrate this principle by encouraging parents to give their children lots of attention for behaviour they like (”caught being good”), and minimal attention to behaviour they don’t like, ignoring it completely if possible. On the net, this principle is known as the “Streisand effect”, and it’s long been recognized that trying to suppress anything online only increases interest in it, multiplying the problem like the Sorcerer’s Apprentice chopping up his broom.

So not only is trying to suppress racist speech online likely to have exactly the opposite effect, it may also have a more dangerous one. As Three Arrows pointed out in his web video debunking Jordan Peterson, Nazism - like all forms of xenophobic ethno-nationalism - thrived by cultivating a sense of collective victimhood. Excluding people expressing white nationalist ideas from the normal protections of our democratic rights to speak our minds, assemble, and organize, only serves to reinforce that sense of victimhood. So it’s likely it actually helps groups planning racist violence with their recruitment, rather than hindering them.

I strongly suggest you watch the documentary ‘Taking Liberties’, which explains how the governments of the Allied countries - including New Zealand - carefully studied how the Nazis came to power, and why the majority of Germans who didn’t support the Nazis were unable to effectively resist them. As a result of this study, many of the civil rights we now consider essential to democracy were strengthened or even created after World War II, specifically to prevent a resurgence of fascism. Arguably, it is as a consequence of the erosion of civil liberties in democratic countries since 9/11 that we have seen the rise of toxic enthno-nationalism and its associated violence, not as a result of too much of the wrong kinds of speech.

I also don’t accept that the ends justify the means. Even if it was true that giving the state absolute power to stop people openly saying racist things would fix racism, that wouldn’t mean it was the right thing to do. Killing the entire human population might fix climate change and prevent the extinction of many other species, but that doesn’t mean it’s the right thing to do. In this (admittedly extreme) example, the negative consequences are obvious, but in designing policy, we also need to be very mindful of the risks of unintended consequences.

There’s a parallel here with the well-meaning attempts by US legislators to suppress sex trafficking - another goal we all support - with FOSTA/SESTA. As Norman Shamas of Open Privacy explained in an interview with Final Straw Radio, not only do these laws make life harder for a lot of innocent people, they also make the jobs of the people who investigate sex traffickers harder too. When sex traffickers can’t hide their communications in plain sight among legitimate ads put up by sex workers, it doesn’t stop them communicating. It just pushes them deeper into the darknet where it takes a lot more resources to find and investigate them. Exactly the same is true for communications among white supremacists.

It’s much safer for everyone if people with racist views discuss them on mainstream platforms, where they can be monitored by both law enforcement and civil society watchdog groups like ours. This is such an important discussion that I’m going to post the text of this email on the Disintermedia blog, and submit it to TheDailyBlog.co.nz as a possible guest blog. I welcome you to engage with me by private email, or on either of those platforms.

Kia manawanui,

Danyl Strype

My apologies to my three readers, and to the hard working organizers from The Open Coop, for not getting around to a write-up on Open 2018 yet. One positive outcome from that event is that attendees who are working on ‘Open App Ecosystems’ of various kinds were able to compare notes, and as a result, there has been a wave of new members and activity on the OAE Loomio group. Open 2018 was a fantastic event, and I encourage anyone interested in potential collaborations between the software freedom movement and the cooperative movement to attend in 2019.

I will soon be heading to Hong Kong for another platform cooperativism conference, ‘Sowing the Seeds‘, taking place from 28-29 September at the Chinese University of Hong Kong (CUHK). This event is a collaboration between a number of cooperatives from around Asia, and the Platform Cooperativism Consortium, based at The New School at NYU (New York University). I’m also hoping to attend the cooperative hackathon taking place over two days before the conference (watch this space!).

A number of the speakers and participants at this conference were contributors to ‘Ours to Hack and Own‘, a book of essays that attempt to map out the transition from data farms that benefit corporations and investors, to digital cafes that benefits their members and workers. It’s a great book, and while I encourage you to buy a copy if you can afford to, I’m aware of at least one place you can download a gratis digital copy (see our Notable Books library).

It’s a privilege to be able to attend these events, and learn more about the fantastic work being done by cooperative organizers and free code hackers around the world. At the same time, it’s taking some effort to get my head around this new social movement, and how it relates to the pre-existing economic democracy and digital freedom movements that I’ve been involved in for decades. Expect to see more writing on this blog about both the organization and technical aspects of platform cooperatives over the next year or so. It may be that some of this writing will provide the ending I’ve been looking for to complete the story I want to tell in ‘Email At My Life‘. Again, watch this space!

Filed September 23rd, 2018 under News, open source

At the end of last month, Mozilla Hacks announced a new series of “DWeb” posts on decentralized software projects, which aim to redistribute the power to host and share information on the web, and on the internet in general. Obviously it’s of great interest to Disintermedia, and this blog’s 2 readers. So far, there are articles on Scuttlebutt/ SSB, WebTorrent, and Beaker Browser (see the list at the end of the DWeb announcement article). Thanks to the fedizen - a citizen of the “fediverse” of federated social networks -  who brought this to my attention, sorry I can’t remember who it was right now.

I’m back in the studio, and intending to resume normal transmission next week. This will start with a run-down of the talks and workshops I attended at Open 2018 in London.

Update 2018-11-29: Rich Bartlett wrote an excellent piece on his experiences with trying to get paid for contributing to the commons. Rich is an activist, writer, and hacker, associated with Enspiral, Loomio, and The Hum.

——–

A couple of years back, I decided to see if I could actually get funded by the communities who I created Disintermedia to inform and support. I started gathering information about different ways people could pay me over the internet, and adding it to a page called Help Disintermedia, which was initially created to publicly thank services like CoActivate that help us in non-monetary ways. First, I experimented with setting up the software to receive BitCoins, and put up a wallet address (is that right?), and over the next year that was followed by a link to a Patreon page, and then a Liberapay page. These “micro-patronage” sites allow people to give small, regular amounts, and in theory, like newspaper subscriptions, many people’s small payments can add up. I’m embarrassed to admit that so far, these efforts have been a dismal failure.

For a start, the BitCoin address I published was: 19KER7hfqXhZnHnnJ3VcGRr2w3i1v6e44e

But I have no idea now where this directs BitCoins to, or if anyone actually donated any, how to retrieve them. I just haven’t had the time to do all the reading required to fully understand how to use BitCoin; how to back up my wallet, how to accept payments to the same wallet from multiple devices, whether I can do this using the same address, so many questions! The same is even more true for other crypto-tokens (FairCoin, FreiCoin, SolarCoin, NameCoin, FileCoin etc). If you can help me get to grips with any of this, especially if you are keen to donate to Disintermedia  please feel free to contact me.

I’m also considering figuring out how to use Brave, Minds, SteemIt, Earn.io, and a bunch of other new systems that claim to offer ways of paying creators who contribute to the weaving of the free web. But seriously, figuring out which of these are honest, and viable, is a high-stakes research project in and of itself. With real money involved, there’s no kind of software more attractive to bad actors, idealistic incompetents, and venture capitalists. They all take time to set up and learn to use well, and you can’t get any benefit out of them without giving them real personal details and banking information. On top of that, there’s a risk involved in implicitly endorsing them if they end up being dodgy.

I’ve thought about experimenting with the newly relaunched Flattr 2.0, since unlike most micro-patronage sites, it’s pretty set-and-forget. Creators can get paid through it without needing to constantly self-promote (”click here to subscribe!”). There have been some hard questions asked about the privacy implications of the Flattr browser extension, but the developers do sound like they take privacy seriously, and it’s encouraging that all their apps are free code (not sure about the javascript on the site itself though). Another critical question is about how much money creators can realistically get out in payments. Even if they took 50% of whatever Flattr payout I got, that’s still potentially more than I’d get by not using it at all, but the new fees scheme for Flattr does seem to take a lot of bites out of my sandwich before I get to eat it.

Really, if the developers of any of these community funding platforms really think they are viable, they should be eating their own dogfood, and funding themselves using their own platform. Gratipay did this (RIP), and Liberapay still do, which is why I tried them first. Any platform skimming their users’ donations with fees, or heaven forbid, sucking up to venture capitalists, isn’t showing much confidence in their own funding platform. After all, you don’t see GitHub developing the code for GitHub on another code forge (they might have a backup there but that’s different).

For example, Ko-fi fund themselves using their own platform, instead of taking fees. I can’t find any source code though, and their use of a proprietary mail missile called SendGrid to send out emails isn’t encouraging. Ko-fi is designed to give the original Flattr model another go; buttons creators can stick on their web page, that users can click to “buy me a coffee”.

A Flattr developer posting on HackerNews claimed that model failed, because:

  • a) people using the web don’t want to click buttons (?!?)
  • b) publishers didn’t want another private company’s branded buttons all over their site

None of this seems to affect PaylPal / Stripe or social media buttons. I suspect it was more like:

  • a) people are used to having to enter their credit card details (or deal with PayPal shudder) when they click a donate button, which is a painful and scary user experience
  • b) when Flattr launched you couldn’t get paid anything without first setting up a monthly contribution to Flattr so most people didn’t bother (that’s why I didn’t), and nobody wanted buttons all over their site promoting a thing that smelt like a pointless ponzi scheme
  • c) Flattr funded themselves by skimming off 10% every time credit moved across their platform, and as mentioned above, Flattr 2.0 has even more ways to charge everyone.

I’ve set up a Ko-Fi account, just to try it out. Is it really going to help to add yet another layer of management between me, PayPal, the bank, and the person trying to give me money? I’m sceptical about whether it was worth the time, or the indignity of having to deal with PayPal or some other toll collector on the information superhighway (again, shudder). Frankly, I’m not convinced that Ko-Fi is an improvement on just having a button for PayPal or Stripe, although it is nice to not have their garish corporate branding all over an activist website. But hey, prove me wrong, buy me a coffee!

Buy Me a Coffee at ko-fi.com

I suspect that for the contribute button thing to really take off, it needs to become a neutral web standard, so the buttons are all over the web, they always look the same, and its a standard icon on them, not one company’s logo. The person clicking them can set up a payment system that gets activated when they click the contribute button, and website creators can decide which payment gateway processes the money when they get clicked. I’m hoping GNU Taler takes off, and we can eventually use that. If anyone reading this is involved in a credit union, or cooperatively owned bank, who might be willing to get involved in a pilot scheme, I encourage you to contact the Taler team.

For now, if anyone can recommend any other sites for collecting one-off donations for struggling web writers, that would be much appreciated. If you want to donate, and you don’t mind the banking system knowing it, please contact me, and I can give you bank account details privately.

————————————

Update 2018-10-01: it just occurred to me that I could be missing out on potential donations by deleting emails from PayPal (which I presume to be spam), and emails offering me money (which I presume to be variants on 419 fraud). If you’ve ever tried to donate to Disintermedia, please reach out via the fediverse (where scam messages haven’t appeared yet), and let me know, so we can figure out if the money left your account, and where it went. 

Filed April 19th, 2018 under free culture, independent media, News, open source

In 2016, I included a graph from Layer 3 Networking blog, in a rant about the tendency to put on weight over time that I’ve seen in even the most lightweight GNU-Linux DE (Desktop Environment). The blog piece I took that graph from gave a detailed run-down of the lightweight DE ecosystem, as it stood in 2013, which still serves as the most thorough introduction I’ve found on the subject.

Being 5 years old now, the graph can’t be treated as a true indication of how much RAM more recent versions of these DEs might use. But it does offer an idea of just how many different free code DEs are out there, some screenshots of what some of the lighter ones look like installed, and roughly how much RAM a wide range of them use relative to each other. It also gives the exact methods used to make the RAM use comparisons between DEs, which is important to whether their results are a fair comparison, and another reason I still consider this a useful guide despite being five years old.

Obviously, being 2013 data, some of the DEs mentioned are now superseded or defunct (eg E17, Unity), or merged (LXDE and Razor-QT are now LXQT), and other newer ones aren’t mentioned (Artemis, Moksha, Pantheon, Yunity, Zorin etc). Based on the numbers from the graph there, I’d say in 2013 you could break DEs down into 3 categories (RAM use numbers assume a freshly booted system running no extra user apps):

  • Small (0-20MB): TinyWM, 9wm, miwm, wm2, dwm, Ratpoison, olvwm, TWM, xmonad/mobar, JWM, i3, Blackbox, Sawfish, IceWM, PekWM, Openbox, Window Maker, awesome, FVWM, Fluxbox, Mutter
  • Medium (20-100MB): E17, LXDE, KWin, Mate, Trinity, XFCE, Cinnamon
  • Bloated (>100MB): Razor-QT, GNOME 3, Unity, KDE

The DEs I describe as bloated are clearly targeted at providing every imaginable widget and performance boost, for users with fairly new hardware, or middle-aged hardware that’s been upgraded or is unusually powerful. Unless you are a business with deep pockets, or someone else who upgrades your computer every couple of years so you can always run the newest software, I suggest avoiding the bloated category. That is, if you don’t want to end up switching to a lighter DE in a couple of years, as the hardware requirements of the bloated DEs continue to creep up towards the latest hardware.

Cinammon, a fork of GNOME 2 developed for the Mint distro, offers everything the average user needs from a desktop experience, while using significantly less RAM than older and more common DEs like KDE Plasma or GNOME 3. Mate, Mint’s lightweight DE, uses even less RAM, while still providing a familiar point-and-click desktop, with the bells and whistles familiar to Windows users who have used any version of Windows from 95 to 7. I’m typing this on an Acer Aspire One that’s nearly 10 years old, and the Mate desktop in the about-to-be-released Trisquel 8 runs fine, although I have improved the performance by doubling the RAM to 2GB and, more importantly, replacing the internal drive with an SSD (Solid State Drive). I can’t emphasize enough what a big difference the SSD makes.

If you still want to be using your computer in ten years time, especially if you bought a netbook or some other unusually under-powered PC like I did, I strongly recommend getting familiar with the pros and cons of the DEs in the small category. If I just want to play a game, I use Openbox, and I really notice how much better the heavier games run without all the extra desktop bells and whistles taking up resources. I intend to get into a habit of logging into Openbox whenever I plan to work on a long piece of writing, or anything else that doesn’t really require flipping back and forth between apps.

In summary, I can’t tell you which DE is right for you, and just to confuse you even more, the same DE can use a different amount of resources depending on which GNU-Linux distro you’re running it on, and even whether or not it’s the default DE for that distro. But it’s definitely worth doing some reading, and choosing one that not only does what you want right now, but will keep doing it for as long as you don’t want to have to switch to keep your computer usable.

Filed April 16th, 2018 under free software, open source
Next Page »
  • Annual Events

  • Digital Freedom Foundation
  • LibrePlanet
  • Aotearoa

  • Aotearoa Indymedia
  • BallaNZ
  • Creative Commons Aotearoa/ NZ
  • Creative Freedom Foundation
  • DigitalNZ
  • Enspiral
  • Fair Deal Coalition
  • GreenStage
  • InternetNZ
  • Island Bay World Service
  • Living Economies
  • Localise
  • Loomio
  • Matrix FM
  • Nicky Hagar
  • No Right Turn
  • NZ Council for Civil Liberties
  • NZ Makers
  • NZ Makers Map
  • NZ Māori Internet Society
  • NZ Open Source Awards
  • NZCommons
  • OASIS
  • Open Government Ninjas of NZ
  • Open Source Society of NZ
  • Open Standards NZ
  • Open Ur Eyes
  • Pacific Media Centre
  • Permaculture in NZ
  • PledgeMe
  • Radio Chomsky
  • Regulation
  • Scoop
  • Tech Liberty
  • Timebank Aotearoa
  • Transition Towns Aotearoa/ NZ
  • Uncensored Magazine
  • Waatea News
  • Waikato Linux Users Group
  • What If
  • Wiki NZ
  • Zenbu
  • archives

  • ArchiveTeam
  • Critical Commons
  • Ibiblio
  • Internet Archive Community Software Collection
  • Open Archives Initiative
  • Blogroll

  • Abject
  • Access Now
  • Ars Technica
  • BadScience
  • Banjo - RoboBlog
  • Boing Boing
  • Born out of Binary
  • Centre for Media and Democracy
  • Choke Point Project
  • Copyrighteous
  • Create Digital Music
  • Creative Commons International
  • Cryptogon
  • Digital Standards Organisations
  • Disinfo
  • E-Democracy
  • Electronic Privacy Information Center
  • Ever Vigilant
  • Freedom Box Foundation
  • Freedom of the Press Foundation
  • Gaming On Linux
  • Global Indymedia
  • Gondwanaland (Mike Linksvayer)
  • Institute for the Future of the Book
  • Institute of Network Cultures
  • Internet Governance Project
  • InternetNZ
  • Island Bay World Service
  • Iterating Towards Openness
  • Knowledge Ecology International
  • LinkedListCorruption
  • Linuxed - Exploring Linux Distros
  • Localise
  • Moved by Freedom - Powered By Standards
  • Nanowares
  • New Zealand Māori Internet Society
  • Nicky Hagar
  • No Right Turn
  • NZ Council for Civil Liberties
  • NZCommons
  • O'Reilly Radar
  • OASIS
  • OERu Technology Blog
  • Open Educational Resources Foundation
  • Open Knowledge Foundation
  • Open Rights Group
  • Open Social Web
  • Open Source Conscious Intelligence Network
  • Open Source Food
  • Open Stand
  • Open Ur Eyes
  • OpenCollective
  • OpenDotDotDot
  • OpenSource.com
  • Permaculture in NZ
  • Plumi
  • Public Interest Journalism Foundation
  • Punk Rock Permaculture
  • Question Copyright
  • Replicant (OS)
  • Rob Meyers
  • Schneier on Security
  • Scoop
  • Shareable
  • Slashdot
  • Software Freedom Law Centre
  • Software in the Public Interest
  • SourceMap
  • Sustento Institute
  • Tech Liberty
  • TechRights
  • The Tin Hat
  • Tinkering Down Under
  • TorrentFreak
  • TransitionMovement
  • Translation Project
  • Trisquel GNU/ Linux
  • United Diversity
  • Waatea News
  • We Speak for Freedom
  • Why Your Boss is Programmed To Be a Dictator
  • code bank

  • Allura
  • BitBucket
  • FusionForge
  • GITHub
  • GITLab
  • Gogs
  • Internet Archive Community Software Collection
  • LaunchPad
  • NotABug
  • Savannah
  • Software Freedom Conservancy
  • Software Heritage
  • Sourceforge
  • community economics

  • Commons Transition
  • Fruit Tree Planting Foundation
  • In Our Back Yards
  • Institute for Local Self-Reliance
  • Libre-Living
  • Living Economies
  • Sensorica
  • Sustainable Economy Law Centre
  • Timebank Aotearoa
  • TransitionMovement
  • cooperative

  • Loomio
  • Snowdrift Coop
  • crowdfunding

  • ArtistShare
  • BountySource
  • Causes
  • CauseVox
  • Crowdfunder
  • Crowdjustice
  • Crowdrise
  • Crowdsupply
  • Flattr
  • Fundit.buzz
  • GiveaLittle
  • Goteo
  • In Our Back Yards
  • KickStarter
  • KissKissBankBank
  • Liberapay
  • Mighty Cause
  • OpenGift
  • Patreon
  • PledgeMe
  • PledgeMusic
  • Pozible
  • Snowdrift Coop
  • StartSomeGood
  • Taproot Foundation
  • The Working World
  • Tidelift
  • Events

  • IndieWebCamp
  • free code

  • April
  • Black Duck Open Hub
  • DistroWatch
  • Ever Vigilant
  • F-Droid
  • Free Software Directory (GNU FDL 1.3 or later)
  • Free Software Support Network
  • Free Software Support Network
  • Free Your Android
  • FreshCode
  • Gogs
  • Gun.io
  • Internet Archive Community Software Collection
  • LILA
  • LinuxTracker
  • NotABug
  • OERu Technology Blog
  • Peers Community
  • Plumi
  • PublicLab
  • Replicant (OS)
  • Software Heritage
  • Urchn Studios
  • Free Media

  • Communes Collective
  • Copyrighteous
  • Create Digital Music
  • Definition of Free Cultural Works
  • Dyne Foundation
  • FLOSSManuals
  • Free Culture Foundation
  • Ibiblio
  • Librivox
  • LILA
  • Open Video Conference
  • Show Me Do
  • Translation Project
  • Urchn Studios
  • WikiLeaks
  • freelancing

  • BountySource
  • Gun.io
  • independent media

  • Aotearoa Indymedia
  • BallaNZ
  • EngageMedia
  • Freedom of the Press Foundation
  • LILA
  • Matrix FM
  • Pacific Media Centre
  • Public Interest Journalism Foundation
  • Radio Chomsky
  • Radio Heritage Foundation
  • Uncensored Magazine
  • Waatea News
  • libre gaming

  • Gaming On Linux
  • Makers

  • GreenStage
  • Libre-Living
  • Mediamatic
  • NZ Makers
  • NZ Makers Map
  • Open ROV
  • Renewable PCs
  • Rob Meyers
  • Sensorica
  • maps

  • GeoForAll
  • GeoNames
  • Green Map System
  • Map Tools
  • Open Geospatial Foundation
  • Open Street Map
  • open governance

  • Crowdfunding
  • D-Cent
  • Deep Democracy Institute International
  • E-Democracy
  • Fight for the Future
  • Holacracy
  • Internet Governance Project
  • Kettering Foundation
  • Knowledge Sharing Toolkit (CC-BY-SA 3.0)
  • Open Government Ninjas of NZ
  • Open Policy Network
  • Open Space World (CC-BY-SA 2.5)
  • Open Stand
  • Open Standards NZ
  • Participedia
  • Sunlight Foundation
  • Transition Towns Aotearoa/ NZ
  • What If
  • WikiLeaks
  • open hardware

  • H-Node
  • Makey Makey
  • Meeblip Open Source Bass Synth
  • Open Hardware Summit
  • Open ROV
  • Open Source Hardware Association
  • Orgs

  • Access Now
  • Apache Foundation
  • April
  • Autistici/Inventati
  • Collaborative Knowledge Foundation
  • Commons Transition
  • Communes Collective
  • Computer Professionals for Social Responsibility
  • Creative Commons Aotearoa/ NZ
  • Creative Freedom Foundation
  • Critical Commons
  • D-Cent
  • Deep Democracy Institute International
  • Digital Due Process coalition
  • Digital Freedom Foundation
  • Digital Standards Organisations
  • DigitalNZ
  • Dyne Foundation
  • E-Democracy
  • Electronic Frontiers Foundation
  • Electronic Privacy Information Center
  • Fair Tracing Project
  • Fight for the Future
  • Foundation for Peer-to-Peer Alternatives
  • Free Culture Foundation
  • Free Network Foundation
  • Free Software Foundation
  • Free Software Support Network
  • Free Software Support Network
  • Freedom of the Press Foundation
  • Guifi
  • Ibiblio
  • Identity Commons
  • Institute for Local Self-Reliance
  • Internet Engineering Taskforce
  • Internet Governance Project
  • ISA Commons
  • Kettering Foundation
  • LEAP Encryption Access Project
  • LILA
  • Living Economies
  • Loomio
  • May First/ People Link
  • Mediamatic
  • NZ Māori Internet Society
  • NZ Open Source Awards
  • Open Architecture Network
  • Open Archives Initiative
  • Open Geospatial Foundation
  • Open Policy Network
  • Open Source Hardware Association
  • Open Source Society of NZ
  • Open Web Foundation
  • OpenADR Alliance
  • OpenCorporates
  • Outreachy
  • Participatory Culture Foundation
  • Peers Community
  • Permaculture in NZ
  • Privacy International
  • Public Citizen
  • Public Interest Journalism Foundation
  • Public Knowledge
  • Public Patent Foundation
  • Question Copyright
  • Radio Heritage Foundation
  • ReDecentralize
  • Reform Government Surveillance
  • Regulation
  • Rhizome
  • RiseUp
  • Science Commons
  • Software Carpentry Foundation
  • Software Freedom Conservancy
  • Sunlight Foundation
  • Sustainable Economy Law Centre
  • Taproot Foundation
  • Transition Towns Aotearoa/ NZ
  • Waikato Linux Users Group
  • Wiki NZ
  • World Wide Web Consortium (WC3)
  • Xiph.org
  • XMPP Standards Foundation
  • Peer2Peer

  • BitCoin
  • FreeCoin
  • Permaculture

  • Appropedia (CC-BY-SA 3.0)
  • Fruit Tree Planting Foundation
  • Future Scenarios
  • OrganicDesign
  • Permaculture in NZ
  • TransitionMovement
  • We Speak for Freedom
  • Privacy

  • Access Now
  • Digital Due Process coalition
  • Ever Vigilant
  • Fight for the Future
  • International Principles on the Application of Human Rights to Communications Surveillance
  • LEAP Encryption Access Project
  • OASIS
  • Privacy International
  • Reform Government Surveillance
  • What If
  • protocols and licensing

  • Definition of Free Cultural Works
  • Digital Standards Organisations
  • Greenlots
  • ISA Commons
  • Open Archives Initiative
  • Open Stand
  • Open Standards NZ
  • Open Web Foundation
  • OpenADR Alliance
  • Regular Events

  • Libre Graphics Meeting
  • Open Hardware Summit
  • science and datasets

  • AllTrials
  • Collaborative Knowledge Foundation
  • DigitalNZ
  • Fair Tracing Project
  • ISA Commons
  • Open Geospatial Foundation
  • Open Hand Project
  • SourceMap
  • Wiki NZ
  • Zooniverse
  • Tools

  • Autistici/Inventati
  • BitCoin
  • Black Duck Open Hub
  • CoActivate
  • Crowdfunding
  • DistroWatch
  • Dyne Foundation
  • F-Droid
  • FLOSSManuals
  • Fork the Cookbook
  • FreeCoin
  • GITHub
  • GNU Operating System
  • GreenStage
  • H-Node
  • How To Escape the GoogleMax Panopticon
  • Knowledge Sharing Toolkit (CC-BY-SA 3.0)
  • LEAP Encryption Access Project
  • LinuxTracker
  • Loomio
  • Map Tools
  • May First/ People Link
  • Meeblip Open Source Bass Synth
  • Monolith
  • Open Hand Project
  • Open Source Ecology
  • Open Space World (CC-BY-SA 2.5)
  • Open Street Map
  • OpenCorporates
  • OpenMailBox
  • Participatory Culture Foundation
  • Plumi
  • Renewable PCs
  • Replicant (OS)
  • RiseUp
  • Savannah
  • Show Me Do
  • Sourceforge
  • SourceMap
  • TransforMap
  • Translation Project
  • Web Platform
  • Zenbu
  • Transition

  • Green Map System
  • Health After Oil
  • Localise
  • OrganicDesign
  • Wiki

  • Appropedia (CC-BY-SA 3.0)
  • Foundation for Peer-to-Peer Alternatives
  • Instructables
  • LibrePlanet
  • Open (Government) NZ
  • Participedia
  • SourceWatch
  • WikiEducator
  • wireless mesh

  • Guifi
  • workplace democracy

  • Enspiral
  • The Working World