The Changelog: Software Development, Open Source - TiddlyWiki (Interview)

Episode Date: February 27, 2016

Jeremy Ruston joined the show to talk about TiddlyWiki — a unique non-linear notebook for capturing, organizing, and sharing complex information. It's written in JavaScript and sports a custom fake DOM. We talked to Jeremy about his nearly 40 year career in programming, Hackability as a human right, Tiddlers — the atomic unit of data in TiddlyWiki and so much more.

I'm Jeremy Rustin, and you're listening to The Change Log. Welcome back, everyone. This is The Change Log, and I'm your host, Adams Dekowiak. This is episode 196, and on today's show, Jared and I talk to Jeremy Rustin, the creator of TiddlyWiki, a unique non-linear notebook for capturing, organizing, and sharing complex information. It's written in JavaScript and sports a custom fake DOM. We talked to Jeremy about his nearly 40-year career in programming, hackability as a human right, Tiddlers, the atomic unit of data in TiddlyWiki, and so much more.

We have three sponsors for the show, towel lenode and bmc true sight pulse our first sponsor of the show is our friends at top towel an exclusive network of top freelance soft developers and designers top companies rely upon top top freelancers every single day for their most mission critical projects and i'd love for you to get in touch with me if you'd like a personal introduction to our friends at TopTile. If you're an engineer or a designer, you'll be a part of a worldwide community

that loves to work on awesome projects with the flexibility to travel and see the world and blog on the TopTile blog or apply for open-source grants or even have access to scholarship options. Head to TopTile blog or apply for open source grants or even have access to scholarship options. Head to TopTile.com to learn more or email me, Adam, at changelog.com if you prefer a more personal introduction to our friends at TopTile. And now, on to the show. All right, we're back. We got an awesome show today.

This one, Jared, like many shows of ours, begins as an issue. Issue 248 on our ping repo. Go to github.com slash the changelog slash ping. You'll see a bunch of issues there. Contribute back. Recommend the show if you want to. But, Jared, it was FND who commented back in july this is kind of crazy it goes back to when we were at gopher gun remember that time i do and this is a a great suggestion definitely a project that had

never hit either of our radars and may never have if it wasn't for fnd i wish fnd would leave his name somewhere on the internet so we could actually thank him by name. We don't know if it's a he either because it's a fighter pilot and it is an avatar, I guess we assume. That's true. We're not even sure. It's a genderless, faceless person. It is. So thank you, genderless, faceless person, FND. And I do like to read off specifically what was said because it was intriguing. And he or she said that TiddlyWiki,

which is what we're here to talk about, was one of the earliest single-page applications and is in many ways both unusual and thought-provoking. Its latest incarnation was rewritten from scratch, taking advantage of the JavaScript community's modern tooling. So that was FND's take on why TiddlyWiki is interesting. And also, he, she said Jeremy Rustin will be a great

guest. So, Jeremy, you're here. We really appreciate you joining us. Thank you, guys. Thank you very much, FND, as well. Yeah, so, Jeremy, we like to get to know our guests a little bit at the top. And so I did a little bit of looking up and on Twitter I found an interesting bio which says that you've been learning the code since 1978.

That's a long time. Yes. I wonder the average age of your guests. I was thinking I'm probably hugely older. But hopefully I can pull out some interesting perspectives that come from that. I mean, I got a first computer in 1978, as it says there. It was long before the web and long before object-oriented programming, long before databases, if you can imagine that.

So what did you cut your teeth on then? Was it just C or what? No, so my first computer was a crazy thing called the MK14. And it's just a circuit board that you soldered yourself. It had a processor called the 8060, also called the SCAMP, S-C stroke M-P. And it was, in fact, it was a bit of a precursor to the RISC chips in that one of the things that was regarded as freakish about it, it was intended for embedded applications, was that it didn't have a stack pointer. And instead, there were some conventions for using one of the general purpose registers as a stack pointer. And obviously, because it was the first processor i touched i had no idea that that was

such an unusual thing but then however many years it was later 15 10 15 years later when i was working using the arm chip of course i came across the same thing where register 15 is the program counter um but anyway it was a tiny 8-bit processor with 128 bytes of RAM. I'm pretty sure the first program I wrote for it was a brute force multiplication program that added numbers together. And you programmed it with a hex keypad and a seven-segment display. So there was no basic interpreter or anything like that goes without saying um but yeah nowadays obviously anybody who wants that experience simply picks up an arduino or a raspberry pi or any of these fun little embedded processor cards but there is something

incredibly invigorating about working so close to the hardware being able to relate what you're doing as a programmer with what you can see in the circuit diagrams and with what you can connect to the exposed ports it's really fun and you know programmers with my background are apt to feel feel almost a little sorry for people who've only had the chance to work in very high-level environments. Well, you must be excited about some of the Arduinos. You still have higher-level languages, but at least being able to feel like you're a little bit closer to the machine than we normally operate on the web. Oh, well, yeah. on the web oh well yeah i mean and also having had the experience of working close to the machine i also really enjoy the experience of working as far away from the machine as possible in a way

you know that's kind of the goal we're trying to make computers tractable for humans and in a way that make means making them less like computers it's interesting that to hear your take too on like i never really thought about it jared but you know how they how the mk14 the sinclair mk14 was a thing back in those days and uh you know jeremy your history and where you came from like you're you're a uh you know let's see his way to say it you're an older guest than we normally have on the show so you have this history that goes back i guess to the early days of things taking place and the early surge

of technology and then now you see more and more like Arduino and you know these kits so to speak that had this resurgence over the last you know say five years how it was a thing and then how it's a thing again you know 1977 now it's you know

2014 2015 and then how it's a thing again. You know, not 1977. Now it's, you know, 2014, 2015. And you certainly see those patterns endlessly repeating. And as mobile phones get 64-bit processors, there's something else even smaller who gets the 8-bit processors that used to drive mobile phones. And yes, it's a great process. I think as a enthusiast for computers one sense in which i feel extraordinarily privileged is that obviously

right back since 19 since the 1970s i've been um keenly acquiring all the computers you know i could and um and one remarkable thing is every computer i've got right up to the macbook pro that i'm um speaking to you on now has been better than the previous one um and that's amazing if you think if if we were um horse riders um it wouldn't necessarily be true by the time you got to my age that every horse you acquired was better than the previous not without a big price but no indeed it's a tiny fraction of the price but it's also terribly slow you know when in the 1970s much of what we take for granted today was envisaged by you know by people who weren't that specialist I remember my remember when I was playing with tape recorders in the early 70s, my maths teacher, or math teacher, I should say,

telling me that in the future there would be tape recorders with no moving parts, which I thought was a fascinating insight. And it took me ages to kind of understand exactly what he meant. And, of course, he was kind of talking about MP3 players, which we then waited 30 years for. And it wasn't useful. I couldn't have bet based on his prediction. But it just reminds us that technology, while it's happening,

