Skip to main content

A CiviCRM extension to generate – and pay out – Revenue Sharing Language plans

Written by Nicol Wistreich on . Posted in Blog.

CiviCRM is regular used to received payments in – donations, ticket sales or membership fees – but what about automating payments out?

CiviSplit is a set of three new beta extensions to let CiviCRM admins automate paying income out to multiple parties based on a set of pre-defined rules. It could split the income from a fundraising campaign between multiple charities; or share ticket sales for an event between a band and an NGO after the organiser’s costs are deducted; or even automate the payout of dividends within a worker cooperative after expenses.

The work is being done by Matthew Wire of MJW Consulting, with support from Rich Lott of Artful Robot, and has been funded by Grant for the Web as part of a broader project looking at how to fund and support independent film online (my personal passion on the web since 1999).

The heart of CiviSplit

CiviSplit components will first let admins create a revenue sharing plan, then save this in a form that can’t be changed later once income arrives, then periodically check the balance of an account, and pay out what’s in there according to the plan. To achieve this there’s a few new concepts:

  • We’ve created a YAML based syntax called Revenue-sharing Langauge (RSL), to describe CiviSplit agreements in a human-readable form; that can also be the basis of payout calculatations. This is how we can ensure that a payout plan that’s agreed on is the same that’s paid-out in the futture by CiviCRM. As well as feedback from Matthew and Rich, am grateful for the input of Aidan Saunders, lawyers Silvia Schmidt and Andrew Katz, and comunity-ownership expert Dave Boyle in preparing this.
  • These RSL agreements are built in CiviSplit using a drag-and-drop builder called Waterfall (a term used in the film world to determine the order people get paid). This (right) has been implemented as a standalone script so it could work with other systems – and has been built first in a framework-free native-JS by Mark Boas and then with Svelte JS by Rich Lott.
  • We register negative payments on a Civi contact record’s contribution screen to denote payments to someone, rather than from someone.
  • We’re using a third party digital wallet system (Uphold) to create a unique collecting ‘account’ for every CiviSplit agreement, so that monies received are ring-fenced before being split out. A new Uphold processor will manage this, and make payouts to any IBAN bank account number.

How will this all work?

  1. Create a payout plan: After setting up an online wallet address in their settings, users should be able to create a new CiviSplit agreement. Each step in an agreement executes sequentially with all payees at each step paid pari passu (at the same time until all are paid). So, for instance, a charity fundraising event may first want to pay back expenses to three people who are out of pocket; then they will split the income 50-50 with the promoter until the promoter has earned a pre-agreed $500 fee; and then they will take 100% of the income. This would be built by the drag-and-drop builder, creating some RSL that looks something like this:
---  
name: “Fundraising event share”
currency: USD
steps:
  - 
    type: fixed
    payee:
      - [ "Venue hire balance", 1234 5678, IBAN, 250]
      - [ "Catering company", 1234 5678, IBAN, 150]
      - [ "The DJ", name@example.com, paypal, 200]
  -
    type: percent
    cap: 1000
      - [ "Charity", 1234 5678, IBAN, 50]
      - [ "Promoter", 1234 5678, IBAN, 50]
  -
    type: percent
    payee:
      - [ "Charity", 1234 5678, IBAN, 100]
  1. Save and generate a Plan. After adjusting the agreement to ensure everyone is happy with it, the CiviCRM admin ‘generates’ it, which makes it uneditable, and creates a wallet address for the agrement, which is then saved in the RSL. Finally a cryptographic hash of the agreement is made, which will change if anyone tried to alter the agreement. A copy of the plan can then be saved as a PDF, and revisited online at a URL based on the hash. This adds some means of protection – future payouts can be checked they are still being applied to the same RSL plan, and hashes can be compared to ensure they mayvch and no changes or errors have been made.
  2. Use a scheduled job to trigger payouts. At regular intervals defined by a Civi Scheduled job, the wallet will be checked for a balance, and provided it’s greater than the minimum payout amount (currently €10/£10/$10) it will be split out between the payees as defined in the agreement. The next time it’s triggered payments will pick up where they left off. Pending and unresolved payouts will be held until resolved. Payouts will be trackable as entities so reports and notifications can be made to recipients of their income.

