Part analyst, part troubleshooter, and part troublemaker, Stefan serves as Agaric's secret weapon and resident heretic. From his homeland of Germany, with other Agarics in Massachusetts, and at Drupal events around the world, Stefan programs, administers systems, and questions Drupal dogma.

Multilingual in human and computer languages, Stefan's technological curiosity and talents have benefited Agaric clients and the Drupal community. With an interest in integrating systems via web services, his work has included LDAP and Kerberos configuration. With his contributions to RDF in Drupal, Stefan is helping build the semantic web, in which computers understand what we mean and let us do fantastically smart and complex things with the knowledge we're all putting online.

¿Por qué Libre?

Una nota sobre otras palabras: Software Libre o Código Abierto

Otras lecturas

Yes it's true, for the past few months we've been hard at work with a lot of other co-authors on The Definitive Guide to Drupal 7.

The Definitive Guide to Drupal 7 accelerates people along the Drupal learning curve by covering all aspects of building web sites with Drupal: architecture and configuration; module development; front end development; running projects sustainably; participating in the community; and contributing to Drupal's code and documentation.

Check out the website today! http://definitivedrupal.org/

Find It's Features and Functionality

Find It is a one-stop-shop for community-members to find opportunities for community engagement

Search a curated directory of events

• Filter results based on age, location, cost, activity, and schedule
• Click on a map to select which areas are accessible to you

Create a user account

• Set event reminders about interesting opportunities
• Receive notifications so that your Find It experience stays smooth.

Select a language

• Navigate the site in your language of choice
• Contribute improvements to the translations so that Find It can meet the needs of the diverse communities it serves

Find It makes it easier for government and non-profit organizations to reach the people they work to serve.

Log in with a service provider account

• Share information about your organization
• Post events and services for the residents of their community

Find It makes it easier for an individual or small team to make sure that members of the community they serve have access to all of the services they need.

Post information about public spaces

• Keep track of all of the available public spaces on a single platform
• Let residents know what public spaces are available as resources to them

Coordinate with all of the city's service providers together on one platform

• Add service providers to the platform so they can post information about what they offer
• Check for gaps and redundancies in services offered throughout your area in order to coordinate a more comprehensive set of services

The Migrate API is a very flexible and powerful system that allows you to collect data from different locations and store them in Drupal. It is, in fact, a full-blown extract, transform, and load (ETL) framework. For instance, it could produce CSV files. Its primary use is to create Drupal content entities: nodes, users, files, comments, etc. The API is thoroughly documented, and their maintainers are very active in the #migration slack channel for those needing assistance. The use cases for the Migrate API are numerous and vary greatly. Today we are starting a blog post series that will cover different migrate concepts so that you can apply them to your particular project.

Understanding the ETL process

Extract, transform, and load (ETL) is a procedure where data is collected from multiple sources, processed according to business needs, and its result stored for later use. This paradigm is not specific to Drupal. Books and frameworks abound on the topic. Let’s try to understand the general idea by following a real life analogy: baking bread. To make some bread, you need to obtain various ingredients: wheat flour, salt, yeast, etc. (extracting). Then, you need to combine them in a process that involves mixing and baking (transforming). Finally, when the bread is ready, you put it into shelves for display in the bakery (loading). In Drupal, each step is performed by a Migrate plugin:

The extract step is provided by source plugins.
The transform step is provided by process plugins.
The load step is provided by destination plugins.

As it is the case with other systems, Drupal core offers some base functionality which can be extended by contributed modules or custom code. Out of the box, Drupal can connect to SQL databases including previous versions of Drupal. There are contributed modules to read from CSV files, XML documents, JSON and SOAP feeds, WordPress sites, LibreOffice Calc and Microsoft Office Excel files, Google Sheets, and much more.

The list of core process plugins is impressive. You can concatenate strings, explode or implode arrays, format dates, encode URLs, look up already migrated data, among other transform operations. Migrate Plus offers more process plugins for DOM manipulation, string replacement, transliteration, etc.