can seem like this tremendous rush, but actually it can be terribly slow. And there's all of us on the sidelines saying come on give us a 300 dpi full color display which I've been saying since the early 1980s and it kind of didn't come true until a year or two ago Wow that's true it took a while to get there Indeed

Here's a question I've been thinking about lately and I think Jeremy I'm going to use you as my test subject to ask it and see how it goes so one thing I've been thinking about with software, we cover open source software and we all know how fast it moves. I think we'll talk to you later about JavaScript specifically and how fast that ecosystem moves. And something that I've come to think about more

and really appreciate is longevity because especially in tech where we have a very startup, you know, disruption, fast moving, you know, companies are here today, gone tomorrow type of a, of a worldview. Longevity is something that's really valuable. And so one thing I've been thinking back is like for myself, what's the oldest piece of code that I've written or that I wrote back in the day, which is still running, still working, still doing its job to the present. Or maybe it just quit working. I just realized, oh man, that was running for seven years or whatever it happens to be. So I'd like to cast that at you, since you have such

a long history of writing software. Can you think back and think, what's the oldest bit of code that you wrote that's still providing some value today? Gosh, that's an interesting question. I'm pretty confident that the software I wrote in Visual Basic in the early 90s, that is still being used, including icon designs that I made pretty incompetently now that I've seen more icons. I worked for an investment bank in the 90s, and so it's anyone's guess what's still running there because they do a very odd combination of tearing things out at the first opportunity, but also keeping the most inappropriate things running for 28 years. So they could easily stuff that too.

But Visual Basic has been, you know, um in the programming landscape has been one of the big survivors yeah absolutely i mean it's left an enormous legacy um and all the time in my day job life outside of open source i encounter surprisingly big business empires that are basically based on the back of a big, big, fat visual basic application that's very, you know, typically is kind of molded around the needs of a specific vertical market. But still, you and I would look at it and go, see that icon in the top left? That's visual basic. Very cool. So you recently gave a talk called Hackability as a Human Right. And we're going to get into TiddlyWiki.

I think maybe your perspective at this plays into the software that we're going to talk about today. But before we get to all that, I would like to ask if you're willing to give us a synopsis of this talk and your ideas behind this hackability as a human right? Yeah, so that talk was to a really fun conference called Wuthering Bites in the wilds of Yorkshire and Hebden Bridge. And it's a lot of the people there are hardware hackers. So I was trying to think of something to say that was focusing on what unites software and hardware hackers, because although I had to solder together my early computers, I learned in the process that I'm not a hardware hacker. And having since then worked more closely with people who can wield a soldering iron, I know that it's not my metier. And one of the words that software and hardware hackers use is, of course, hacking. And all I was trying to do was to play with the idea that hacking, what is hacking? And hacking, obviously, I mean in the white hat sense that one has to specify.

And to me, hacking uh changing your environment it's it's tweaking and improving your environment typically through engineering but often just through cunning um and to me the an environment that you can't change an environment that you're prevented from changing is is essentially prison you know that's how prison works. Everything happens to you and you can't change anything in that environment. And so I like those two extremes. The idea that hacking is a sort of an engineering expression of a human urge that if we didn't have, well, not that we would all be in prison if we didn't have, but that, let's say, our lives would be indistinguishable from prison if we didn't have that freedom. And so, you know, we regard not being in prison as a basic human right for people who aren't criminals.

And I think it's reasonable to say to the extent that it doesn't hurt other people. People should have the right to change their environment around them to suit them and obviously particularly in the realm of writing software and creating digital devices changing the world around you you know it's not it's not the james bond villain thing of turning the oceans into a giant algae factory or something we're just talking about improving the light switches you know kind of thing. So, and I think I probably went on a bit about the aspects of all of that that I find matter to me. And one of them that maybe is a good theme for us to explore a tiny bit is that TiddlyWiki is unusual amongst open source projects. Not that unusual, but fairly unusual in that its primary target

are people, user base, people who are not software developers, they're end users. And of course there are things like Firefox, for instance, a notable piece of open source software that's directly used by end users. But if you think about it and if you look at the charts on GitHub, the vast majority of open source products are things made by bunches of developers and consumed by a bunch of developers. And so open source is, a lot of it is a conversation between developers.

Now, the aspect of TiddlyWiki being, gosh, what was your original question? Oh, talking about the hackability as a human right and how that plays into TiddlyWiki itself. I was going to bring that hackability point together with the observation that one of the unusual things about TiddlyWiki is that it's designed for end users. One of its properties is that it's generative. It lets end users make things. And so I like to think that it brings some of the magical powers that developers have, because when we think of hacking, the digital realm that is accessible to developers pervades so much of our lives that if you have that capability as a software developer, you do have these mini godlike powers. You understand the technology around you and you're able to shape it to your needs. And that's a remarkable capability. It's a multiplication of the power of technology. Technology in the hands of a programmer, you can do anything with a computer.

In the hands of somebody who can't program, you can only do those things that the programmers equipped it to do for you. So I'm very interested in tools like TiddlyWiki, and I think there's many others, that provide a palette of tools and capabilities for end users or people who aren't conventional software developers to achieve some of the goals that software developers take for granted all the time. And so does that make sense? So I'm kind of thinking that our duty as developers, we have this sort of natural ability to hack the digital world around us. And rather than jealously guarding those skills and those techniques, we should be trying to bring as much of that experience to ordinary people as we can. And the reason why I think that's necessary is through TiddlyWiki. I've seen that if you provide a tool that can do that, people will build technology to serve extraordinary tiny

niches that would never get filled in the commercial way. So one of my favorite applications of TiddlyWiki is a volleyball teacher who has used TiddlyWiki to create this extraordinarily detailed, extensible lesson planning system. And in fact, it's not, it produces bits of paper, the things that I think are printed out and given to pupils and teachers and so on. But it's also got a whole user interface for defining exercises, goals, goodness knows what stuff. And when you look at it, because I know nothing about volleyball, the thing that's really obvious is that it's riddled through. The creation of it was riddled through with a knowledge

and understanding of volleyball. And so the person who built it as a volleyball expert was able to build something very closely, match their needs because of their tool, because of being able to use a tool like tiddlywiki but um uh but without it there was no way that any of us software developers were going to say oh yippee let's go and write the perfect software app for the volleyball industry so um that's where i was coming from with the hackability as a human right thing this idea

that kind of trying to frame it as an obligation for us for developers i think it's important to um you know consider what you do um in a in a thoughtful way and one aspect of being a software developer is is sort of ethical philosophical considerations and it's worth giving them a little yeah i love that idea you're bringing hackability to the masses and as the ones who are you know the niched uh the people with the current superpowers right the hackers of today like we can bring that to them or we can just hoard it for ourselves and so by building tools for end users that are extendable are hackable we're allowing a whole new class of things and ideas that we never would have come up with on our own.

Awesome. If I've got time to mention a specific one that I like, it's a good example, is that I think Git, or source code control in general, but today that means Git, is one of our superpowers as developers. That imagine that capability in the rest of our lives. It's the ability to make arbitrary changes to things, completely safe in the knowledge that you can wind them back. That ability to experimentally change things is actually completely denied most people.