How could this potentially be used?

  • Collective fundraising. Tythe.org is a fundraising protal for nine small charities. The founders recognised that many small charities spend a lot of money and energy on fundraising; while many people who want to donate struggle to choose between multiple causes. Tythe simplified the process by selecting 9 charities, and donors pay a standing monthly payment and can choose how they want their payment split. CiviSplit could make it easier to create and automate these kind of groupings of related campaigns and causes, while deducting costs before the split (ie hosting, marketing or an accountant).
  • Peer-to-peer fundraising When Northbridge Digital built a large Civi/Drupal site to manage a large sponsored walk; donors could choose which charities from a select group they wanted their money to go to. This was calculated at the end by adding up the different fields users had entered; this approach could automate that.
  • Cooperatives and ‘informal cooperations’. CiviCRM is already used by a number of cooperatives; some of whom track dividends to workers/users in the app. An automated payout processor could also accomodate other less formal cooperations. For instance where three Civi agencies share the cost of building an extension, then run a fundraiser to continue its development (or operate a ‘donate here’ button after launch). Make it Happens could be tied to specific CiviSplit plans so donors can see exactly how their money will be spent, and track those payouts.
  • Independent creatives. Independent creators of films, art, events, books or music – like many open source developers are driven by a passion or itch, more than the (highly unlikely) goal of getting rich. For many, managing the finances is a burden; at the same time for collaborations like film productions or recording an album there can be a mix of debts, deferred fees and promises to pay someone back, which especially matter in the event a project earns something. The indie film world is littered with stories of people who worked for free on the promise of a deferred fee or profit share in the event of success, only to see nothing – and these stories inspire some of the original motivation here. But we also know, from LiveAid and Peter Pan/Great Ormond Street Hospital to Warchild and Comic Relief/Fantastic Beasts there’s long been very successful collaborations between the creative and charitable worlds, so perhaps this could support some new ones.

Shifts to automation in many areas of technology are full of problems, and it’s important to stress that we’re not proposing charities ditch their accountants for an experimental CiviCRM extension just yet. At the moment the wallet address created by the agreement will only receive one type of income stream – micropayments using Web Monetization, which is a new protocol streaming money from web users to websites as they browse the web, designed to improve how news and media is supported online. It will not be until next year that normal one-off and recurring card payments to wallets from non-Uphold users should be available. But these tiny payouts – a few cents or pennies from lots of people regularly – is where automation saves time and seems a safe place to experiment.

Glasgow SECC

Online video’s carbon footprint could be bigger than aviation. What can we do?

Written by Nicol Wistreich on . Posted in Blog.

Of this carbon footprint, the biggest impact by far (excluding non-web activities like blockchain mining or buying a new phone every year) is streaming video. The IEA claims streaming services from video and games will account for 87% of consumer internet traffic next year (2022), with video doubling to 2.9 zetabytes of data by then from only 2019. The rate of growth seems exponential – and video is 2-3 times worse than conventional broadcast TV.

This is bad news for creators: the bigger your audience, the more viral your videos, the worse the climate impact.

Dryden Williams, founder of website footprint optimiser EcoPing estimated that the global carbon footprint of just one adult video site is over 580,000 tonnes of CO2 each year – more than the entire footprint of Gibraltar, Granada or the Seychelles.

It’s not only CO2, data centres want water…

Worse, in the rush to cut CO2 emissions, big data centre owners like Google have switched from energy-intensive air conditioning for cooling, to water cooling. This has created a new demand for billions of gallons of water, which is particular problematic given data centres are often built in hot, dry regions. Time magazine found that in some places the demand for water for data centres could be from 10% up to 50% of a district’s water needs. “In Red Oak, Texas, a town about 20 miles south of Dallas, Google wants as much as 1.46 billion gallons of water a year for a new data center… Ellis County, which includes Red Oak and roughly 20 other towns, will need almost 15 billion gallons for everything from irrigation to residential use.”

