LCA 2017 Day 4

Fresh from a nice dinner last night and a run along the waterfront and through the bush this morning, I’m ready to tackle another day. The number of little bush walkways and river cuttings in this part of Hobart makes for some very pleasant mornings.

I am living in the future; while there’s a lack of jetpacks, while I was running down the hill from the University accommodation I took a video call from Ada and Rosa as they drove into town, in another country.

(Slightly less awesome: dropping my room key while I took my phone out. Happily the University dorm staff were delightfully friendly about replacing it.)

Opening Remarks

The Outreachy fund raising has leapt up, tripling from yesterday. This is no doubt aided by the press at the dinner last night. “We encourage you to buy tickets with your credit card.”

Consider the Maintainer

Nadia Eghbal @nayafia

Nadia has spent the last 18 months researching how to better support people doing the work; the title of the talk is named after a David Foster Wallace called Consider the Lobster, which is concerns a lobster festival which uses over 25,000 lbs of lobster, boiling the lobster in alive for freshness. Just as Foster Wallace asked whether it is acceptable to boil animals alive for gustatory pleasure, when it comes to open source the question is “Is it alright to compromise, or even deliberately ignore, the happiness of maintainers so we can enjoy free and open source software?”

This is not intended as a polemic, but a set of questions to think about.

What, exactly, is the problem?

• More people are consuming open source software than ever before.
• e.g. in 1998 Netscape got 180k downloads in two weeks; in 2017 the lodash package had 18 million downloads in two weeks.
• In 2001 SourceForge had 208 thousand registered users. In 2017 GitHub has 14 million.
• But two-thirds of the top GitHub projects have only one or two maintainers.
• So while use has exploded, maintainers have not.

But why?

1. Style of production has changed: the production of software has many smallish projects.
2. Being a maintainer isn’t glamourous.
3. 1% of people produce the content 99% of people consume.
   • “Rapid evolution poses the risk of overwhelming the system … this introduing errors more quickly than the system can fix them” - Steven Weber, The Success of Open Source.

Many users and contributors are new to software development; “Git is too hard”, notes one maintainer who Nadia quotes. There is limited support, both in terms of tools, and in terms of mentoring of deelopers and maintainers themselves.

Increasingly users see themselves as entitled to support, and are angry when they don’t get it. This can include people who are themselves developers, but flip into “angry user” mode when interacting with other projects - and these are very senior people in their own communities, so they influence others to behave the same.

Why aren’t we talking about this?

Maintainers are told this is normal and expected - it is difficult to know when and how to push back.

• A trip back in history:
  • rms noted that his goal is to spread freedom, not to be popular. [I would note that surely being popular spreads freedom, but never mind that for a momen]. Nadia notes that this approach comes from a good place, to absolve developers from legal liability for things they have produced.
  • The Debian Social Contract is another example; all the examples are focused on the needs of the users of Debian.
  • The Open Source Summit implies, according to Eric Raymond, is that we “intend to convince the coroporate world to adopt open source”. There’s nothing there, or in the OSI manifesto, about helping the producers of FOSS software.
• Both free software and open source are oriented around the user, not the producer.
• What might the four freedoms of open source producers look like?
  • The freedom to decide who participates in your community.
  • The freedom to say no to contributions or requests.
  • The freedom to define the priorities and policies of the project.
  • The freedom to step down or move on from a project, temporarily or permanently.

“This puts the onus back on the user.” [I would argue that user hostility is already the state of and problem with many projects, but never mind…]

Other things maintainers need help with

1. Community best practise.
2. Project analytics. Nadia acknowledges that this a controversial view, but she argues that we should not criticise developers for instrumenting their projects for better analytics/telemetry.
3. Better tools and bots.
4. Conveying support status. “Right now there’s an odd view that maintainers are required to respond to everything.”
   • A standard set of status such as “finished, no longer accepting contributions.”
   • Closed communities with vetted contributers.