If I think about my LinkedIn profile, so try and think of something that's the opposite of the concern of a software developer. I might want to change my LinkedIn profile to present myself differently. But there's no rewind on GitHub. I can't go back to an earlier commit. There's just a whole bundle of apparently independent things that I can go in and change. And so that discourages experimentation. And we see that all the time with end user behavior. There's an old adage that a significant goal of users of software is to not mess up, to not be seen, to make a mistake. So yes, there you go.

I agree. I think it's a great example of the ability to rewind and start over and have that. Yes, I'm so sorry. I agree. I think it's a great example of the ability to rewind and start over and have that. I didn't complete the thought by connecting it to TiddlyWiki. I think after the break we'll be talking about the way that TiddlyWiki exists as a single file and perhaps we'll touch on how that can give end users exactly this capability that we as developers get with Git. Yeah, absolutely. I think you teed it up well. Let's take our first break. When we get back, we will dive into TiddlyWiki and how all these ideas of yours play into that software

and some of the success stories you've had with it. So we'll be right back. If you're looking for one of the most fastest, efficient SSD cloud servers on the market, look no further than our friends at Linode. You can get a Linode cloud server up and running in seconds with your choice of Linux distro, resources, and node location. And they've got eight data centers spread across the entire world. North America, Europe, Asia Pacific, and plans start at just $10 a month with hourly billing. Get forward access for more control. Run VMs. Run containers. Run your own private Git server.

Enjoy native SSD cloud storage, 40 gigabit network, Intel E5 processors. Again, use the code changelog10 with unlimited uses. Tell your friends. It expires later this year, so you have plenty of time to use it. Head to linode.com slash changelog. All right, we are back with Jeremy Rustin talking about TiddlyWiki. And Jeremy, we're going to get into all the details. I love the idea of a tiddler. We're going to explain that, the single file, the extendability, the hackability. But before we get into all that,

I want to hear about the conception of TiddlyWiki. You know, there's lots of wiki solutions out there. And wikis are, in my view, kind of a quintessential part of the web and the open web. And so all these wiki systems, most of them are open source systems because wikis kind of have that open idea ingrained in them from the beginning. And so can you take us back to the origin of TiddlyWiki and why you thought

that this had to exist in a world where there were other wiki systems out there? TiddlyWiki's direct origin, as in why I started writing the code, and once I started writing the code, I learned other things that made me think other things. But the original motivation was based on a really simple observation that I'd been using wikis for maybe five or six years in various different work contexts by then and found pretty much what everybody finds. They work really well in a technical community.

They work less well as the community gets less technical. But more interestingly, I learned, as I guess everybody does, that the ability to refactor content in a wiki is incredibly important and that a useful wiki that's shared within a group needs kind of constant tending. Everybody needs to be looking out for opportunities to improve it. And I'll call those improvements refactorings. And what you observe with people using, say, MediaWiki is if they're approaching, there's two perhaps archetypal refactorings with a wiki. One is to split a page into two you know one

existing page you realize that there's a subtopic there that deserves its own page you shift it off into a separate page or conversely you've got two pages that you realize are about almost the same thing and you merge them together and when you watch people doing that with media wiki particularly you will see them open those various pages in different tabs so that they can more easily jump between them and if you're if you've got the keyboard shortcuts to hand for dealing with tabs it can make that kind of refactoring actually pretty efficient and you know when you switch between tabs most browsers will retain the current selection within a text area so it's quite easy to kind of line things up and get quite efficient that way. Although I'm sure the

Emax and Vim users will argue that there's more efficient ways to operate. Anyway, so it made me wonder whether there was a more direct way that the software could support the interactions necessary for users to perform those kinds of refactorings. And then I saw Gmail at the beginning of 2004, signed up the 1st of April 2004, I believe was when they launched it. And it seems extraordinary to a modern audience. But the innovation in Gmail was the way that it showed multiple email messages at once. Until that time, pretty much all email clients, you'd seen a list of individual emails in the thread, you selected one of them and then the text of that email was displayed.

And this idea of having the same user interface gadget that was used to display an individual message repeated down the page, to me, I thought that was really attractive. with a sort of more old-fashioned visual basic, laying things out on a corkboard sort of view, which is rather what was the prevailing view at the time. So all I did was to combine those two existing ideas that I thought to create a wiki where the pages were shown as individual chunks on a page. So actually, I've explained it badly because I was already interested in the kind of philosophy of recording and reusing information. And one of the ideas that I think I evolved,

but that probably means that I read it, was the idea, well two linked ideas really that the purpose of recording information is so that we can reuse it and that the way to optimize information for reuse is to chop it up into little bits um and those are kind of assertions that i have no formal proof of um but that's based on my experience of watching myself and other people working on stuff. And this small chunks of information thing is also, it was part of, at the time I had,

I wanted to write as to be part of the blogosphere. But I knew that my tendency was to write very long pieces i'd been trained in essay writing and with lots of um i have to kind of kick myself to remove the rhetorical flourishes so i rather liked the whole idea of building a tool that encouraged brevity that encouraged concisely expressed ideas so that by optimizing the tool for small chunks of text you would avoid the problem that somebody faced with a massive blank text area will feel compelled to fill the text area you know with unnecessary embellishment and detail nobody likes blank either you know like it's it's if you see a blank page you yeah designers out there that are

familiar with photoshop and a brand new document it's like it's this document you open up and it's just white and it's doesn't encourage any sort of creation yes whereas in tiddlywiki when you add something to an existing wiki your you know your new item will appear alongside the existing entries it feels explicitly like you're creating onto an existing thing where it's presented yes presented with a white box although sometimes it's what you want isn't necessarily conducive to thinking so that was that was kind of the idea and I thought what needed to be what I had a number of other sort of ideas floating around that seemed to connect with it. And at the time, Flickr had just launched. And so I thought that the obvious thing to do was to create a service like Flickr that would be based on what I was calling micro content, small fragments of text that people would share and tag and arrange into albums and sequences and so on. So pretty much Flickr for text for small fragments of text. And the very first thing I did to explore that was to create a prototype in JavaScript. And

at the time, I'd only had the loosest experience with JavaScript I'd looked at it from a distance and thought it looked like C and and not really got much beyond that but right this tiny prototype and at the time I didn't have access to a server and so a friend of mine had a static server. So the easiest way for me to kind of publish this demo so that I could talk to people about it was to create it as a standalone HTML page with embedded JavaScript, you know, that that ran the demo, so to speak. So I put out what i thought was you know what people do all the time a simple javascript

demo that i thought would would maybe start a conversation and you know help me to explore the ideas that i was expressing within it or help me to explore them with other people um and what actually happened was it it got a certain amount of attention from a couple of at the time it was blogs that used to be how people obtained links to interesting stuff on the web and a blog called cocky covered it and oh yeah yeah it's like the oldest blog out there basically i still read cocky oh yeah yeah every day well back then it seemed like being covered by Entertainment Weekly. That's not the best example, I think. But it felt like a very...