This is why climate researchers specialising in ICT increasingly say we can’t only focus on CO2 but must look at full life-cycle impacts. It’s not only water usage, but resources in the equipment from data centres and consumer devices – as well as the energy source itself.

“In France, we tend to follow a Life-Cycle Assessment (LCA) approach that includes four factors: GHG emissions (CO2eq), water consumption (Litres), abiotic resources consumption (Sbeq. or Antimony equivalent) and energy consumption (MJ). Like everybody else we measure these impacts on three different poles: data centers, networks and end-user equipment… So what’s the difference with the English-speaking approach? The main focus seems to be on reducing carbon emissions through the vector of electricity.”

Gauthier Roussilhe – gauthierroussilhe.com/post/digital-sustainability-french.html

So cancel film & TV then?

If all the different impacts could be tallied precisely, then given that many environmentalists call for us to reduce not offset – is the conclusion for filmmakers to stop making videos people want to watch and share online? Perhaps to ditch cliffhanger episodic TV for a feature film of the same story or preferably a short film or radio play? Must we add ‘Netflix and chill’ to the things to feel bad about?

Given the pushback against relatively simple behavioural changes like refill stations, it’s hard to imagine enough people wanting to ‘stop watching video online’. The only option therefore – until the grid is fully decarbonised – would seem to be climate impact offsetting.

This does three things:

  • It first works to force us to quantify video’s impact as it moves from servers, across Content Delivery Networks through an ISP into homes and offices, which in turn lets us see what parts of the lifecyle has the most emissions;
  • It generates finance for useful CO2eqv removal, environmental preservation, transition and restoration projects;
  • This cost also incentivises and rewards us for adopting cleaner architectures, while penalising dirtier ones;

It’s like a self-imposed, voluntary carbon-tax. There’s fair criticism of offsetting being used for greenwash, such as when Leon claimed their beef burger was carbon neutral because they’d paid some farmers to not burn down rainforest; but for impacts we’re stuck with until we’re on fossil-fuel free infrastructure, it seems a lot better than doing nothing.

What if you could pay to ‘offset’ as you browse?

Web Monetization (WM) is a new web protocol that streams every second tiny micropayments between a website owner, and someone browsing their site for as long as they’re on it. WM’s designers wanted to ‘stream payments’ in the same way the Internet streams data whenever an email, file or website is loaded. So given every byte of data has a potential carbon footprint – could streamed payments be used to offset streamed data in real-time?

In other words, what if Web Monetization could compensate exactly for the environmental impacts of data consumed online?

For example, suppose we want to offset a 90 minute documentary feature streamed online.

If we agree that streaming one hour of video is responsible for 100g of CO2eqv emissions –which is the rate given by research group DIMPACT, backed by Netflix, ITV and the BBC– we know that streaming the full film would release 150g. We then need to find a cost for taking this much CO2 out of the atmosphere irreversibly. Using the expensive, over-engineered, but reliable Orca project that would be $0.096 / 100g or $0.144 for the full film. This is well below Coil.com’s payout of $0.36/hour.

What’s unique about Web Monetization is, as a protocol for streaming micropayments, it could pay out, say, $0.015 for someone who only watched 10 minutes of the film, or $0.003 for a 4 minute music video – while handling each transaction invisibly in the background.

The footprint of 60 episodes of Battlestar Galactica streamed at 4k to a flatscreen TV is obviously much higher than a dozen Tik Tok videos on a phone. Web Monetization, coupled with analysis of the user-agent and location, could ensure that offsetting costs are proportional to media-type, energy mix and use, while protecting privacy.