Drupal core provides destination plugins for content and configuration entities. Most of the time, targets are content entities like nodes, users, taxonomy terms, comments, files, etc. It is also possible to import configuration entities like field and content type definitions. This is often used when upgrading sites from Drupal 6 or 7 to Drupal 8. Via a combination of source, process, and destination plugins, it is possible to write Commerce Product Variations, Paragraphs, and more.

Technical note: The Migrate API defines another plugin type: `id_map`. They are used to map source IDs to destination IDs. This allows the system to keep track of records that have been imported and roll them back if needed.

Drupal migrations: a two step process

Performing a Drupal migration is a two step process: writing the migration definitions and executing them. Migration definitions are written in YAML format. These files contain information about how to fetch data from the source, how to process the data, and how to store it in the destination. It is important to note that each migration file can only specify one source and one destination. That is, you cannot read form a CSV file and a JSON feed using the same migration definition file. Similarly, you cannot write to nodes and users from the same file. However, you can use as many process plugins as needed to convert your data from the format defined in the source to the format expected in the destination.

A typical migration project consists of several migration definition files. Although not required, it is recommended to write one migration file per entity bundle. If you are migrating nodes, that means writing one migration file per content type. The reason is that different content types will have different field configurations. It is easier to write and manage migrations when the destination is homogeneous. In this case, a single content type will have the same fields for all the elements to process in a particular migration. Once all the migration definitions have been written, you need to execute the migrations. The most common way to do this is using the Migrate Tools module, which provides Drush commands and a user interface (UI) to run migrations. Note that the UI for running migrations only detect those that have been defined as configuration entities using the Migrate Plus module. This is a topic we will cover in the future. For now, we are going to stick to Drupal core’s mechanisms of defining migrations. Contributed modules like Migrate Scheduler, Migrate Manifest and Migrate Run offer alternatives for executing migrations.

Next: Writing your first Drupal migration

This blog post series, cross-posted at UnderstandDrupal.com as well as here on Agaric.coop, is made possible thanks to these generous sponsors: Drupalize.me by Osio Labs has online tutorials about migrations, among other topics, and Agaric provides migration trainings, among other services.  Contact Understand Drupal if your organization would like to support this documentation project, whether it is the migration series or other topics.

Monday night before the "Super Tuesday" primary, I'm searching for "does the bernie sanders app help you offer rides to polls to people" and finding no answer. (It does not.)

All I found was Lyft offering ride codes to for a handful of non-partisan non-profits to distribute. If Lyft can realize that simple physical access to vote is a barrier that affects different groups of people unequally and cite the facts about youth not voting, it surely came up on the Bernie Sanders Slack.

Yet in this highly online-connected campaign, some of the basic steps to winning (asking everyone: Do you have a plan to vote? Do you need help getting to the polls?) didn't make it into the official app, nor in any public side efforts.

There are a huge number of thoughtful, dedicated people working on the Bernie Sanders campaign (and in other political campaigns), but as in every movement I've witnessed I'm convinced that not all the best ideas are bubbling up.  This is especially true for communities like Drupal where even the idea of shared goals, let alone the mechanism for identifying and realizing them, can seem to disappear when you look for them directly.

Even when a goal is simple (get this one person elected president) the tactics are likely to need to be varied and complex.

This is vastly more true when we're talking about a movement. Even in a presidential campaign like for Sanders, the the goals behind the goal—health care, living wages, lots more jobs for everyone because we're putting people to work reversing global warming—are many, multifaceted, and cannot possibly be achieved only through electing someone, even to an office like the United State's imperial presidency.

After getting over my personal hangup of asking people for something without having at least the barest offer of help (a ride to go vote), I did start texting a few people to encourage them to vote. But as I texted my brother in New York, I'm still bummed we're organizing in the context of political campaigns, instead of having huge movements that, as an afterthought, choose our politicians.