Big splash. Absolutely delighted, yeah. And so then there's a flood of people who don't know anything about wikis coming to this demo. And they go, when I say they, I mean the feedback that I then read, particularly on there was a bookmarking service called Delicious at the time. And so one of the sort of ways that I got feedback then that would be kind of on Twitter now was the comments that people left as they bookmarked Italy wiki dot com and the graph of people increasing. And the reaction to it was, hey, that's really great. Once they fix it and make it work properly. And I was like, what do you mean? And the and the people's expectation, despite the fact that I'd build it as a demo, was that it was a product.

And so it got to be rather a. So the way that I'd written TiddlyWiki, you could this initial demo of it popped up a pop-up window that then javascript printed out your data in basically in html and you could copy and paste it elsewhere and so what people were saying was that when you press save it should actually save your changes so that the html file is modified and i got incredibly frustrated um saying to myself and others well that's ridiculous. Of course you can't do that. An HTML file loaded in the browser can't save changes.

That's absurd. But then saw that somebody else had worked on a Firefox extension that let TiddlyWiki save changes. So it used the privileged APIs that were available to Firefox extensions to access the file system and save the HTML file. And then I discovered that these same APIs were actually not that privileged and you could use them from an ordinary HTML file. So then suddenly it was, well, I thought that was a rather nice example of something I found before, that there are certain there are certain situations that the best response to them is just to write code and you know when people are giving you a hard time about shortcomings of a product or um then just write code and it's often the most

most useful response and in this case I'd unexpectedly um uncovered what I now think is a potentially important but still much overlooked way of running software and it's basically the idea is to treat the browser as a virtual machine and you can if you're paying attention of course the browser is quite explicitly a virtual machine virtual machine for running JavaScript but start to think about the browser as being a virtual machine container in the same way as virtual machine containers, hypervisors. And you realize that it's not so very far away. You can provision a new virtual machine by pressing Command-T. The computing power available within a browser tab, of course, exceeds that slice of computing power that Facebook.com or Google.com is going to grant to your unique needs. It's good. I mean, you're describing a little bit of the history of TiddlyWiki. You started off with this demo of an idea around these small chunks of text.

And then people got mad at you. And so you decided, I'm just going to code. Instead of reacting, I'm just going to keep coding. At which point now you've decided that you're going to start storing all of the information in the browser and you're going to start using it as a virtual machine. So a little bit, you're giving us the background of how TiddlyWiki came to be. Maybe let's talk about this idea a little bit more of the unique, or excuse me, of the small chunks of text.

Because it seems like that's the idea that has continued forward as you've developed the software. One thing that we pulled off of, I'm not sure if it was your website or a blog post, is that you said that TiddlyWiki is based on the idea that information is more reusable if it is sliced up into the smallest semantically meaningful chunks and then woven back together to make

narratives and stories and you call these tiddlers which i think i referenced earlier um is that that seems like the unique bit that seems like it's unique take on the world yes and it's again it's it's it's a bit accidental and a bit deliberate. The word tiddler came from writing the code. In the code, I was at first thinking I'm dealing with objects, nodes, items, all those words, records that we use for generic things that you deal with. And lots of apps generalize everything. I think WordPress does generalize everything to the point where basically everything is a post. And so I needed a word to describe that thing

and had beforehand come across the advantages of neologizing an unusual word. And tiddler comes from an English word. Tiddler just means small, tiddly. It also means drunk, so it's kind of a joke. That's where Tiddlywinks comes from, the game with the little tiddlywinks. I think that's different again. It might be the young person, so a game for tiddlers. These are my tiddlers, so you could say about my young children or something.

But it turned out that it was the right place to neologize that the idea of a tiddler, although closely related to lots of similar ideas in other applications, is so important and central to TiddlyWiki that it's worth neologizing and choosing a word that we get to define um and that is pretty much the definition that you gave the idea of the smallest semantic unit so one often when one uses tiddlywiki you might write a stream of consciousness you write for 10 minutes to capture what you just did for the previous hour um and then i think as i mentioned before an archetypal tiddlywiki refactoring would be to slice out chunks into separate tiddlers and then it's kind of the idea of active learning that when you learn something

you write it down um and that that improves your chances of remembering it. If you write it down and then do something with it, use it. That improves your chances even further. So the idea that you'll record information, refactoring it, changing the title so that it makes more sense when you refer back to it in the future, giving it some tags so that it gets tied together into different categories, weaving it together into weaving it into different stories along with other items, those kinds of ways of exploring your data and kind of sorry, exploring your information. And, and crucially, presenting snapshots of it to other people. So you know, a common you think about people who do stuff in Excel, a common thing is they've got some unholy mess of spreadsheets and macros in the background but what comes popping out at the far side is a fairly simple spreadsheet that everybody

can understand, showing the disposition of sand and the sandhills or whatever it is. One thing that FND said is, first of all, the way it's built is unusual and thought-provoking. It's probably this idea, because I think that is the uniqueness. When I think of a wiki, I think of the small, it's a bunch of pages, and you edit a page, and then you link pages. And with WordPress, they had posts,

and everything was a post, and then they added some pages, and then they started to like you know it started to expand beyond that idea and so the software and then the nomenclature had a change and they started to you know started to get that square peg in a round hole um and it seems like uh the the same problem can happen with a page where like you said if you're refactoring or you're i think of it like trimming the hedges like you're you're maintaining the wiki you start to realize that like pages is not small enough for things to actually fit together in the way that you think about them in your mind and so i think the the reason why it is unusual and thought-provoking is because you you're really

focusing down on uh really small units of is it just text or can a tiddler be an image or a link? A tiddler can be an image. Links, you can, there are situations where it makes sense to use a tiddler to represent a link, but you can also have links embedded within a tiddler and you can have MP3 tiddlers, WAV tiddlers, I mean, anything with a MIME type, you can do something within a browser it deals with.

Very interestingly, it also works with SVG. But to pick up your point about TiddlyWiki not seeming like a wiki, the most common characteristic of a wiki is this idea of a wiki that anybody can edit. It's the kind of page that anybody can edit. It's the highest expression, purest expression of the idea of a shared space. It's a shared space with no rules and no admins often. But I always felt what was interesting about wikis wasn't that at all, although that is interesting. It was the way that wikis turned linking into part of the punctuation of writing. So I've always found hypertext and the previous developments in hypertext very interesting.

And one of my observations is I think hypertext is an expression of a fairly common set of beliefs about how our brains work. And our brains work to many of us feel without being too presumptuous um that some of the time it's useful to think of our brains as lumps of things connected by lines you know as would be depicted in a mind map would be a very direct expression of that vision that people have now tiddlywiki doesn't seek to express those relationships graphically like a mind map, although it can, and there's a plugin to do mind mapping. But it seeks to give you a data structure that's rich enough to represent those kinds of structures. So the Tiddler within TiddlyWiki, once you get to the level of detail beyond its smallness, it's a kind of universal data structure for thinking about items of data.