Who might sign up for that? It could be done at consumer, platform or creator level. For e.g.:

  • a climate committed consumer or employer, who wants to track and offset their online footprint. This could bring a new group of users to Web Monetization;
  • a platform wanting to offer viewers 100% compensated videos, adjusting the cost-per view relative to device and geographic location of the viewer;
  • a filmmaker wanting to ensure that their film is 100% offset across its full lifecycle. Organisations like We Are Albert currently focus on production.

How to do this? Three initial inquiries

Before this kind of approach can be taken seriously there are three research-heavy questions that need to resolved around monitoring, methodology and how to compensate:

  1. Monitoring. First, we need to assess what impacts can be known and tracked per stream and what must be averaged or guessed at. While adjusting for variables per stream is much more work (and processing, which has its own cost) – it could incentivise more responsible behaviour. Variables that make a big difference include:
    • Screen size: a 50-inch LED television consumes 100 times more electricity than a smartphone and 5 times more than a laptop (IEA): “because phones are extremely energy efficient, data transmission accounts for more than 80% of the electricity consumption when streaming.”
    • Device type & age: Every year that equipment is kept and repaired/upgraded rather than replaced its embedded resource impact declines. “Before you start using a piece of electronic equipment, it has already emitted 70% of its lifetime CO2” François Zaninotto.
    • Geography. Carbon intensity is deeply tied to the country of origin – for nuclear France and renewable Norway, the CO2eqv emissions per KwH of energy is under 60g, while the European average is 300g (electrictyMap) and in the US it’s 417g.
    • Media production intensity. An average feature film generates 2840 tonnes of CO2 according to 2000’s Arup/BFI/Albert Screen New Deal study – equivalent to 150 transatlantic flights. This is sometimes offset before release; but often isn’t. A viral video filmed in the park on a phone obviously emits close to nothing.
  2. Methodology. ie, decide an impact model and scope to give a resource and carbon intensity figure per hour of streaming. The scope might include production impacts or ignore these given the difference between a superhero movie and a chat to webcam. Once a model is chosen, it should give a baseline impact which could then be adjusted by variables wherever they are known. Modelling only CO2 isn’t straightforward:
    • at one extreme is the Shift Project who suggest a carbon intensity of 400g of CO2 / hour of video.
    • at the other the much more conservative IEA, estimate it to be 36g of CO2 / hour of video.
    • between these is DIMPACT, a research project of Bristol University supported by the UK TV and streaming industry has settled on ~100g CO2/eqv per hour. However, this excludes equipment manufacturing and the media production impacts.
  3. Compensation. The final step is deciding on a price for these impacts – ie what does it cost to ‘offset’ them? Of all the new areas in this research, the offsetting industry seems the one with the strongest views and divergence on methods and costs – which I’m still trying to grasp. Looking just at CO2, for instance:
    • at one extreme there are projects that meet the minimum BSI PAS 2060 standard, which can include ‘forest preservation’ offsetting where loggers and landowners can get paid an income by agreeing not to chop or burn trees down. There’s also tree planting, that might mature in 40 years if they don’t combust first. IHS Market put this at $34.99/tonne in May 2021 (ie $0.0035/hour) but there are ‘gold standard’ schemes that are even cheaper.
    • At the other extreme, there’s physical CO2 removal and burial with a project like ClimeWorks’ Orca for $0.096/hour ($960/tonne). Orca’s offsetting is considered to be one of the costliest around, but would still be comfortably under Coil’s $0.36/hour payment.
    • In between there’s a number of experimental but unproven CO2eqv removal projects – which if successful could take CO2, methane and other climate gasses out of the atmosphere. Carbon Plan.org has a good list they’ve built up from helping assess projects for Stripe and Microsoft.

To answer these questions there’s a big shortfall in data as companies like Google, Amazon, Apple and Facebook aren’t required to make public their full use of resources, energy and water, and most of them don’t.

While this all points to the importance of rapidly decarbonising the energy grid everywhere, of the legislative low-hanging fruits to be sought at COP26 in Glasgow, a cheap-but-impactful one is to mandate that large technology and web companies publish full life-cycle data on carbon, resource, energy and water (CREW) use. This would allow individuals and business to make informed choices about where to host, stream and watch video – and provide the needed data to let them offset/compensate that impact if they want. If the data was audited, it could help ‘the market’ reward companies who improve their impact – on the assumption any consumers, platforms or filmmakers wanting to reduce their own impact would favour them, even with higher costs.