5. Finding funding.
   • Some people don’t want to accept the obligations that go with money.
   • Some people are paid indirectly by an employer.
   • How does funding best work - grants? Employement? Patreon?
6. Existential questions.
   • What does it mean to be a maintainer?
   • When do I take a holiday?
   • What am I responsible for?

History Revisited It

“What is clearly missing from [esr’s] statement, and is ultimately as important, *is how those eyeballs are organized.” - Steven Weber, The Success of Open Source

But Open source != Linux (or a few other big projects).

We punted on how we were going to support this, assuming it would just magically happened - and people stopped talking and writing about how this could all be made to work; Nadia didn’t find much of interest written past 2005.

• People like to point to Linux as a success story, but we’ve ignored thousands of project whose welfare is ignored.
• We have to confront the awkward fact that the story of open source today is not open source as twenty years ago, and stop sweeping that fact under the rug.

This Stuff Is Confusing

• We have yet to figure out how this works.
• It’s not a unique problem - it is common to many fields; journalism, art, etc.
• It isn’t a solved problem, it’s an ongoing conversation that needs to happen.

Q&A

• Given GitHub is such a major influencer in this picture, what is their responsbility, and the responsibilty of influential organisations like GithHub, to help with these problems? Sure; the tools could be better and a better relationship between maintainers and power users, establishing better lines of communication.
• How accurate is this picture? Nadia acknowledges it’s difficult to get a sense of project popularity based on what’s available from github and other sources.
• It seems that maintainers have lost authority and prestige - is that a result of the rise of Agile programming, with maintainers treated as an obstacle to the net cool thing? I share the bias. Anecdotally people are learning to code, but in a shallow way. People don’t have enough respect for what’s going on under the hood.
• Since your background is in funding, do you have any thoughts around how projects can “grow up” and get funding and govern themselves properly? This is a hard problem, it’s not well-mapped out as a path - there are many questions around, if funding is available, who should be funded, and what the obligations of paid maintainers might look like as opposed to unpaid maintainers.
• Has proprietary software done a better job of solving these problems? The difference is that people are being paid to deal with abusive users, so it’s just their job. [The fact people are paid doesn’t make abuse OK, in my view]. “There shouldn’t be users, only potential contributers.”
• Answer to a question I missed: “I think tech companies need to have a better understanding of what’s going on.”
• What are your thoughts on a Patreon model, moving the funding question to the users? Recurring crowdfunding works well for projects with clear deliverables; it requires a huge following, which is hard for people who don’t want to market themselves all the time. “Not everyone wants to give $10/month to twenty differenct projects”, and it’s not really clear what to do on the paying out side.

Some Thoughts

Much of Nadia’s talk about the state of maintainership may be true from the POV of the maintainers of many projects - but things like closed contribution groups and so on are currently big problems for users and would-be contributions; in other words, a number of the suggested remedies would make many of the problems of FOSS software worse, not better.

There’s a potentially intractable tension there - but Nadia notes we “shouldn’t try to go back in time”; rejecting user interaction, closing project communities, these things are going back to an older, more elitist model, so it doesn’t seem to me to be a solution. In fact, it will make many problems with FOSS far worse, not better; contrary to some chatter on the twitters, free software as not “swung to far to the end of UX concerns” - and if you think it has, I’ll challenge you to name me a free software project that ordinary people think is too easy to use! Similarly, can anyone claim with a straight face that documentation has run amok in free software?

Furthermore, if you think that free software is important, then “there shouldn’t be users, only potential contributers” is really antagonistic to the idea of meaningful freedom that Dan described yesterday (namely that freedom which can’t be exercised are worthless freedoms).

