Making a list
Pondering how projects become products
I think I’ll stop apologising for the large gaps between these emails. In one way, I’m doing you all a favour by giving you less to read.
I will also skip the story about stealing a laptop from one of the world’s largest IT consultancies again. Maybe I’ll tell the story next time. Maybe I’ll leave it as a teaser for you all that never gets resolved. Maybe it never happened.
Today I want to talk about the difference between projects and products. This is a thought that turned up pretty much fully formed in my head a few days ago. I haven’t written it down before, but it feels important and/or useful so I thought I’d share it with you.
I’ve written a couple of blog posts recently about my “pointless personal projects”. I used to call them side-projects - but that ruined the alliteration.
Here’s a blog post that’s even called “Pointless Personal Side-Projects”. It concentrates on the software I wrote to create my link site - links.davecross.co.uk. In it, I make the point that projects like this can be used to gain experience in new programming language features or new technologies.
And here’s a more recent blog post about another of my projects - Combining Calendars. An important point in that post is how anyone showing the slightest interest in one of these projects can get me so excited that I’ll spend days adding new features.
These projects (and, if I’m honest, probably a dozen more) came into being because I had an itch to scratch. And, going back almost forty years, I remember that being the explanation for how most good open-source software projects got going. Someone had a problem and wrote software to fix that problem. Other people had the same problem and they got value out of using that software too.
Of course, projects that solve problems aren't all going to be open source. All software exists to solve a problem. And, if you’re lucky, people will pay you for the software that solves their problem.
And that’s when I started to wonder about the path from problem to project to product (there’s that alliteration again). The idea that popped into my head (while I was asleep) was that it’s a four-stage model.
In the first stage, there’s the recognition of a problem and some attempts to sketch out something that solves the problem. Here’s an example. I wrote a blog post about a program I wrote that would suggest artists that I might want to listen to. The blog post talks about a couple of iterations of the project but there were a few more after the post was written. At this point, the code doesn’t need to be good (although I have standards to meet if I’m going to include it in a blog post!) It’s just a proof of concept - demonstrating that the problem can be solved, even if we haven’t found the best solution yet. Very few of my projects stop at this stage.
The second stage is making the code available for other developers to read and use. These days, that means uploading it to GitHub. And because you’re making it available for other people to read, that’s going to involve cleaning up the code. This is when you become more interested in confirming that you have the best solution to the problem. You might well (certainly if you’re me) break the code down into classes, make it testable and remove any hard-coded configuration information (put it config files, accept command-line arguments or read it from environment variables - all three if you’re feeling generous). This is the point at which I’ll be thinking about including a version number. Most of my projects get to this stage. Very few of them get any further.
The third stage is making it available to the general public. These days, that’s probably a web app (although, I should probably investigate how easy it is to make a phone app too. In the past, it might have been some kind of desktop app but, to be honest, I’m glad those days are behind us. At this stage I’ll need about things like deployment and hosting. It’s likely that I’ll need some kind of user management system (although things like Line of Succession or ReadABooker don’t need that). This is definitely the stage that would benefit most from a checklist of things that need to be done). I kinda assumed I was bad at getting things to this stage but, thinking about it, I have quite a few projects in this state - it’s the reason why I own so many domains!
The final stage - the Holy Grail - is to make the it profitable. This is, of course, the hardest step. And that’s why so few projects get to this stage. First you need to decide how you monetise the site and then you have to implement that strategy. And, finally, you need to market it so you get enough users to make a profit. I know that marketting is where I fall down pretty much every time. I do get things to this stage (ReadABooker is full of Amazon affiliate links; Line of Succession has a shop page and a load of Google Ads) but none of them have the traction they need to make real money.
And there you have it. My roadmap to profitable products. I’m not saying it’s the only way to get to a profitable product, but I think it’s a workable one. And, having written this down, it’s clear where I need to address my efforts. I can’t just keep throwing projects up on the web and just expect them to find their audience. I need to get better at marketing. So even if you didn’t get anything useful out of this newsletter, I think I’ve learned a valuable lesson.
What do you think? Have you tried to turn an itch-scratching project into something profitable? What route did you take? How well did it work out?
In other news
A few other bits and pieces…
I’ve mentioned before that I’ve been pleased with my experiments in AI-aided programming. I now have access to the beta version of GitHub’s Copilot Workspace. Where the standard version of Copilot makes suggestions in your editor while you’re working, Copilot Workspace takes it a step further. You give it an issue in one of your repos and it will plan and (when you give it the go-ahead) implement the required changes. You’ll end up with a pull request that you can examine and merge just as you would if it came from one of your colleagues. I had a lot of fun yesterday, whizzing through a load of issues that needed fixing in one of my (stage 2) projects. There was nothing that would have taken more than an hour to implement. But with the help of Copilot Workspace, each one took about ten minutes. I was very impressed and will be using it again.
The first batch of talks for this year’s London Perl Workshop have been accepted. This includes a “Conference-Driven Development” proposal from me. I’m not quite sure where that fits on my list of stages above. Maybe Conference-Driven Development is its own thing. The LPW is returning for the first time since 2019.
I’ve been worrying for a while about the way the Perl community is shrinking. A smaller community will have problems mainitaining community infrastructure and even adding new features to the language. A particular worry for me is the number of CPAN modules that are becoming unmaintained. This week, Curtis Poe realised that DBIx::Class (a popular library for database access) is basically unmaintained and hasn’t been updated since 2022. It currently still works fine, but that won’t be true forever. You might be interested in the discussions about this on Reddit and Facebook.
I won’t promise when the next of these newsletters will appear. But I’m quietly hoping that it’ll be some time in August.
Now I’m going to get back to moving projects along the product scale.
Cheers,
Dave…