And it's in computer science terms, it's just a hash map by title of an Attidler is essentially a hash map of field values, named field values. So it's a similar data model to a lot of the NoSQL databases at the moment, for instance. And yeah, that's turned out to be kind of easy to do, because it's hypertext, as I say, we're 50 years into the history of hypertext. And we've got some, there's some strong evidence that people like linking as a metaphor for, well, as a way of expressing relationships between items. As software developers, we certainly to define and have this nomenclature to things and understanding the depth and also your path to understand what a tiddler is and what it means to you and how it's an atomic unit and it's the smallest atomic unit is

going to give us a lot of clarity especially as we get into the more technical pieces let's take a break and when we come back we'll dive a little deeper into tiddlywiki how tiddlers play into this larger technical piece and we'll cover that on the side, we'll dive a little deeper into TiddlyWiki, how Tiddler's plan to this larger technical piece. We'll cover on the other side. So we'll be right back.

We're excited to be working with BMC to spread the word about TruSight Pulse, their infrastructure monitoring service with one second resolution. I talked to Mike Warren, the senior architect, about the importance of alarming, but more importantly, the importance of more accurate alarming. We also talked about integrations and how that plays into communicating internally across your teams, as well as outside your organization. Take a listen. So alarming comes in really handy when you have one second data, because we actually collect different resolutions and we aggregate that data into one second, 15 seconds, 60 seconds, five minutes. And what that allows us to do is we can actually pull out some of the noise and give you more accurate alarms. Now the question is, what do you do for me? Send me an email? Well, that's not going to be very helpful. Really what I want is I want to find a way to push that towards

my team so we're all knowing what's happening with the services, what's up, what's down, what's fixed, what's not. And that's where the integrations come in. So integrating in with things like your chat, how do I integrate into my other tools like PagerDuty or Ops Genie? So how do I take advantage of hooking up who's on call and who's not?

And then potentially how do I do automation? So fire off a web hook, or potentially if you have another setup you can set off an email and maybe that triggers something for you. But essentially you end up with that full round trip with everybody involved in that process and that's your developers and your operations team because both of them have to be involved and know what's happening. So kind of with that end-to-end level we can pull the different stats from everywhere, we can share those dashboards between anybody in your team at a certain point in time, and we can embed those dashboards into

any of your existing dashboards or monitoring tools or things you may have. And that gives you the ability to share that information outside your organization. So that way you kind of have that one single piece that you can talk about, share about, and see those metrics everywhere. I A, have the ability to have that communication with my team, and I B, have the ability to have that same visualization across my team and external to our team. That was Mike Morin, the Senior Architect of BMC's TrueSight Pulse. Head to bmc.com slash TrueSight Pulse, all in word,

to learn more and tell them Adam from the Cheese Log sent you. Alright, we're back for the break. Tilly Wiki, Jeremy is here. We're talking you know, we quite we talked about breaking down each of the pieces. Tiddlers, as you called it, I love the backstory

there, especially tying back to the UK UK where you're from. If you're listening to this show and you couldn't tell us where Jeremy's from, then check your ears or something like that. But TiddlyWiki is 98.5% according to GitHub JavaScript. How do you, you know, we cover that a lot around here. We have a weekly email. We're always seeing the ups and downs, and we even cover the madness of frameworks in JavaScript and the fatigue that comes from it.

So having such a JavaScript depth to TiddlyWiki, how do you personally deal with this ever-changing JavaScript landscape? That's a good question. So TiddlyWiki started in 2004 before any of those things existed. So I had to write my own bits of code to smooth to TiddlyWiki, it's quite useful to keep it as clean as possible. So it's pretty much self-contained. It doesn't use any external libraries, but you can use external libraries with it. So there's a sense in which some of the considerations that you'd apply to a library actually apply to TiddlyWiki, even though it's an application. So I've been in a happy position of being able to watch and experiment with lots of JavaScript libraries.

So D3, for instance, which I guess now is probably five or six years old, was one of the things that helped me to understand the potential of SVG in the browser. So SVG at that point, embarrassingly, we hadn't realized that a technology that had been broken in 2002 had quietly got fixed over the following five or six years More recently things like angular and

reactive the kind of second wave of frameworks I I don't use those frameworks because say tiddlywiki is kind of easy its own framework tiddlywiki has a Consciousness might be going a little bit too deep if i could jump in how is it uh describe how tiddlywiki is its own framework so i mean you'd mentioned uh i think you mentioned react and i couldn't remember what else you said but um because i was trying to follow along but but how is it its own framework? From a distance, this will seem like a circuitous answer, but hopefully we'll get there in the end. From a distance, what a wiki is is a piece of code that converts wiki text into HTML. and particularly the new version, my goal was to make the Wikitext powerful enough

that the user interface of TiddlyWiki itself could be written in its own Wikitext, thus making it highly extensible, et cetera. And it's just like writing Chrome developer tools being written in JavaScript. It's kind of a logical approach. And so you can imagine then that the pipeline that goes from Wikitext to the DOM needs to be interactive in that case. So what TiddlyWiki does is it parses the raw text

of the Tiddler into a pretty straightforward syntax tree. And then it executes that syntax tree into what TiddlyWiki calls the widget tree, which is pretty much the virtual DOM tree that you see in things like React and Angular. And the virtual DOM tree, then there's a process that does, well, close to the minimum or a fairly good subset of the maximum updates, selective updates to the DOM. So if we've got a Wikitext construction like a transclusion, which will be familiar to JavaScript programmers from ordinary web development templates,

so double mustache in Wikite text typically means translude this other page make it appear as if this page is here and so in an interactive wiki like tiddlywiki you want to make sure that if the text of that target page that is being transcluded changes then we get minimal Dom updates to update the transclusion but not the text around it and that that's what TiddlyWiki does. And that enables all the paraphernalia that you see in the user interface, things like tabs and dropdowns and everything else, is modeled as the state of Tiddlers.

So the state of the user interface is modeled as Tiddlers. To update the DOM with the state of the user interface is modeled as tiddlers. To update the DOM with the state of the user interface, we render one single Wikitext template that expands out to be the entire DOM tree of the user interface. So what I described there was kind of talking about the internals of other libraries. And many of the people who use those libraries wouldn't necessarily think about them working in that way. And I find that when I read about these libraries, I have to kind of do some picking apart to relate my understanding of what they do

to what I know about how TiddlyWiki works. But it's good to see that we're all on the same page. You do stuff in JavaScript as much as you can. You don't touch the DOM unless you have to. Back in 2004 DOM as essentially transient, as something that you can recreate at will. So that stuff, those characteristics of TiddlyWiki, interestingly, they're not appreciated in the terms I've just described them by the users. It's a very developer-ish quality that I'm describing. Which we're happy to hear as developers ourselves and developer audience. So feel free to share those details. They're absolutely interesting to us.