I have to wonder if one root cause of these problems is simply that many maintainers are people who don’t want to be maintainers; what I mean by that is that much of the job of a maintainer isn’t what we think of as development (in the sense of spending a lot of time cutting code); it’s dealing with contributors, code review, setting and communicating the direction of the project and so on and so fort. There are a lot of people who are maintainers by virtue of having been talented and persistent enough to create a thing other people like, but, much as with a developer who’s been promoted into management in a traditional company, the maintainer may well be giving up on work they love (designing and implementing code) in favour of managing a group of people who are doing exactly that.

But even if that’s true, what’s the solution? If you were maintaining a project (a necessary task) and you wanted to simply focus on development, what do you do? Hand it over to one of the other developers? They might burn out the same way? Hire someone to do the management parts of maintenance you’re burning out on? With what?

Conversely, if you’re a user, what do you do? Some parts are obvious, like Nadia’s example of a senior dev from project A being tremendously rude about smaller project B (i.e. cut that out). Others are harder. I work for an organisation that gives a lot of money to Red Hat for support, which (indrectly) allows a bunch of people to work on free software with a variety of support and compensation. But as an individual, how would I extend that support to the things I care about? What about a small company? Would any of that cover the costs of a helpdesk or other forms of bug triage? The failure of commercial Linux desktop businesses at the start of the century would suggest otherwise.

Nadia’s suggestions of becoming more user-hostile certainly wouldn’t let me help out with testing - I tested GNOME back when they first started releasing tarballs, painstakingly downloading them over dialup and compiling dozens of packages in the right order, providing feedback on how well that worked. I wouldn’t touch current GNOME with a shitty stick, such is their unmitigated contempt for their user base.

Is the problem Nadia’s describing merely the tip of a bigger problem for programmers? esr did a great job of convincing corporates they could free ride on free software (sorry, Open Source), but are the halcyon days winding down more generally? A big chunk of the free software world is, after all, supported by loss-making VC backed companies, or worse yet, loss making post-IPO companies (think GitHub, Twitter, etc). That will run out. Is part of the problem simply that a tech industry where we get to enjoy the privlege of being paid well to work on things we like doing, dressing how we like, and showing up when we want, at the beginning of the same relentless downward pressure that, say, auto workers have been experiencing since the 70s?

Rust 101

E Dunham

“Full” doesn’t really do this talk justice. Even rolling extra seating in ten minutes from the nominal start time saw it fill to room capacity with a queue outside.

Introduing Rust

This is not a step-by-step tutotial; it’s teaching you how to learn Rust and what you need to find to help yourself. Emily’s tutorial is available online.

Emily is the DevOps engineer for Mozilla Research; not a compiler academic. This is not a talk about the delightfully subtle differences between type systems.

It’s a systems programming language - but while compared to Go, it’s not really accurate; Go is a language for sysadmins, while Rust is more for writing systems or systems components.

It’s aimed at high performance with safety, and has a unique community that is heavily focused on providing a positive environment, which is apparently controversial for some people.

The motto is “hack without fear”. Memory safety is a key goal of Rust; compare:

• C: “Just follow these rules perfectly, you’re smart.”
• Java, JS, Go, etc: “Wait a minute, I’ll take care of it.”
• Rust: “I’ll prove correctness at compile time.”

“Ferrous”, at the rustacian web site, is the unoffical mascot.

Rust is about 2 years old, and hit 1.0 in 2014. 2.0 is not on the roadmap, because breaking changes are not on the roadmap.

Where is Rust a good tool:

• Speed & safety are an essential technology.
• An LLVM-supported architecture.
• Because you love new things - Emily has seen companies let people use it as a reward.

Where Rust is a bad tool:

• Tight timeframes.
• Need code reuse.
• Can’t handle the CoC.

Run Rust

• There are three different channels of Rust:
  1. Nightly, which is where the cool new ideas rock up, and features may live there a long time - or never make it to production.
  2. Beta: the release candidates.
  3. Stable: always backwards-compatible.

Code written for Stable should run anywhere, although Nightly sometimes breaks with stable code. In general, you should start with Stable, and only move to Nightly if you absolutely need it.

