Microdata addresses this.

Well, they're not supposed to be ephemeral. They're supposed to be as durable as the title of whatever book you're talking about.

...who thought this was a good idea??

I realized after fully digesting this document that it effectively outlines a mechanism of anti-discovery.

Grand problème de la centralisation des programmes et des instances productrices de programmes: uniformisation des usages, comportements, et des programmes récursivement; dépendance à des structures tierces (aux intérêts commerciaux souvent conflictuels avec les besoins des usagers).

```js import { ReadableStream } from 'node:stream/web'; import { Worker } from 'node:worker_threads';

const readable = new ReadableStream(getSomeSource());

const worker = new Worker('/path/to/worker.js', { workerData: readable, transferList: [readable], }); ```

```js const { workerData: stream } = require('worker_threads');

const reader = stream.getReader(); reader.read().then(console.log); ```

The common perception of the Web as a sui generis medium is also harmful. Conceptually, the most applicable relevant standard for Web content are just the classic standards of written works, generally. But because it's embodied in a computer people end up applying the standards of have in mind for e.g. apps.

You check out a book from the library. You read it and have a conversation about it. Your conversation partner later asks you to tell them the name of the book, so you do. Then they go to the library and try to check it out, but the book they find under that name has completely different content from what you read.

https://tantek.com/2023/051/t1/five-years-ago-w3c-social-web

texto pdf

My Fifth Year as a Bootstrapped Founder February 10, 2023 12-minute read annual review • tinypilot Five years ago, I quit my job as a developer at Google to create my own bootstrapped software company.

For the first few years, all of my businesses flopped. None of them earned more than a few hundred dollars per month in revenue, and they all had negative profits.

Halfway through my third year, I created a device called TinyPilot. It allows users to control their computers remotely without installing any software. The product quickly caught on, and it’s been my main focus ever since.

In 2022, TinyPilot generated $812k in revenue, a 76% increase from 2021.

In this post, I’ll share what I’ve learned about being a bootstrapped founder from my fifth year at it.

Previous updates My First Year as a Solo Developer My Second Year as a Solo Developer My Third Year as a Solo Developer My Fourth Year as a Bootstrapped Founder Highlights from the year TinyPilot grew annual revenue to $812k Income/Expense 2021 2022 Change Sales $459,529 $807,459 +$347,930 (+76%) Credit card rewards $2,241 $4,327 +$2,086 (+93%) Raw materials -$224,046 -$333,656 +$109,610 (+49%) Payroll -$142,744 -$206,187 +$63,443 (+44%) Electrical engineering consulting -$28,662 -$124,643 +$95,981 (+335%) Advertising -$3,873 -$51,764 +$47,891 (+1,237%) Web design / branding -$15,931 -$30,215 +$14,284 (+90%) Postage -$24,227 -$30,779 +$6,552 (+27%) Cloud services -$5,553 -$7,865 +$2,312 (+42%) Office space -$4,400 -$6,600 +$2,200 (+50%) Equipment -$2,083 -$5,915 +$3,832 (+184%) Everything else -$4,902 -$8,183 +$3,281 (+67%) Net profit $5,349 $5,979 +$630 (+12%) While it sounds impressive to grow revenue by $350k, it’s a little less exciting that I’m only walking away with $6k in profit. I don’t pay myself a salary, so $6k is the full amount I earned from the business in 2022. Still, I’m excited about these numbers and what they mean for 2023.

One of the major cost increases was electrical engineering. Throughout 2021, TinyPilot’s electrical engineering vendor was struggling to keep up with TinyPilot’s growth. In late 2021, I switched to a new vendor that fits our needs better, but they cost three times as much.

The ongoing chip shortage forced us into frequent redesigns, which bloated costs in engineering hours and raw materials. We were often in a race to redesign a circuit board before we ran out of our existing version, so we repeatedly paid a premium to expedite the process.

We finally escaped the redesign treadmill in September. I’m hopeful that our fourth quarter results will reflect the coming year. Our profit was $28.6k for the quarter, so if we average $9.5k per month in 2023, I’ll be happy.

TinyPilot got a new website When I launched TinyPilot in 2020, I told myself the website and logo were just placeholders. Then, things took off so quickly that I never had time to replace them.

In 2022, I finally hired a design agency to create a new logo and redesign the website.

Screenshot of old landing page Screenshot of new landing page Before and after the TinyPilot website redesign

I wrote previously about how frustrating and expensive it was working with the design agency, but I’m pleased with the result. My old website looked like a hobby project, and the new design looks like a real company. I suspect that at least a portion of my increased sales resulted from the new design.

The TinyPilot team grew from six people to seven At the end of 2021, the TinyPilot team was:

Me, the sole founder Three part-time software developers Two part-time local staff who handle assembling devices and fulfilling orders One of whom also handled customer service By the end of 2022, we had added two support engineers and adjusted responsibilities, so the team is now:

Me, the sole founder Two part-time software developers Two part-time local staff who handle assembling devices and fulfilling orders Both now work on customer service Two part-time support engineers Adding the support engineers felt like finding the missing piece of the puzzle. Before they joined, I was the only person handling technical support, and it occupied about 20% of my time. Now, I spend less than 5% of my time on support requests, and customers receive faster support.

The support engineers also do things I didn’t have time for, like investigating complex bugs, writing documentation, and improving our diagnostic tools.

Growing the team stretched my skills as a manager. In 2021, TinyPilot’s workflows were fairly simple. Almost everyone did their work as a single-person unit. The results either went directly to me or to a customer. When employees needed to coordinate with each other, it was always among teammates of the same role.

Integrating support engineers meant figuring out how different teams work together. How do support requests work when they require cooperation between fulfillment staff and support engineers? What’s the feedback loop between the support engineers and the dev team?

PicoShare became my fastest-growing project One of my pet peeves in the last few years is how difficult it is to share a single file with cloud storage providers like Google Drive or Dropbox. They won’t give you a direct link to your file — just a link to their web interface, where they pressure your recipient to sign up for an account. If you upload a video to Google Drive, they make you wait 15+ minutes while they re-encode it, even if it was already optimized to play in the browser.

As an alternative to the existing cloud storage options, I made a minimalist file-sharing app called PicoShare. You just upload a file, and it gives you a direct link that you can share. Easy! No re-encoding, no prompts to sign up for anything.

Animated demo of uploading a video file to PicoShare and streaming it in another browser window Demo of PicoShare There are a few open-source tools that offer similar functionality, but PicoShare is unique in not requiring a database server. That means you can run it in a single Docker container, whereas other solutions require more complicated orchestration.

PicoShare became the fastest-growing open-source project I ever published. It received 600 Github stars within two weeks of its release. As of this writing, PicoShare has over 100k installs.

Lessons learned Don’t become anyone’s smallest client I made many mistakes throughout the whole TinyPilot website redesign fiasco, but the core problem was that the design agency was a fundamental mismatch for TinyPilot.

The agency’s other clients had 5-20x TinyPilot’s budget. At first, I thought that was such a gift — this fancy agency with expensive clients was betting on a little company like mine.

The reality was that TinyPilot was the agency’s lowest priority. They managed the project poorly, which drove up costs, bloated scope, and stretched out timelines.

Now, when I work with new vendors, I ask them how my company compares to their other clients. If I’m an outlier in any important dimension like size, revenue, or industry, I look elsewhere.

Run at 50% capacity Wouldn’t it be wonderful if your business’ capacity perfectly matched your customers’ needs? Your employees would fulfill every order and satisfy every support request while working exactly 40 hours per week. They’d never feel overworked nor underworked, and there’d be no idle time.

In practice, that would be a terrible system. Running at 100% utilization would mean you have no margin for error. Ordinary occurences like a bump in sales or an employee taking a vacation would immediately overwhelm you.

I aim for everyone at TinyPilot to run at around 50% capacity. That is, a balance of 50% reactive work and 50% proactive work. For some roles, the balance isn’t quite 50/50, but it’s a good rule of thumb.

The technical support team is the clearest example of a 50/50 split: they spend half of their time responding to support requests and the other half finding ways to save users from needing support. The proactive tasks include fixing bugs in the product, writing documentation, and improving our diagnostic tools.

Every TinyPilot team comprises two people. When one person is unavailable, the other can suspend their proactive work and handle time-sensitive tasks without feeling overwhelmed. If we get a rush of orders because a popular YouTube channel mentions us, we have spare capacity to absorb it.

Team Reactive tasks Proactive tasks Founder Team management Vendor management Reviewing work Filling gaps in responsibilities Marketing Sales Re-evaluating strategy Hiring and training Support engineers Answering technical support questions Writing documentation Writing tutorials Investigating difficult bugs Software developers Fixing urgent bugs Releasing new features Improving dev experience Creating automated tests Fixing non-urgent bugs Fulfillment staff Assembling devices Fulfilling orders Customer service Creating support playbooks Assisting in marketing Ansible and git are not software distribution tools When I started working on TinyPilot, I didn’t know how to distribute Linux software.

To publish the prototype of TinyPilot, I used the tools I knew: bash scripts, Ansible, and git. The bash script bootstrapped an Ansible environment and executed an Ansible playbook. Ansible installed dependencies, made necessary changes to the operating system, and cloned the TinyPilot git repository.