Could streamed micropayments offset other processes?

Maybe streamed micropayments –aka Web Monetization– that flows like data for the duration of an activity, has other applications during the fast decarbonisation our societies and economies need to meet the 1.5C goal of the Paris Agreement. Perhaps you could have streamed micropayments for every KwH of solar energy generated, or for web hosting in a fossil-fuel-free energy country?

Or perhaps micropayments go back to consumers for every minute listening to music online with the screen dark, or for watching lower-resolution video, or using a refurbished older model phone, or streaming off-peak when energy demands are lower. Or even for pricing in the impacts from different parts of network infrastructure as data moves around the world between countries with different energy mixes – with a different cost if your video CDN is using a server cluster in coal heavy Poland over nuclear-France or hydro-Norway. It’s an carbon accountant’s dream, although potentially an engineering heavy answer to the problem.

Ultimately, the work coming out of communities like ClimateAction.Tech is inspiring because small changes can have big impacts:

“Just last week I reduced global emissions by an estimated 59,000 kg CO2 per month by removing a 20 kB JavaScript dependency in Mailchimp for WordPress. There’s no way I can have that kind of effect in other areas of my life.”

Danny van Kooten – https://dannyvankooten.com/website-carbon-emissions/

So while the data is incomplete, and the divergence in opinion from experts can be dizzying and make it tempting to give up for fear of getting it wrong – the scale of the climate crisis and the growing impact of online video towards that makes it feel that doing anything is better than nothing. Mistakes can be corrected, models and estimates can be adjusted as more data is made available. The key thing is to start.

Introducing Revenue Sharing Language – a Web Monetization answer to Hollywood accounting?

Written by Nic on . Posted in Blog.

Scarlett Johansson’s recent contract dispute with Disney and their thunderbolt response that she had ‘callous disregard for the suffering of the pandemic’ showed Hollywood’s power players on the brink of civil war. The LA Times suggested the fight, and Disney’s diss at Marvel’s biggest female star, was really about a bigger question: “how should stars and filmmakers be paid for movies and TV shows now that the business model is shifting quickly from one based on box office and television ratings to one reliant on online subscriptions?”. It’s easy to calculate how to earn a cut of ticket or DVD sales for a film, but what about ‘all you can eat’ flat-fee subscription video services where some people watch one film a month – and others dozens a week?

To those in the Web Monetization (WM) community, the answer is maybe simple – they could get a share of every second that a subscriber is watching for. A Coil.com plugin in the subscriber’s browser, streams $0.36/hour to the website’s Payment Pointer for the first 12 hours each month, and tapers off after that. Amazon Prime also pays filmmakers per seconds viewed, tho at a much lower and well-guarded, rate. Problem solved? Web Monetization could turn subscription income into profit-share for every second viewed of any film that works for all but the biggest platform users.

However, a Payment Pointer only points to one wallet, in reality, the premiere of Scarlet Widow 2: Implausible Resurrection on Cinnamon in 2024 would want to pay out to many different wallets: the website, the production company, Marvel and all the stars guaranteed a share of the profits.

Sharing Web Monetization payouts precisely

Probabilistic Revenue Sharing is WM’s answer to this, which works by letting the hosting website list a number of payment pointers and a value for what percent of visits each pointer should be the receiving wallet for. If it’s 50% Disney and 50% Scarlett; every other view of the page would load each payment pointer, so the amount paid out should be largely equal after a few hundred views. But for videos with a dozen or more payees, or feature films with 120 minutes per view and only a few dozen views, it’s easy to imagine how quickly probabilistic payouts become less than precise.