(Crater, a tool which compiles the world and records and checks for differences. The core team will even go so far as to provide pull requests to libraries that help fix potential problems that Crater uncovers.)

You have a few options:

• The playpen, for example will let you play with syntax.
• rustup.rs is a script which lets you manage Rust installations, including multiple versions of Rust.
• System package manager.
• Compile from source if you’re paranoid.

Playpens

• Choose a variety of outputs, including the LLVM IR or ISM.
• You can Gist your progress to make it easier for people to help you.

Rustup

• The page gives you the instructions.
• It’s a local installation, which is generally a Good Thing, but rather a per-user install.
• You can use it to manage the existing installation or add/delete them.
• The scripts and installers are GPG signed, and the key is help only by the Core Team.
• Rustup does check signatures.

Deployment

• Check the README (e.g. for your -dev libraries).
• git clone.
• cd projectname.
• cargo run
  • Cargo run will grab dependencies and build automagically.

Write Rust

Rust has a lot of new stuff, as well as old ideas. It’s a big topic, you will not get it in a day. You will still be making the odd idea every few months.

There is IDE support - there’s Jonathan Turner’s blog, and a canonical site that shows the status of support in different IDEs. People ask if there’s a REPL, which “seems like an odd question - does C have a REPL?” The closest idea would be playpen, or the playbot on IRC.

Errors

Rust wants you to succeed. Emily’s mental model of Rust is that the compiler is a wise old guru who will tell you, “that might work now, but it will cause you problems later.”

• Rules catch things that look unsafe. Most compilers will compile code even if it may not work. Rust will refuse to compile things that it can’t prove are correct.
• There is an unsafe directive to work around the rules. You probably don’t need it when you think you do; you should probably ask for guidance from more experienced users about whether there’s another way.
  • When you see an unsafe block it deserves extra scrutiny; the sad reality is that we aren’t smarter than the compiler as often as we think we are.
• Errors are generally helpful and offer suggested fixes.

If you think they’re getting an error and you think it’s wrong, you should probably search on the web, or ask on #rust-beginners. If you do find an error, please please please raise a bug.

• You should use rustfmt if you want to outsource having strong opinions about the style of the code.

• rust-clippy will offer helpful suggestions about how to improve your code; it will make syntax suggestions, for example.

• Q: Can you run it in an isolated environment? You can have cargo run in an offline mode, for example.

• Q: How far does “you probably don’t need unsafe” extend? If you’re interfacing with something which you can’t prove the safety of, such as a piece of hardware or some C code, you will need unsafe. You should invoke it, and aim to get out of it with as little as code as possible.

Syntax

Scope syntax:

• Matched {} are a scope.
• Scopes can be nested. Something which is available in the parent scope will be available in the child scope, but the child scope may not be available to the parent.
• This is critical to understand for lifetimes.

Function syntax:

• fn myfunction {...}: a function and a scope.
• In the real world there will be a signature: fn myfunction (arg: type, arg:type) -> resulttype {...}
• The signature is used heavily by the compiler for checking for correct interaction with the function.
• Function must have a name and scope, but types are desireable.

Macro Syntax:

• Shorthand for functions with a variable number of arguments.
• e.g. macroname!(foo, bar, baz).

Puncuation matters:

• Expressions end with a semicolon, with one special exception: if, at the end of a function, you have a bare function foo, it will woulk the same as return foo;.
• Whitespaces only matter to seperate functions. You can make unreadable Rust with whitespace.
• There is an “underhand Rust competition”.

Control Flow Syntax is generally pretty familiar:

• Conditionals work as you’d expect:
  • if x {...}
  • loop {...}
  • while x {...}
  • match {...} statements; a block that will take actions based on the value assigned to a var.

Q: Is there true, false, 0, 1? There is a boolean type. Use a boolean type!

Q: Why are there different dots in ranges? Inclusive versus {1..10} means “2-9”, while {1...10} means “1-10”.s

Types and Traits