So one thing that FND mentioned is that the, and maybe I missed it, so forgive me if I did, that this latest incarnation of what TiddlyWiki is was rewritten from scratch. Was there like a big rewrite somewhere in the history and what was the reason for that? There were a whole multitude of reasons, but the main one was that some of the quality of the code

in the original Tdly wiki was pretty poor i didn't know javascript when i wrote the first version i thought it resembled c and i treated it like c for a few weeks and then gradually learn more and more about javascript but it meant that there were decisions that were there were decisions that were impossible to reverse because other people had written code plugins and so on that was based on my code so i really felt that to fix the internal architecture we needed a complete rewrite but there was also an opportunity in the change in the environment that JavaScript had shifted from being Regarded as a niche embarrassment to become somewhat mainstream so somewhere in

2011 node.js launched and I'd been waiting for that when I was working for BT in the 10 years ago I looked at Rhino so that it was possible to run JavaScript on the server. I used Rhino back in the day. Yeah, in the late 90s, the Netscape had some software that involved running JavaScript on the server. And looking at Rhino, making TiddlyWiki as I had written it work in Rhino

would have been almost impossible because TiddlyWiki was heavily based on the DOM. There was no DOM in Rhino and there was no decent support for writing web applications, for writing web servers. So when Node.js came out, that seemed like a wonderful opportunity to fix one of the biggest frustrations for me about TiddlyWiki which was the limitations that stemmed from running as a single HTML file in the browser so it's the it's the quality of TiddlyWiki that leads to its most unique and unexpected features. But it also, as everybody listening to the podcast,

has profound limitations. There are pretty severe limitations to what you can do in the browser. And I was confident that the ideas that we, the community, had explored with TiddlyWiki were equally applicable to the server. So the opportunity, when Node.js came out, the idea of writing diddlywiki as an isomorphic application became overwhelming. And I left

the job that I was in, in order to do more flexible freelance consultancy works so that I could spend a bit more time on this rewrite. So how is the wiki content persisted nowadays? It depends where you're running it. In a way, this is the easiest audience to explain it to. Imagine that we've got a function, just like I described, that takes a chunk of Wikitext and converts it to the DOM. To run that on the server, we have an implementation of a very simple, I call it the fake DOM, but, you know, JavaScript, pure JavaScript implementation

of the DOM APIs so that on the server we manipulate that fake DOM and then we do an inner text on it to extract the HTML. So given that engine and its capability of running in both of those places, we can run in a bewildering number of configurations. So we can run entirely in the browser and we save changes using HTML5's download attribute, which is a standard attribute, a standard feature of HTML5 that allows JavaScript executing in the browser to prompt for a download. So in that case, the experience is that each time you press save, you get a fresh copy of your up-to-date copy of your document.

And that's not bad. It means that you get cumulative backups or you can configure your browser to prompt you when you save and then saving is a two-click operation but you update the original HTML file. or there's a NWJS based desktop application that access a sort of custom browser that lets the single file configuration of TiddlyWiki again persist changes directly or you can run it under node.js where individual tiddlers are served over HTTP to another instance of TiddlyWiki running in the browser and then your changes are persisted as individual files, so each tiddler is an individual file. Or you can run TiddlyWiki in Amazon Lambda, where it starts up, reads a whole load of tiddlers from DynamoDB,

mashes them together, and then squirts the files out to Amazon S3. So really, although it's packaged and presented as a product, and I highlighted how important to me it is that it serves the needs of end users, what it eats, in fact, functionally is a reusable JavaScript library for handling Wikitext. And within TiddlyWiki, we reuse it endlessly. So I described how we convert Wikitext like headings and lists and so on to HTML. But we use the same engine to convert style sheets. So inside TiddlyWiki style sheets, we transglued what would in something like SAS be a variable. So we've got magic tiddlers that contain say the

background color of the page and then in a style sheet wherever you want to reference the background color of the page you just transglued that tiddler and that's that's the characteristic that i think all developers love is the idea that you only introduce new mechanisms reluctantly. And when you do introduce a new mechanism, you make it pay its keep by using it orthogonally on lots of different problems that have the same shape. And I think you see that in lots of software. pipeline the same processing pipeline to do interactive rendering in the browser to produce static renderings on the server that you know then get served on a static web server plus all this internal stuff like the way it handles style sheets the way that it handles color palettes all that kind of thing is all wiki text mechanisms reused and there's something very pleasing about it as the creator yeah the idea is as a user it's tools that behave like that have this pleasing property that you learn

how these components work and ideally you know in a sequence where where you learn about the gradually more complicated ones and then kind of like a bicycle, they become, they're kind of, the internal structure is sufficiently apparent that you can have a strong mental model of how to use the tool. You can anticipate how it's going to behave in a situation where you haven't used it before. It turns into something that feels like

an augmentation of your brain. And that takes us back to Vannevar Bush and the early hypertext pioneers. They were obsessed with the heretical idea that people would use computers interactively. So in their work, one of the challenges they faced was just persuading people that that was practical and that the purpose of doing that

was to extend our capabilities. You sent us a nice write-up in Network World about TiddlyWiki. We'll link that up in the show notes. One thing they said in that, which I thought was super interesting, I think it plays into this idea of a single pipeline, is that TiddlyWiki is a quine.

Some of us know what that is. Some of us don't. I've actually seen these before. I don't think Adam had, but they're quine, Q-U-I-N-E. It's the idea of a program that doesn't have any inputs, but as it's the process of it running, it outputs its own source or it outputs itself as the program.

And I've only seen those as like mental gymnastics type of yes things like one-liners how do you do that can you do this in this language they're very short snippets and they're you know it's a it's kind of a not a toy but just a way of people to challenge themselves and i've never seen an actual full-on useful program that's also a quine can you speak to that yes um there's well you'll see some spectacularly useless quines. I've seen quines now that run in more than one language, quines that are also ASCII art at the same time. So yes, there's no limit to how much effort people will put into these apparently pointless pursuits. But it's because it speaks to some sort of inner satisfaction. It's like

an automaton that can reproduce itself is a fascinating thing, especially if you throw it in the lake of raw ingredients. So yes, it's a kind of timeless vision. I love that. Absolutely love that. Well, let's take our final break. And we want to talk about a few other things on the other side. Specifically, we talk about deployment and all these different ways you can persist it. I want to talk to you about what that looks like for your end users,

whether they're going to tiddlywiki.com or it's a one-click install on a shared hosting or how the end users come to TiddlyWiki and set up their own and use them. And then also we'll talk about getting started, helping out, getting involved, if you're looking for helpers or not. So we'll discuss those things

as well as our closing questions on the other side of this break. Here at the Change Law, we have two emails we'd love for you to subscribe to. The first is Change Law Weekly. And we've been shipping this email for several years now. We ship it every single Saturday morning. It's everything that hits our open source radar.