I'm not making (or necessarily opposing) the argument that electoral organizing distracts from more important grassroots organizing.

I have gotten involved with a local solidarity network which focuses on direct action to help people with immediate problems— frequently a dozen people helping just one person or a few people at a time win livable spaces from landlords (or get security deposits back), or get stolen wages from an employer.

This sort of deep organizing—really only medium deep, but it's using available resources to nearly their maximum capacity—does not have the breadth of the typical mayoral campaign.

We need breadth as well as depth. There are many problems that can't be solved on a case by case basis. Although the type of organizing local solidarity networks engage in builds the capacity to take on bigger problems, it doesn't necessarily scale fast enough, or have clear mechanisms to translate built power and solidarity in one area to others.

The question of translating power built in one sphere to another is even more pressing for the election campaigns.

It's no secret, as Frank Chapman of the National Alliance Against Racist and Political Repression reminded people in Minneapolis when he visited from Chicago, that you build political power by going door to door and finding supporters.

What would our political movements be able to do if we didn't have to redo all the grunt work every time?

Or if people weren't canvassed only by campaigns (electoral or otherwise), but asked about their needs?

There are enough people who give a damn.

We could build immensely powerful movements from the ground up, if we had a way to agree how shared resources of movements—including communication channels—would be controlled.

To be a movement for, among other things, democracy, we need to be democratic ourselves. The DSA is probably farthest along in reach and democratic mechanisms, and so a natural place to join.

We need better technology to coordinate to achieve justice, liberty, and better lives for all. I don't mean merely a better canvassing app.

We need approaches and tools that let us share power. Then we can truly build power together.