The installation process was okay, not great. It was slow but reliable and didn’t require the user to configure anything manually.

Two years later, TinyPilot’s update process was a mess. It still relied on the same shaky foundations from the prototype, except now there was a complex web of interdependencies. Ansible roles depended on Git repositories, which depended on other Ansible roles, which depended on parameters in a bunch of YAML files. Minor changes swallowed weeks of development time.

All this because I never bothered to learn standard Linux packaging tools.

This year, the TinyPilot team learned to use Debian packages. It was far less painful than I’d feared. I thought we’d have to deploy all sorts of package servers and key servers, but it turns out we didn’t need any of that. The process was relatively easy once we found the right guides.

Debian packages have accelerated our development. The tooling catches expensive mistakes earlier, and we can deploy pre-release versions to our test devices easily, whereas our previous installation system made that process prohibitively complex.

Grading last year’s goals Last year, I set three high-level goals that I wanted to achieve during the year. Here’s how I did against those goals:

Grow TinyPilot to $1M in annual revenue Result: Grew TinyPilot’s revenue by 76% to $812k Grade: B I always knew that $1M was an aggressive goal. We fell short, but I’m still impressed at how close we came.

Manage TinyPilot on 20 hours per week Result: I spent more time managing TinyPilot in 2022 than in 2021. Grade: D I was hoping to automate and delegate away enough of my job to reduce my management time to 20 hours per week, but it didn’t happen. Between growing sales, spinning up the support engineering team, and putting out fires due to the chip shortage, my management time increased.

Ship TinyPilot Voyager 3 Result: We never even completed the design phase Grade: F TinyPilot has always used the Raspberry Pi 4B as the core hardware. There’s a wonderful ecosystem around the Pi 4B, but the hardware is relatively expensive and difficult to integrate with custom chips.

My plan for 2022 was to create a custom circuit board for the slimmer, less expensive Raspberry Pi Compute Module 4. That could cut our manufacturing costs by up to 60% and simplify our hardware design.

Instead, all of our hardware engineering time went to chasing down manufacturing issues and supply shortages, so we made no progress on a new product.

Goals for year six Manage TinyPilot on 20 hours per week I failed miserably at reducing my hours last year, but it’s now my top priority. I’m hopeful about my chances this year. A lot of my 2022 work laid the groundwork to remove me from the critical path in 2023.

Earn $100k in profit For TinyPilot’s first two and a half years, I focused on growth. I pay the same in hardware and software engineering costs whether I’m selling 20 devices per month or 2,000, so I needed to reach a certain scale to make the business viable.

For most of 2023, TinyPilot’s production will be constrained by supply. It was disappointing to find out I’d have no chance at growing sales, but the silver lining is that I can slow down and focus on profit rather than growth.

TinyPilot has always roughly broken even, but I think I can reach $100k in profit this year if I avoid further hardware redesigns. Without the hardware redesigns in 2022, I would have saved around $100k on engineering and $20k on materials. If I keep sales steady and run leaner on the hardware side, 2023 should be a profitable year.

Close the TinyPilot office I’ve leased an office for TinyPilot since early 2021. We use it for assembling devices, fulfilling orders, and storing inventory.

Having our own local office has helped us adapt quickly to changes in our hardware and processes, but it’s a lot of extra overhead. This year, I hope to transition assembly to China, where all of our parts originate. I’m also in the process of moving our fulfillment to a third-party logistics warehouse.

Eliminating the TinyPilot office would spare us the work of maintaining a physical space, managing inventory, and tracking in-person shifts. Outsourcing manufacturing and fulfillment will also give the team more flexibility in time and location.

Do I still love it? Every year, when I write these blog posts, I ask myself whether I still love what I’m doing.

2022 was a hard year — certainly my hardest since going off on my own. I wasn’t miserable, but I can’t say I loved it.

The global chip shortage meant we could never manufacture a batch of products the same way twice. There was always some missing component or manufacturing issue, so we were constantly racing to fix issues and adapt our processes before we ran out of stock. We got through it, and there were only a handful of days that I had to mark any product as sold out, but it was stressful.

That said, there were certainly many things to appreciate about the year. I had a relatively small amount of time for writing and software development, but I’m proud of what I produced. Expanding the TinyPilot organization and figuring out how teams work together grew my skills as a manager. It’s been gratifying to see the team grow in their roles and expand their skills as the company evolves.

I still prefer working for myself to having an employer. I still feel grateful for the freedom to have my own company. And I still want to do it forever.

https://coolors.co/

developers first API first

https://optimize.google.com/

alternative: https://www.inspectlet.com/