In our Grant for the Web project, MOVA we’re taking another approach – with a CiviCRM tool to log into the wallet behind a payment pointer, check the balance, then distribute payments to multiple parties depending on a set of pre-agreed rules. This opens up the possibility of more creative repayment structures that take account other obligations – like paying back the drone hire company for your shoot and the cinematographer’s deferred fee, then the loan from your rich great-aunt, before splitting what’s left fairly between the production cast and crew. And how much easier might it be to get that rich great-aunt’s loan if she doesn’t have to depend on her nephew’s accounting skills to get repaid?

Once we started exploring the tool we hit a question: how can payees be sure that they are receiving the right amount? Even ignoring fraud, how could the system check that payouts are accurate? Could there be a machine- and human- readable version of the revenue split that could be hashed/printed out and also used as the basis for payouts? This idea of a human and machine readable agreement is sometimes known as a Ricardian contract. This would have the benefit of letting us develop something that other systems could read and produce; using, like Web Monetization, Interledger and Payment Pointers, a decentralised approach. Researching the space it soon appeared that while there is a sophisticated machine readable rights language – Open Digital Rights Language; and there are multiple systems for writing up contracts with machine readable syntax, including Smart Contract templates, and the Accord Project, we’ve not found a syntax for revenue sharing agreements.

Introducing RSL

Revenue-Sharing Language (github.com/openvideotech/rsl) is a proposed YAML-based vocabulary and syntax to describe how revenues received at a wallet, pointer or account should be distributed. It uses YAML to make it easier for non-developers to read, with agreements structured as a series of steps. MOVA’s revenue-sharing-agreement builder will output this syntax, which will then be used as the basis for payment distributions on an ongoing basis by the CiviCRM extension we’re building.

Each step in an RSL agreement pays out either fixed amounts or a percentage split – before flowing onto the next step. Steps could have one payee or hundreds; and each payee can be identified with an ILP payment pointer (or a bank account, wallet address or other payee address). RSL isn’t intended to generate or implement the agreements – that’s the next task in our project – but rather to provide an open serialisable basis for structuring them.

In the spec for RSL – which we are inviting comments and feedback on – we have six examples of different kinds of payout structures. For instance, the below YAML maps a traditional publishing advance deal where a writer gets 25% of royalties, of which 10% goes to their agent, after they’ve repaid their advance to the publisher in the first step.

---
name: "Best of times, Worst of times"
description: "Book deal for the new novel by Charlene Dickens"
pointer: ilp.uphold.com/191320x91
currency: EUR
steps:
  -
    type: fixed
    payee:
      - ["PRNG House", $ilp.example.com/prng, ilp, 40000]
  -
    type: percent
    payee: 
      - ["Charlene Dickens", 12345678/12-34-56, uk-ac, 22.5 ]
      - ["Internet Aritsts Management", payment@example.com, paypal, 2.5]
      - ["PRNG House", $ilp.example.com, ilp, dbse, 75 ]

Of course these agreements could get very complex and RSL probably wouldn’t be able to accommodate sophisticated, high-end royalty agreements. Gerard Butler’s contract payout dispute over Olympus has Fallen, for example, appeared a few days after Johansson’s and “entitled him to 10% of net profits, plus 6% of domestic adjusted gross receipts above $70 million and 12% of foreign adjusted gross receipts above $35 million… [plus] 5% of net profits” to his production company and “certain bonuses for hitting box office thresholds”.

Hollywood accounting

Once we look at LaLa Land salaries and bonuses it may feel a little abstract – a company making billions in profits on one side and a star earning more per movie than any YouTube influencer will probably make in their lifetime. But Butler and Johansson are the tip of the iceberg of ‘Hollywood accounting’ long famed for finding creative ways to ensure that, for instance, Return of the Jedi, Spiderman, Batman and Harry Potter: Order of the Phoenix are all technically loss-making —despite huge commercial success— so never have to pay out profit shares to their cast and crew.