It's our editorialized take on what happened this week in open source and software development. Go to changelaw.com slash weekly to subscribe. And our second email is ChangeLaw Nightly. Every single night, we ship this email out covering all the top new and top star repos on GitHub at 10 p.m. Central Time. It's all the latest stuff on GitHub before it blows up. It's often our own radar.

We're often creating shows and finding new people, finding new projects, putting things on our own radar based on what we find in there. So we'd love for you to subscribe to that. Head to changelog.com slash nightly. And now back to the show. So Jeremy, before the break, you described all these different ways that you could persist your titlers into different backends, even AWS Lambda, which is pretty interesting.

And I started thinking, this sounds like a really awesome hacker tool. Like you can do it this way. You can do it that way. It's what hackers love. Like give me the flexibility. Give me the freedom. I want to run sounds like a really awesome hacker tool like you can do it this way you can do it that way it's what hackers love like give me the flexibility give me the freedom I want to run it on a raspberry pi I want to put it on the digital ocean but you also want this to be a general purpose usable tool for anybody not for just hackers so what's the use case of somebody who's coming to it and they're just looking for a wiki or they're just looking for this web-based notebook?

How do they use TiddlyWiki? Great question. My approach to it has actually evolved over the time of the rewrite. When I started the rewrite, I thought that it was important to present TiddlyWiki in all of its multifar its multifariousness not sure if that's the right word but all of these different things that you could do with it um so i presented them or tried to present them on the site as if they were kind of peers um and what i found was that that was confusing for quite an important constituency which is the people who were going to use the single file version of TiddlyWiki were terrified of GitHub,

didn't have any understanding of the command line, so the non-developer types. So what I've ended up doing is making two pathways, if you like, gosh, that's a ridiculous word, but one is people going to tiddlywiki.com, we try to help them as quickly as possible to start using the standalone edition on their machines and the github and it's github.com slash germline slash tiddlywiki 5 which is the the rewrite version is information for a developer audience and that does try to give a taste of

all of this of all of these possibilities but i think as other open source projects have found that's when the all of these interesting developments in the project a lot of them aren't from me that they're scattered throughout the community and there are very different stages of development and um and some people have different published at different times um so the community can seem very fractured um we've we've done a great job in open source of adopting tools that help to minimize that effect. And GitHub itself, of course, the word hub is right in that to remind us of its main purpose is that it's the, what do you call it, the village green for open source development. Right. Speaking of GitHub, I was on the TiddlyWiki GitHub page there, and I noticed something that was a little bit concerning,

and I just wanted to talk to you about the state of it, because actually one of our closing questions is sometimes how can the open source community help support TiddlyWiki or the project that is important to you, in this case TiddlyWiki. And one thing I noticed is you've got a whole bunch of open issues out there. You've got a lot of pull requests. You've got 67 open pull requests. You've got 520 open issues.

And so I'm just curious if maybe the demand and the interest in TiddlyWiki is overwhelming you or you've got it under control. What's the situation there? Interestingly, you're raising something that we in the community are trying to tackle at the moment. It's partly the result of a poor something that we in the community are trying to tackle at the moment it's partly the result of a of a poor decision that we made um last year maybe the year before um so we use um google groups as the mailing list for the project and we've got a um mailing list called tiddly wiki and a mailing list called tiddly wiki dev the first for users and the and the second for developers and um i think pretty much we all hate it um but um it's you

know it's it happens to be um where we tied our horse uh that's a bad metaphor but right at the beginning um and um some of the non-developers, anyway, for various reasons, we decided to experiment with using GitHub issues for discussion. And so quite explicitly, we had the policy that it was okay to have basically anything that you wanted to discuss as an issue

without a clear policy on closing the issues. We're moving now to a much more conventional and, I must say, familiar for me approach. Yeah, that's a lot the issues. We're moving now to a much more conventional and I'm so familiar for me approach. Yeah, that's a lot of issues. I was worried. And you'll see the worth of those. I mean, a fifth of them are one person.

And you should be extremely careful that I think that in open source, we are incredibly lucky whenever anybody opens their mouth. Even if they're saying something, the same thing as somebody else, any kind of feedback is like oxygen for an open source project. And it's obviously it's only other people's interest that keeps any project like this alive. So, yeah, a bit of a misstep on how we handled issues. that keeps any project like this alive. So, yeah, a bit of a misstep on how we handled issues. We're moving to issues being more explicitly needing, well, explicitly being the to-do list for the core developers and there being basic requirements about actionability

in order for them to remain open. And we will continue to host, I'm sure, lively discussions on closed issues, but we'll try and keep the open issues, the above the waterline issues, reflecting what we think is actually doable, actionable work. That makes sense for issues, but what about pull requests? Oh, well, I mean, A, I'm behind so there's but you'll you'll see if you look back that some of those issues have been around for an embarrassingly long time so again i've not had a clear policy on closing pull requests so if they where they've gone off

into a discussion i've tended to just leave them open And the reason is because I haven't been using call requests or issues as my to-do list. I've been tending to fall back to using, essentially using email as my to-do list. You know, you respond to the tickets that thanks to the noise on them, they've risen to the top of your inbox. Squeaky wheel, just the oil. It's also, I think it kind of reflects our peculiar heritage as having a

substantial audience that are not developers um so a lot of those a lot more of my tickets i think are opened by non-developers than you know would be typical for for a library or a framework or something. In terms of pull requests, I wonder, I think TiddlyWiki is also quite hard for new developers to get into because of some of the things we touched on. It is its own framework. It's not like working in jQuery, not keeping state in the DOM is profoundly difficult for people who've only ever worked that way. So we do, plus I'm sure other people have experienced the same thing. You have to have

quite a high bar for what you accept. Well, how well do you document those things? Like that, that the DOM piece specifically, because it sounds pretty unique. It sounds pretty awesome. But you know, how well is that documented that invites people into? Because I think docs might lend a hand there. Again, a very good question. And I think I personally am not always the best documenter. So I can think that something is fully documented because I've precisely described it unambiguously. And yet there's an enormous gulf between, in some cases, between that and what's needed for people to have a clear understanding if they lack the context of being inside my brain.

So, yes, it's a challenge. And I guess what saved me, so this rewrite has been going for five years or nearly five years now, with pretty uniformly all the way through, people could come along and say the documentation could be improved. And yet we've survived. And I think it's the universality of code that actually saves us.

That for a small but significant part of my audience, they can verify how the software operates by looking at the code. And there's not that much of it. It's fairly neatly sliced up. And so if you've got enough of an incentive, it's reasonably tractable to find your way around and just see what the thing does. Well, there's different kinds of open source projects out there. Every maintainer or author runs their projects a little bit differently. And you've got 87 contributors over the years,

and this is probably just since the 2011 rewrites all we have history in git but if we go look at the contributions list um you know you have over 5 000 commits personally and the next closest is 158 so we have an order of magnitude difference there and is it fair to say that you're the primary developer you know on tiddlywiki and you know you have people who pitch in here and there, but it's not like a robust team that's working on it day in, day out. That's absolutely true. Yes. Is that, do you like it that way? Are you looking for more help or are you looking, or you'd like to keep on, keep it on and like people can help in other ways? The, the most, some of the people who missed out of that analysis are the people who are missed out of that analysis