A positive spin on this extremely spun election: media coverage has meant a ton but advertising has not. And the national, corporate media (which, if for instance you haven't checked who owns your local newspaper, if you even have one, is nearly all of the news media) is the sworn enemy to economic fairness and equal political power. No one with resources should put a cent into our enemies pockets by buying ads, especially when it doesn't even work.

It's a perfect opportunity to build institutions that work for us, rather than pouring resources and energy into institutions that are getting us killed.

We can build a communication network through which we collectively decide what we want, and then figure out how to coordinate to get it— whether it's electing someone or holding politicians or businesses accountable with direct action or forming ourselves into a giant cooperative corporation to negotiate as workers and buyers more equally with the huge corporations we deal with on a day-to-day basis.

If you're in the position to connect us to campaigns, cooperatives, parties, or other organizations who see a need for communication tools controlled by all the people in an organization or movement, where the ideas and control of resources can build from below, please contact Agaric.

In Drupal 7 it was useful to do things like this: 

   
function mymodule_content() {
  $links[] = l('Google', 'http://www.google.com');
  $links[] = l('Yahoo', 'http://www.yahoo.com');
  return t('Links: !types', array('!types' => implode(', ', $links)));
}
    

In this case, we are using the exclamation mark to pass the $links into our string but unfortunately, Drupal 8 doesn't have this option in the FormattableMarkup::placeholderFormat(), the good news is that even without this there is a way to accomplish the same thing. 

Today we will learn how to migrate addresses into Drupal. We are going to use the field provided by the Address module which depends on the third-party library commerceguys/addressing. When migrating addresses you need to be careful with the data that Drupal expects. The address components can change per country. The way to store those components also varies per country. These and other important consideration will be explained. Let’s get started.

Getting the code

You can get the full code example at https://github.com/dinarcon/ud_migrations The module to enable is UD address whose machine name is ud_migrations_address. The migration to execute is udm_address. Notice that this migration writes to a content type called UD Address and one field: field_ud_address. This content type and field will be created when the module is installed. They will also be removed when the module is uninstalled. The demo module itself depends on the following modules: address and migrate.

Note: Configuration placed in a module’s config/install directory will be copied to Drupal’s active configuration. And if those files have a dependencies/enforced/module key, the configuration will be removed when the listed modules are uninstalled. That is how the content type and fields are automatically created and deleted.

The recommended way to install the Address module is using composer: composer require drupal/address. This will grab the Drupal module and the commerceguys/addressing library that it depends on. If your Drupal site is not composer-based, an alternative is to use the Ludwig module. Read this article if you want to learn more about this option. In the example, it is assumed that the module and its dependency were obtained via composer. Also, keep an eye on the Composer Support in Core Initiative as they make progress.

Source and destination sections

The example will migrate three addresses from the following countries: Nicaragua, Germany, and the United States of America (USA). This makes it possible to show how different countries expect different address data. As usual, for any migration you need to understand the source. The following code snippet shows how the source and destination sections are configured:

source:
  plugin: embedded_data
  data_rows:
    - unique_id: 1
      first_name: 'Michele'
      last_name: 'Metts'
      company: 'Agaric LLC'
      city: 'Boston'
      state: 'MA'
      zip: '02111'
      country: 'US'
    - unique_id: 2
      first_name: 'Stefan'
      last_name: 'Freudenberg'
      company: 'Agaric GmbH'
      city: 'Hamburg'
      state: ''
      zip: '21073'
      country: 'DE'
    - unique_id: 3
      first_name: 'Benjamin'
      last_name: 'Melançon'
      company: 'Agaric SA'
      city: 'Managua'
      state: 'Managua'
      zip: ''
      country: 'NI'
  ids:
    unique_id:
      type: integer
destination:
  plugin: 'entity:node'
  default_bundle: ud_address

Note that not every address component is set for all addresses. For example, the Nicaraguan address does not contain a ZIP code. And the German address does not contain a state. Also, the Nicaraguan state is fully spelled out: Managua. On the contrary, the USA state is a two letter abbreviation: MA for Massachusetts. One more thing that might not be apparent is that the USA ZIP code belongs to the state of Massachusetts. All of this is important because the module does validation of addresses. The destination is the custom ud_address content type created by the module.

Available subfields

The Address field has 13 subfields available. They can be found in the schema() method of the AddresItem class. Fields are not required to have a one-to-one mapping between their schema and the form widgets used for entering content. This is particularly true for addresses because input elements, labels, and validations change dynamically based on the selected country. The following is a reference list of all subfields for addresses:

1. langcode for language code.
2. country_code for country.
3. administrative_area for administrative area (e.g., state or province).
4. locality for locality (e.g. city).
5. dependent_locality for dependent locality (e.g. neighbourhood).
6. postal_code for postal or ZIP code.
7. sorting_code for sorting code.
8. address_line1 for address line 1.
9. address_line2 for address line 2.
10. organization for company.
11. given_name for first name.
12. additional_name for middle name.
13. family_name for last name:

Properly describing an address is not trivial. For example, there are discussions to add a third address line component. Check this issue if you need this functionality or would like to participate in the discussion.

Address subfield mappings

In the example, only 9 out of the 13 subfields will be mapped. The following code snippet shows how to do the processing of the address field:

field_ud_address/given_name: first_name
field_ud_address/family_name: last_name
field_ud_address/organization: company
field_ud_address/address_line1:
  plugin: default_value
  default_value: 'It is a secret ;)'
field_ud_address/address_line2:
  plugin: default_value
  default_value: 'Do not tell anyone :)'
field_ud_address/locality: city
field_ud_address/administrative_area: state
field_ud_address/postal_code: zip
field_ud_address/country_code: country

The mapping is relatively simple. You specify a value for each subfield. The tricky part is to know the name of the subfield and the value to store in it. The format for an address component can change among countries. The easiest way to see what components are expected for each country is to create a node for a content type that has an address field. With this example, you can go to /node/add/ud_address and try it yourself. For simplicity sake, let’s consider only 3 countries:

• For USA, city, state, and ZIP code are all required. And for state, you have a specific list form which you need to select from.
• For Germany, the company is moved above first and last name. The ZIP code label changes to Postal code and it is required. The city is also required. It is not possible to set a state.
• For Nicaragua, the Postal code is optional. The State label changes to Department. It is required and offers a predefined list to choose from. The city is also required.

Pay very close attention. The available subfields will depend on the country. Also, the form labels change per country or language settings. They do not necessarily match the subfield names. Moreover, the values that you see on the screen might not match what is stored in the database. For example, a Nicaraguan address will store the full department name like Managua. On the other hand, a USA address will only store a two-letter code for the state like MA for Massachusetts.

Something else that is not apparent even from the user interface is data validation. For example, let’s consider that you have a USA address and select Massachusetts as the state. Entering the ZIP code 55111 will produce the following error: Zip code field is not in the right format. At first glance, the format is correct, a five-digits code. The real problem is that the Address module is validating if that ZIP code is valid for the selected state. It is not valid for Massachusetts. 55111 is a ZIP code for the state of Minnesota which makes the validation fail. Unfortunately, the error message does not indicate that. Nine-digits ZIP codes are accepted as long as they belong to the state that is selected.

Note: If you are upgrading from Drupal 7, the D8 Address module offers a process plugin to upgrade from the D7 Address Field module.

Finding expected values

Values for the same subfield can vary per country. How can you find out which value to use? There are a few ways, but they all require varying levels of technical knowledge or access to resources:

• You can inspect the source code of the address field widget. When the country and state components are rendered as select input fields (dropdowns), you can have a look at the value attribute for the option that you want to select. This will contain the two-letter code for countries, the two-letter abbreviations for USA states, and the fully spelled string for Nicaraguan departments.
• You can use the Devel module. Create a node containing an address. Then use the devel tab of the node to inspect how the values are stored. It is not recommended to have the devel module in a production site. In fact, do not deploy the code even if the module is not enabled. This approach should only be used in a local development environment. Make sure no module or configuration is committed to the repo nor deployed.
• You can inspect the database. Look for the records in a table named node__field_[field_machine_name], if migrating nodes. First create some example nodes via the user interface and then query the table. You will see how Drupal stores the values in the database.

If you know a better way, please share it in the comments.

The commerceguys addressing library

With version 8 came many changes in the way Drupal is developed. Now there is an intentional effort to integrate with the greater PHP ecosystem. This involves using already existing libraries and frameworks, like Symfony. But also, making code written for Drupal available as external libraries that could be used by other projects. commerceguys\addressing is one example of a library that was made available as an external library. That being said, the Address module also makes use of it.

Explaining how the library works or where its fetches its database is beyond the scope of this article. Refer to the library documentation for more details on the topic. We are only going to point out some things that are relevant for the migration. For example, the ZIP code validation happens at the validatePostalCode() method of the AddressFormatConstraintValidator class. There is no need to know this for a migration project. But the key thing to remember is that the migration can be affected by third-party libraries outside of Drupal core or contributed modules. Another example, is the value for the state subfield. Address module expects a subdivision as listed in one of the files in the resources/subdivision directory.

Does the validation really affect the migration? We have already mentioned that the Migrate API bypasses Form API validations. And that is true for address fields as well. You can migrate a USA address with state Florida and ZIP code 55111. Both are invalid because you need to use the two-letter state code FL and use a valid ZIP code within the state. Notwithstanding, the migration will not fail in this case. In fact, if you visit the migrated node you will see that Drupal happily shows the address with the data that you entered. The problems arrives when you need to use the address. If you try to edit the node you will see that the state will not be preselected. And if you try to save the node after selecting Florida you will get the validation error for the ZIP code.

This validation issues might be hard to track because no error will be thrown by the migration. The recommendation is to migrate a sample combination of countries and address components. Then, manually check if editing a node shows the migrated data for all the subfields. Also check that the address passes Form API validations upon saving. This manual testing can save you a lot of time and money down the road. After all, if you have an ecommerce site, you do not want to be shipping your products to wrong or invalid addresses. ;-)