And many contract payment disputes outside of Hollywood involve regular creators who’ve hit it big. Consider Nomcebo Zikode, the singer of last year’s lockdown hit Jerusalema (440 million views on youTube for the original so far, and countless views for the tribute dances) and who claims to still have not been paid one cent because of a contract dispute with DJ Master KG who she made it with. KG counters that the issue is Zikode wanting a 70-30 split, not the 50-50 he claims they agreed. The lack of a documented agreement Zikode and KG can reference leaves it potentially down to whoever can afford the better lawyer. This is a sad outcome for a song that gave cheer to many millions of people during lockdown both listening and dancing to it.

Fenomenos do Semba, uncredited choreographers of 2020’s viral hit Jerusalema

The TikTok Dance Strike – credit… and payment?

Dance mashups brings up another question – that of unpaid and often uncredited choreographers of viral hits. For example Fenomenos do Semba – the Angolan dancers whose original eating-while-dancing choreography for Jerusalema doubtless helped the hit, and made it easy for others to copy the dance and make the countless remix videos.

This subject got attention this summer after a Jimmy Fallon segment where Addison Rae danced viral TikTok dances without crediting the choreographers. While Mya Johnson, the 15-year-old whose choreography to Cardi B’s Up was performed on the show was gracious, this lack of due props drove this summer’s Black TikTok Dance strike.

Attribution will doubtless improve (the Tonight Show and Rae both had to respond to the backlash) – but what if a hit songs’ revenues could be shared with choreographers whose work goes viral?

In RSL we have proposed a ‘Variable Syntax’ which would allow making agreements with people who aren’t known at the time the agreement is made. It was designed so that a filmmaker could share their Monetization income with a website or influencer who hosts their film, but it could maybe also work with future choreographers whose routines help a song go viral. Given the complexity of making that work accurately and securely, we aren’t currebuilding out Variable Syntax during this round of work within MOVA, but it’s included in RSL as it seems interesting – and as an open language maybe others will try to implement it.

So I’m very pleased to share RSL for feedback, criticism and review. It’s been created with much helpful input from readers including Mark Boas, Laurian Gridinoc, Rich Lott, Aidan Saunders, Silvia Schmidt and Kevin Wittek — many thanks to them – and also Adam Davies, for helping inspire this tool, following the years of manually calculating royalty payouts for our Film Finance Handbook.

Interview Archive screenshot

What would a video Wikipedia look like?

Written by Nic on . Posted in Blog. 1 Comment on What would a video Wikipedia look like?

I hope you forgive the clickbait headline, reader, as our project isn’t a video Wikipedia. But the subject is a good thought experiment to introduce some of the motivations around ‘open video’, and explain some of the backstory to our project MOVA (Monetizing Open Video Assets), which has just started this week.

‘Video Wikipedia’ is a long-discussed concept that slams fast and hard into technical, social and funding questions: what is the interface for collaborative and transparent video editing that’s as easy to use as a Wiki? How would you host and serve that much video? How could you moderate for quality, accuracy and legality of media? How would such a project be funded? What might motivate videomakers to contribute?

While Web Monetization may offer answers to the funding question, the scale of the other challenges, not to mention the carbon footprint of video online versus text, triggers an immediate question – why does the planet need a video wikipedia? Simply literacy: for the 773 million adults around the world who cannot read, two-thirds of whom are women, Wikipedia is useless – and that’s before considering many people’s low reading skills or learning styles. According to Wikimedia Sweden, a quarter of Wikipedia users prefer or need text in a spoken form. For as long as Wikipedia can’t serve these people’s needs, YouTube will – yet without an editorial process to ensure quality, accuracy or ‘neutral point of view’.

Pratik Shetty, the co-founder of the most recent attempt to solve the problem, VideoWiki, was inspired after seeing the presence of mosquitoes near his building and warning the building’s security guard they could cause dengue fever. The guard reassured him that he could treat dengue by himself without visiting a doctor, showing a YouTube video that listed five at-home remedies. When Pratik advised him to get his medical advice from Wikipedia not YouTube, the guard explained he cannot read.

VideoWiki Founders(L:R) Pratik Shetty, Hassan Amin