are the people who work on kind of other things within the ecosystem. So, for instance, this TiddlySpot is a hosting service that's been running for almost as long as TiddlyWiki, and it's completely independent and is by by people other than me so yes in terms of the code that does tend to be um 98 percent jeremy um or 95 percent jeremy i'm not sure um but in terms of the ecosystem as a whole it does it feels crucially like i'm less than 50 because again projects like tiddlywiki like all open source projects it deals with the conflicting requirements of its user base by adopting a plugin architecture so that we can encapsulate conflicting requirements and plugins and um in any project with plugins

and a community you'll see most of the innovation happens out in the plugin space. And that's definitely how I like it because that way there's a multiplicity of different things going on at once. Things aren't serialized on Jeremy's singular brain. So it ends up, if you want a system like that to survive and be healthy, oddly,

the core needs to be unbelievably conservative. You basically want to hardly change anything apart from, you know, let's rephrase that. Well, actually, you want to hardly change anything. But once you've got to where you need to get to, but what you do change, you need to pay incredible attention to backwards compatibility because plug in architectures typically allow very tight coupling between the plug ins and the host architecture. And so you never really quite know what you might change that might inadvertently affect a plug in. job in the core is for sure there's a there's an agenda of features and mechanisms that need to be added and and improved but a big part of dealing with the kind of daily development is is that is kind of making sure that it works well as a as a platform for the ecosystem, trying to encourage contributors in many cases

to focus their efforts on working on plugins rather than the core. Because once you put something in the core of a project like TiddlyWiki, there's no going back. You can't then retract it. You can deprecate it. But if you want plugin compatibility to to carry on you've got to

keep the thing there so there's a kind of uh it ends up as i said i'm making i'm making it sound like a horror movie a room that you can never go back into but but honestly it's joyful because what one what one sees us you know in exchange for I can't treat the core as my play thing, that I do what I like with, I have to be extremely respectful. And what I'm respectful of is this, the ecosystem in the sense of artifacts that people have created, but also the thousands of hours that people have invested in understanding the product, figuring out how to get the best out of it. And in the end, the software is, in open source, is often a means to an end. And the end is a well-informed, purposeful community that can solve a bunch of problems together or alone that they couldn't do before. And I feel that we, again, because of this sense of TiddlyWiki being used not just by

developers, therefore it's used in an incredibly wide array of situations and contexts. And yes, that feels like the most fun I can have as a developer. Writing code for other people. Awesome. I think that leads us right into our closing questions. You just mentioned all the different ways that people have been involved. Plugins, obviously you had robust discussions in the issues. Maybe not the best place for them, but live and learn. So our first closing question for you kind of relates back to what we talked about just a moment ago. If you could have a clear call to action, you know, or a call for help

to the open source community on how they can help you take TiddlyWiki even further or, you know, to new heights, what would you say to them? What's the best way people can hop in and help you out? It's interesting. I think what open source needs is people paying attention to it. As we touched on before, one of Tilly Wicky's shortcomings is documentation. One of the things that I've learned about documentation is that we can try to have a single body of reference documentation that completely accurately describes the behavior of the system. That would be a great thing to have. But it's actually not really what's needed.

What's needed is introductory documentation that helps people up the on-ramp of using TiddlyWiki because of all the different directions that that can take. So, for instance, we've got reasonable coverage for people who want to use TiddlyWiki in that standalone single file configuration. But the material for getting up and running on Node.js is still not as straightforward and easy as it should be. So helping with the documentation in TiddlyWiki is quite a good way to start because the documentation is written in TiddlyWiki. So making a contribution to the documentation

is itself working with TiddlyWiki. And then for a long time at the beginning of TiddlyWiki, it was actually writing, beginning of the rewrite, it was writing the documentation that drove the development. I was busy writing the tech docs and then trying to write the features I needed of TiddlyWiki in order to present those documents. So given the fact that you began on a Sinclair MK14,

you've been hacking since, and the positive, the white hat version of hacking, not the negative given your expansive history with programming and languages and all the ups and downs and of tech and how it's gone slow to you or gone fast to others you gotta have a programming hero i can't even imagine if it's just one but if you could just give us one single programming hero who might that be for you yeah and um i thought about this and um there's somebody who i became aware of in 1996 so i guess um uh i'll have other programming heroes from when i was younger but it's ward cunningham He's the developer of the original wiki. And for me, the thing that actually first

attracted my interest was a colleague showing me the thing first, and then telling me that it was 700 lines of pearl. And I still think that's an incredibly impressive achievement that such a powerful piece of software with profound implications that we've gradually learned as we've used it and built communities around it should be 700 lines of pearl. Pretty amazing stuff. So for that and for his work on programming patterns, no difficulty in nominating Ward Cunningham.

So it may make some sense, too, to choose somebody who's actually written a wiki before, right? It just seems like it's perfect, a perfect interview. So, yeah. Well, Jeremy, it's definitely been fun having you on the show. Definitely been fun diving deep into Tilly Wiki and your depth as a programmer, your history as a programmer, it's certainly appreciated to come on a show like this and share, you know, from the 70s to

now uh this this rich history and to see you i think the most inspiring thing is that you haven't stopped you know is that 30 years later how many ever years later whatever the actual number is you're still going so there's something encouraging in open source there's something encouraging in this community and i think what if you didn't say it directly, I think a lot of your thoughts and a lot of your passion shares that this is a rich, vibrant thing to do. And that it's encouraging to those who might be listening to the show that's thinking, is open source for me? You know, I'm not getting paid.

I'm not getting retribution for it. But it's inspiring to see that you've kept it going for all these years. But anything else you want to say in closing before we tell the show? Yeah, please. If you like what you've heard, please give TiddlyWiki a try. It's the easiest thing in the world. Just go to TiddlyWiki.com in your browser and give it a go. Fantastic. And as I said, it was awesome to have you on the show today. Thank you so much for spending this time with us. To the listeners out there, we thank you for sharing the time as well to hear Jeremy's past and his history he shared here today. And those who sponsored the show,

we love you. We thank you. And our members, you guys rock. Up next, we do have some big shows. We've been mentioning these shows and we're excited about the next few weeks of the change. We've got the future of WordPress and Calypso with Matt Mullenweg. And we also have a big show we're working on with Matt's, 20 years of Ruby. So if you're a Rubyist, if you've ever even thought about writing Ruby, if you've ever envied Ruby, you want to listen to this show and you want to tell every single person you know that we're doing the show with Matt's. It's going to be awesome. 20-year history. We've also got Raquel Velez, bot npm in the play of blinds so stay tuned for that uh and that's it guys so let's tail out let's say let's say goodbye bye thanks

jeremy thanks for coming on thanks jared thanks adam thanks very much bye We'll see you next time. you