Technical note: The commerceguys/addressing library actually follows ISO standards. Particularly, ISO 3166 for country and state codes. It also uses CLDR and Google's address data. The dataset is stored as part of the library’s code in JSON format.

Migrating countries and zone fields

The Address module offer two more fields types: Country and Zone. Both have only one subfield value which is selected by default. For country, you store the two-letter country code. For zone, you store a serialized version of a Zone object.

What did you learn in today’s blog post? Have you migrated address before? Did you know the full list of subcomponents available? Did you know that data expectations change per country? Please share your answers in the comments. Also, I would be grateful if you shared this blog post with others.

Next: Introduction to paragraphs migrations in Drupal

This blog post series, cross-posted at UnderstandDrupal.com as well as here on Agaric.coop, is made possible thanks to these generous sponsors: Drupalize.me by Osio Labs has online tutorials about migrations, among other topics, and Agaric provides migration trainings, among other services.  Contact Understand Drupal if your organization would like to support this documentation project, whether it is the migration series or other topics.

According to the documentation:

• @variable: When the placeholder replacement value is:
  • A string, the replaced value in the returned string will be sanitized using \Drupal\Component\Utility\Html::escape().
  • A MarkupInterface object, the replaced value in the returned string will not be sanitized.
  • A MarkupInterface object cast to a string, the replaced value in the returned string be forcibly sanitized using\Drupal\Component\Utility\Html::escape().