Why traits and types?

• Describe characteristics and outputs, which is where you most care about them in your program flow.
• Avoid allocating uneccessary memory.
• Allows the compiler to better understand whether the code is safe or not.
• Reminds humans how the code works.

Types:

• There are a variety of built-in types in rust, documented as the primitive types.
• You can make custom types via enums and …

Traits:

• Describe the type’s abilities - can it be added? Subtracted? Multiplied.
• Described with the impl.

The details are quite complex, and well-documented in the book.

Safety

The core of safety is the idea of ownership:

• let myint = 42;
• myint is a variable binding.
• myint owns the value 42.
• Every value has only one owner.
• Mutability: values are only mutable if it is explicitly delared to be so: let mut myint = 42;.

But if you want to allow temporary access to an area of memory, you can use borrowing:

• Grant temporary access to a variable.
• 1 mutabble borrow XOR unlimited immutable borrows.
• This helps avoid many of the worst problems of parallelism.
• Syntax is &myvar.
• This is [documented in the book](https://doc.rust-lang.org/book/references and borrowing.html)

The final thing to consider is lifetimes:

• Remember {scopes}?
• Variables disappear when their scope ends!
• No borrow outlives its value’s owner; this prevents use after free type bugs.

Q: How does that work with constants? How do I have multiple things with the value of 42? Long story short, if Rust knows that you aren’t going to change things it will store those things in seperate areas of memory.

Using Libraries

The package manager is called Cargo, and the libraries are called Crates. These live at crates.io; once you’ve published something, it cannot be removed, but it can be marked as deprecated. Only a handful of people could remove it.

If there is material with CoC violations, or copyright violations, or somesuch, this could cause a removal, but only after a proper review process and with adequate review.

There is a Guide to Crates and you should read it.

When creating a new binary or library, we recommend you use cargo:

• cargo new --bin creates a new binary project.
  • You run main.rs.
  • cargo.lock stores the state of the last known good build.
• cargo new --lib creates a new library.
  • Creates a lib.rs

cargo new also creates:

• Cargo.toml - describes the project dependencies and metadata.
• src/main.rs or src/lib.rs depending on the binary or library.
• .git if absent.

Q: How easy is it to run you’re own Cargo infrastructure? Not easy at all at the moment, but there’s work in progress to deal with the uses cases like working disconnected, caching, firewalls and so on.

Depending on a crate; this is not always easy, since you search crates.io for looking for which library to use. There’s work going on to make it easier to determine which crate is the best choice where they are many options.

• Add it to the dependencies session of your cargo.toml:
  • You can specify by name, in the form name = "0.1", to allow it to pull from crates.io automagically.
  • Or from github with name = { git = "https://github.com/foo/bar" }
  • Then use extern libname in your code to pull it in.

Q: How do you track security vulnerabilities in your deps? At the moment there’s no clearing house for notifications of changes. We need better tooling for this case.

Improve Rust

If you think Rust is cool and awesome, how do you level up? How do you find stuff to work on and with?

Always:

• Respect others’ licenses.
• License your own code.
• Document and share what you learn!

Level Up

Note that Rust has been fast-moving, so check the date on blog posts and articles to make sure the advice is relevant to current Rust.

Read the book or the Rustonomnicon or wait for the O’Reilly book. There’s also newsletters, blogs, and podcasts.

Practice: rustlings or Rust by Example.

Use Are We Web Yet? to find socket libraries.

Q: Rust for embedded - is there a canonical implementation? While Rust shines for embedded platforms, it’s not consistent, in part because there are so many processors and processor variations. It’s closely tied to LLVM support.

Q: Where doesn’t Rust run? There is a support list, but there’s some odd corner case.

Find a Project

You can search for and join projects, either via crates.io, or search GitHub for is:issue label:easy.

You could port something, possibly with the assistence of Corrode.

Start something from scratch.

Get involved

• IRC: #rust and #rust-beginners.
• The Discourse forum.

Both of those are moderated closely. There are less-moderated side-channels such as /r/rust, blogs, and so on.

I am your user. Why do you hate me?

Donna Benjamin

Free and open source software suffers from poor usability. “Did I say that out loud and LCA?” “But it’s true!” replies the audience.

“Leslie Hawthorn and I have been ranting about this in private for many years, and we finally decided to take it public.” The talk came from two things: struggling with free software, and hearing our developer friends speak about users with contempt.

But what is a user? Who are our users? Well, look at Wikipedia: users are being defined by what they can’t do, what we imagine them to be incapable of. And who else describes their customers as users? Well, it’s basically computing… and drug dealers.

How do I hate thee? Let me count the ways:

• Just for brainiac me. “Scratch my itch.” “It works on my desktop.” “Patches welcome.”
• Stupid user memes. “Users are searching with the wrong keywords!”
• Oh, no, no, no. I know better. [Seriously I’ve had people I work with suggest mobile banking is a fad we don’t need to support.]
• You’re just not technical.
• Faceless icons.
• Prickly attitudes: people taking pride in the idea it’s hard to deal with us.
• But Donna acknowledges that there are people who can be whiney, entitled, and demanding. And there’s more of them than there of us.
  • But sometimes this selfishness is born of frustration, if hitting the rough edges of software.
• Poor documentation. We make it hard for users to help themselves.

Let’s stop for a moment and chat, about chat. Now, sure IRC is great; it’s not a particularly easy-to-use tool. Slack have come along and given us something that easy and delightful to work with; projects have migrated to it, taking a great deal of flack for it, since it’s closed. But it’s also easy for the users. What can we learn from Slack?

Let’s talk about Steep Learning Curves. Donna notes that Drupal used to take a perverse pride in their learning curve - isn’t that wrong? Shouldn’t we want to help people kick ass sooner (see the Kick Ass Curve by Kathy Sierra).

People don’t want to be badass at using your tool. They want to be badass at what using your tool allows them to do. [YES! Tools a means to an end, not an end in and of themselves!]

(Donna thinks you should read Kathy’s book.)

So how did we get here?

Excellence and its Discontents

• Perfect is the enemy of the good: could we afford a little rough around the edges, if it helps make things a little better? If someone’s documentation contribution isn’t perfect, but improve things, shouldn’t we take it and encourage them?
• Consider the experience of a GSOC intern, whose first experience as a GSOC intern was to be told to go away because she “wasn’t a serious developer.” That was the experience of Angela Byron, who ultimately persisted and became the Drupal 7 release manager - but how many people have we lost who could have been awesome.
• Diversity: understand who your users are; see them as people, like your friends and colleagues, not faceless icons.
  • Donna asked us to imagine our users as the early adopters.
  • To treat them as reviewers, people who provide triage.

“I feel like Nadia’s talk was one side of the coin; we need to think about our maintainers with more respect and care, but we also need to think about our users with more care and respect, too.”

Q&A

• Do you think user stories in interfaces have helped? Are they real or are they stories developers tell themselves? I think the trend to move to user-centric design is great, and one of the reasons proprietary software is kicking our arses with this. But they can be used badly, either as stereotypes or used to exclude people who don’t fit the profiles.
• There’s often a tension in the amount of time you have to make things better; how do you convince people to focus on the user compared to features? I wish I did have clever tricks. I think we can try to make it a baseline for product quality. Could we make things simple?
• Should something fail code review if the usability sucks? Yes. But how do we test for usability? And get people to care in the first place?
• Are there any good examples of projects getting people from user to participants? Drupal have a great mentoring program for getting people to the point of “first patch”, but what about the second or tenth? Often people will make one contribution - and then stop.
• How can open source projects attract people who have specialised skills in UX, user experience? There’s not a good answer Donna knows about. Drupal struggles to attract a broader range of skillets. There may be fundamental cultural issues between the disciplines.
• Do we perhaps not have enough respect for other people’s expertise? Yes - we don’t appreciate that people have a range of skills and expertise.

Open Source Accelerating Innovation

Allison Randal

Free software started with a printer, per the famous Richard Stallman story; when qwe make edits to our software we should share the software, so we can build on one another’s work.

When we think about the story, we think of it as a Leia story, fighting an evil empire, but it’s an Amidala story: Stallman existed at the end of a glorious republic of free software, but one he could see disintegrating befoer his eyes.

Free software, therefore, was an equal and opposite reaction to the arrival of copyrighted software. At that time, software was not valued, it was considered merely an enabler for the hardware the company sold. Companies would often let customers see the source; there slow, steady innovation.

The middle age of software arrivedwith the 80s, with software becoming prevalent; the Mac arrived, so did DOS and Windows and so on; but free software did as well.

Innovation: Allison defines this as new things, unique ideas or implementations. Commoditization is when it has become so common that no-one would pay for it any more.

In the 80s it was generally held that FOSS would always be a follower, while proprietary software would continue to show the way.

But in reality, Allison argues, this was a myth. In the 2000s we start to see corporate adoption of the large body of FOSS software. The dot-com bubble arrived in this time; with its collapse, companies began to look for alternatives.

Web 2.0 was fundamentally powered by FOSS. That’s partly economic necessity: if your competitors all use free software you’re going to find it hard to justify spending your money on proprietary software.

As far as innovation goes, it turns out that a model of shutting away software in little black boxes may not work so well. Letting people collaborate, even across companies, can accelerate innovation.

Software has become more and more important - which means software freedom has become more important. We don’t want to live in a room where we cn’t change anything. It’s become a key part of a free society, in fact, because so much of what is required to participate in society is software (but Allison notes that while it maybe necessary for a free society, it isn’t sufficient: if you don’t have free speech or freedom of association, but do have free software, you don’t get a free society.)

Now, though, using free software isn’t a competitive edge; it’s become table stakes. Everyone is using it, simply haveing free software is just an entry point to stay in business.

Participation has become the competitive edge: if you participate, you can help steer teh software you rely on in the direction you want. The more you participate, the more you can build better and more useful software; the better the software is, the higher the bar is raised for you and your competitors.

The more you participate, the better everything gets, but e more you have to participate.

Companies have to deliver value customers care about. And you can’t just deliver what the last supplier did.
What’s the value of a software license for a customer? Not much.

Something interesting here is companies working collectively; we’re used to governments accomplshing something sollectively, and free software communities full of people working collectively’ but now we have companies collectively.

One problem here, though, is that if we become over-dependent on companies to support development, we may have a problem with taking advantages of opportunities for improving the public good; companies don’t do a good job of that. So there’s a gap. There’s a contribution companies need to be encourage to make, but also that free software communities need to make.

Because there are gaps here.

So what does the next phase look like?

It matters, because software is for the future of humanity.

We should care about diversity: geography, skills, gender, race, ideas. We’re stuck because we don’t have enough perspectives on what the next level looks like.

Myopic monocultures have a weakness: they miss opportunities.

Q&A

• How do we get over the requirement for continual growth interfering in sustainability? We probably need to demonstrate alternatives before we can create change.
• How do we e.g. create a decetralised Twitter or similar things and make money to feed ourselves? Well, you need to see what the customers are paying for when you aren’t ust charging for software: maybe you run a federated server with better support than your sompetitors (or better blocklists!)
• Are you suggesting we should move back to a more ethical focus in free software? Could we fall back the mountain we scaled as “open source”? Allison doesn’t see that “open source” abandons freedom; rather that freedom is the main reason we’ve succeeded.
• A lot of companies are service companies. How does this change things? Licenses don’t cope with this - but with luck, companies will care less about their software, not more. There is a risk that companies will backslide to wanting “secret” software, but Allison thinks it will be an overall benefit.