link to: https://hypothes.is/a/ykPEMJXhEe2yst-vhvqBzg

https://www.inspectlet.com/

I've used this briefly before, but it's also something Scott Scheper swears by.

alternative: https://optimize.google.com/

Wikipedia really is an excellent example of why and how Web 2.0 was so impactful to online society. Unlike Web 1.0, where content consumers were mostly limited to read-only, Web 2.0 allowed content consumers to produce their own consumable content for the first time.

https://500ish.com/mastodon-brought-a-protocol-to-a-product-fight-ba9fda767c6a

https://arstechnica.com/gadgets/2022/12/mastodon-highlights-pros-and-cons-of-moving-beyond-big-tech-gatekeepers/

Example of how ActivityPub standards don't work in practice, in part because Mastodon is an 800 pound gorilla which actively flauts or adds their own "standards".

https://arc.net/

First I've heard of this.

https://atproto.com/guides/faq

https://www.justingarrison.com/blog/2022-12-06-mastodon-files-instance/

https://snarfed.org/2022-12-03_48181

https://social.yesterweb.org/explore

A mastodon instance for the OG web and design folkx.

Is this behavior/limitation part of the web standard or a Rails-specific thing?

This brings interesting questions back up like what happens to your online "presence" after you die (for lack of a better turn of phrase)?

Aaron Swartz famously left instructions predating (by years IIRC) the decision that ended his life for the way that unpublished and in-progress works should be licensed and who should become stewards/executors for the personal infrastructure he managed.

The chrisseaton.com landing page has three social networking CTAs ("Email me", etc.) Eventually, the chrisseaton.com domain will lapse, I imagine, and the registrar or someone else will snap it up to squat it, as is their wont. And while in theory chrisseaton.github.io will retain all the same potential it had last week for much longer, no one will be able to effect any changes in the absence of an overseer empowered to act.

https://iiif.io/api/search/2.0/change-log/

https://vivaldi.com/blog/blue-beanie-day/

https://blog.erinshepherd.net/2022/11/a-better-moderation-system-is-possible-for-the-social-web/

<small><cite class='h-cite via'>ᔥ <span class='p-author h-card'>Erin Alexis Owen Shepherd</span> in A better moderation system is possible for the social web (<time class='dt-published'>12/03/2022 11:10:32</time>)</cite></small>

https://www.manton.org/2022/12/02/moving-from-mastodon.html

Details for moving from one instance to another.

This seems like a great iniciative! Did it succeed?

Also, there is Moodle plug-in for web monetization and paypal.

Possibly, besides web monetization, there can be donation basket like ko-fi beside curation, as well as cleatly linking back to the original that can have a donation basket as well. The options are complementary.

Web Monetization

Thought you might like Web Monetization.

https://hekate2.github.io/buttonmaker/ http://webbuttonmaker.great-site.net/?i=1

https://neonaut.neocities.org/cyber/88x31.html

I have thought long about the same issue and beyond. The triple (wiki, Hypothesis, donations) could be a working way to search for OER, form a social group processing them, and optionally support the creators.

I imagine that as follows: a person wants to learn about X. They can head to the wiki site about X and look into its Hypothesis annotations, where relevant OER with their preferred donation method can be linked. Also, study groups interested in the respective resource or topic can list virtual or live meetups there. The date of the meetups could be listed in a format that Hypothesis could search and display on a calendar.

Wiki is integral as it categorizes knowledge, is comprehensive, and strives to address biases. Hypothesis stitches websites together for the benefit of the site owners and the collective wisdom that emerges from the discussions. Donations support the creators so they can dedicate their time to creating high-quality resources.

Main inspirations:

Deschooling Society - Learning Webs

Building the Global Knowledge Graph

Schoolhouse calendar

So many good features in your project!

Employing local staff that know the setting and can be role models for the kids.

Supporting mentoring by volunteers to scale.

Working with bodies to get a visceral experience that change is possible.

Mentoring in groups to build a community.

Spotlighting diversity and building bridges beyond the local community.

Some related resources: Ballet dancer from Kibera

Fighting poverty and gang violence in Rio's favelas with ballet

I love this! It is similar to Prezi or VoiceThread.

Do you also support collaborative editing (public or with invited collaborators)? If yes, a high-resolution world map could be used for collaborative pinning of local events, meetups, news, videos, and so on, such as radio.garden or YouTube Geofind.

Have you thought about crowdsourcing localization via weblate? It includes DeepL and can also be a learning ground, such as Duolingo Immersion.

Have you thought about opening the project setting and the remixing to educators or even kids? That could create additional momentum.

A few related resources you might want to check out for inspiration: Science Buddies, Seesaw, Exploratorium