Using the @ as the first character escapes the variable if it is a string but if we pass a MarkupInterface object it is not going to be sanitized, so we just need to return an object of this type.

And Drupal 8 has a class that implements MarkupInterface called: Markup, so the code above for Drupal 8 will look like this: 

   
public function content() { 
$markup = new Markup(); 
$links[] = Link::fromTextAndUrl('Google', Url::fromUri('http://www.google.com'))->toString(); 
$links[] = Link::fromTextAndUrl('Yahoo', Url::fromUri('http://www.yahoo.com'))->toString(); 
$types = $markup->create(implode(', ', $links)); 
return [ '#markup' => t('Links %links', ['%links' =>$types]), ]; 
}
 ​​​​​

And that's it, our string will display the links. 

If you want to see a real scenario where this is helpful, check this Comment Notify code For Drupal 7 and this patch for the D8 version.

Micky is a highly active and dedicated individual who is deeply involved in various movements and networks related to free software, cooperative business models, and community building. She is a worker/owner of Agaric, a member of numerous "free software" networks and movements, and actively uses tools like BigBlueButton, Drupal, and the GNU/Linux operating system to promote and introduce people to the world of free software.

Micky plays a crucial role in connecting different organizations and networks and she serves on the board of May First Movement Technology (MFMT), The US Solidarity Economy Network (SEN) and, SnowDrift.coop. As a member of The Tech Workers Peer Network a coalition of the US Federation of Worker Cooperatives (USFWC), she works to foster ongoing dialogues and collaborations in building a new economy network rooted in community-based, shared ownership. She also works with organizations like, Platform Cooperativism Consortium, The Free Software Foundation, The Center for Global Justice, The Greater Boston Chamber of Cooperatives, Restore the Fourth, and MassMesh, among others, to raise awareness about free software, cooperative business models, privacy protection, plus local and global opportunities to share knowledge. She has been a Keynote speaker, lecturer and panel member at conferences over the past 20 years.

As a member of the May First Movement Technology board, Micky actively collaborates with technical activists to provide people with the necessary information and tools to transition from being a local or small global network to becoming part of a global movement based on solidarity and cooperative principles. She strongly believes that the workers' economy requires free software tools to protect our freedoms, and she combines the principles of free software liberation and cooperative development in her presentations and talks.

Micky is also an active member of the Drupal community, an international group centered around a free software content management system. She has contributed to the Drupal community as a writer and has shared her experiences as a contributing author in the book "Ours to Hack and to Own," which is considered the handbook for the Platform Cooperativism Movement. The book was initiated by Trebor Scholz and Nathan Schneider at the New School in NYC and was listed as one of the top tech books of 2017 by Wired magazine.