Shetty and Hassan Amin’s VideoWiki isn’t the first attempt to solve the problem; the subject has a long history – WikiTV dates back to 2005, and in 2008 open source collaborative video editor Kaltura added a MediaWiki extension and announced a partnership with Wikimedia to bring rich media to pages. But it struggled to take off, and the VideoWiki lists under 150 articles articles made into rich, editable media. As Wikipedia itself says, the incorporation of video into wikipedia is still at ‘a very early stage’ and although there are 135,000 videos listed on WikiMedia Commons many seem likely to have been generated by the Open Access Media Importer project, a bot which imports public access scientific video from PubMed Central.

As I left the FOSDEM Videowiki session in Brussels in February 2020, I found myself wondering why there wasn’t more open video on Wikipedia. Part of the answer is simple: money. It’s far cheaper to write a Wikipedia entry or share a photo than produce a professional-quality video. Furthermore, Wikimedia’s Creative Commons licensing doesn’t allow for non-commercial, so filmmakers wanting to still sell their film to Netflix can’t also share parts of it to Wikipedia without allowing someone else to then sell a version of it to Amazon.

As it happened I’d just that day filmed an interview with the co-founder and former ‘Benevolent Dictator’ of CiviCRM, Donald Lobo for an ongoing, somewhat neglected project of mine, making Creative Commons SA video around the CiviCRM community: screen.is/civicrm/. It had struck me that Lobo’s interview would be interesting to people outside of CiviCRM as well: he was employee number five at Yahoo; and thru his Chintu Gudiya Foundation is involved in a range of transformational open source development projects in India. I’d been lucky to get the interview at short notice, so what gave me the right to exclusively own a 30 minute interivew, for the two minutes that might make its way into a final film of mine?

Interview with Donald Lobo

At another FOSDEM session on Wikibase, I learned of JSTOR’s Interview Archive for Peter Kunhardt’s HBO film about Martin Luther King’s last three years: King in the Wilderness (pictured top). The film is a historical document, but so are the uncut testimonies of each of the interviewees. JSTOR labs created a searchable database of each interview for the documentary, complete with transcripts, tagging, metadata and background information from Wikipedia. https://www.youtube.com/embed/MutfvpFS6G0

JSTOR’s Ron Snyder talking thru the project explained how ‘some of the best stuff ended up on the cutting room floor’. This is something I’ve mentioned before here and is well known to filmmakers but not necessarily viewers — just how much footage is never shared in order to make a tight and snappy final cut. Peter Kunhardt’s Film Foundation, has since put the interview archives of more documentaries online but not with the JSTOR interface and it’s not caught on further.

These three takeaways from my weekend in Brussels at FOSDEM were whirring around my mind as I got on the train back to London:

  • Wikimedia doesn’t have enough good quality Creative Commons BY/SA licensed video;
  • Documentary filmmakers effectively bin millions of hours of footage that never makes their final cut each year;
  • For some cultural projects the full unedited video provides value and importance as a source text. If you’re lucky as a filmmaker to interview a historically or socially significant figure – is there a responsibility to share their uncut story? It also can add context at a time when the stripping of context on social media is, in the words of Charlie Warzel, creating a ‘one-dimensional space’ for culture.

After the Grant for the Web first call was announced and I started testing Web Monetization, came an ‘aha moment’. What if the potential for Web Monetization income could encourage filmmakers to open up more of their assets? More open assets could mean, eventually, better video on Wikimedia and more interesting works using those assets. Perhaps it can even share monetization between orginators and remixers, as Mark Boas has discussed with Hyperaudio.

Over two GftW application processes, the seed of an idea germinated into project MOVA, which I’m really excited to finally getting going on – with a great team and perhaps the most exciting technology – in Web Monetization – I’ve seen in 21 years thinking about filmmaking on the web. In the coming months I’ll dive deeper into what we’re building, and the surrounding questions around video rights, discovery, moderation and sustainability, but for now – hello – I’m really looking forward to this journey.