As a public speaker, Micky passionately delivers the message of cooperative software development to various networks and movements. Her presentations cover a wide range of topics, including free software, cooperative tech development, personal digital privacy, worker-owned cooperatives, artificial intelligence, surveillance and capitalism, introduction to web technology, and the incorporation of the seven cooperative principles using Sociocracy, into work and living environments. Additionally, she provides software training for free tools such as BigBlueButton, Signal Instant Messenger, NextCloud, and encrypted email, and she can offer advice on alternatives to proprietary software.

Outside of her professional endeavors, Micky has a rich personal history. She was a resident of Weston, CT in the 50s, 60s, and 70s and currently resides in Boston, MA with her long-time partner John M. Crisman. Micky was a member of a few bands in Boston, MA during the 1970’s through the 90’s, such as The Phantoms. The band is featured in the book "Hit Girls" by Jen B. Larsen, a compendium of female-led punk bands in the USA during the late 70s and early 80s as well as an exhibit at Harvard's Loeb Music Library in 2024-2025.

Micky's dedication to her work and her commitment to promoting free software, cooperative business models, art, music and community building make her a valuable asset to the movements and networks she is involved in. She continues to make a positive impact in the world through her activism, public speaking engagements, and the creation of site like CommunityBridge, which prioritize privacy and provide a more secure environment for meaningful video chats between individuals who share a passion for education and activism.

Here is a trailer for a video documentary about Micky's High School days  - It is Rock and Roll History - The High School that ROCKED.

Request an interview, presentation or workshop with Micky

Presentations and Workshops:

*Updated list and references available upon request.  

2021

• Live interview - Sweden CivicTech Lab - The Two Money Problems

2020

• Hosted workshop: Surveillance Capitalism, Predictive Analysis and YOU at HOPE 2020  (Hackers on Planet Earth)
• Live interview on Radio Statler at the HOPE 2020 conference
• Libreplanet LIVE online 3/14/2020. We hosted a discussion at 4:20 ET on fsf.org - Libreplanet 2020
• Surveillance Capitalism, Predictive Analysis and YOU - Lecture, Biblioteque, San Miguel de Allende
• Internet Security - Workshops - Biblioteque, San Miguel de Allende
• Boston College - presentation on AI and Predictive analysis
• Colorado.edu online interview on Cooperative development and Agaric values

2019

• Platform Cooperativism 2019 - Who Owns the World? - New School, NYC
• BADcamp 2019 - San Francisco

• Mass Pirate Party - Ring Doorbell Surveillance
• Keynote - LibrePlanet 2019 - M.I.T.
• Micky's Resource Links from LibrePlanet Keynote
  • How can we prevent the Orwellian 1984 digital world? - March 2019 - M.I.T. Boston, MA USA
• Keynote - NERDsummit - UMASS Amherst
• UjimaBoston
  • Series of four workshops on Free Software and Platform Cooperativism in January 2019
• Chris and Micky present at Boston College on AI and Free Software
• Micky and Ben present at DrupalCon Seattle on Scaling Community Decision Making

2018

• 3rd Regional Workers Encuentro
  • "Communications & the Workers' Economy" (workshop) Mexico City CDMX
• Center for Global Justice Assembly
  • "Securing your devices and using free software" (workshop) San Miguel de Allende, Mexico
• LibrePlanet 2018
  • Connecting communities with schools and free tools (workshop) M.I.T. Boston, MA USA, Facilitators: Micky Metts, Chris Thompson
• New Economy Coalition's CommonBound - St. Louis, MO USA
  • Technology for the New Economy

2017

• Open.coop 2017 - London University, London, UK
  • Panel: Empowering digital collaboration: Introducing the open app ecosystem
  • Workshop: Designing interoperable apps for the open app ecosystem