Validating a new project

MP 142: Conference "open spaces" are a great place to get valuable feedback about new projects.

Note: The debugging series will continue shortly. I spent a full week at PyCon, and my son graduated from middle school the day after I got back. Life has been busy. :)

I just got back from PyCon US, and it was a fantastic conference overall. I may do a recap post in the next month or so, but I wanted to share one specific aspect of the conference.

PyCon, and many other conferences, has a series of "open spaces" alongside the main track of talks. To present a talk, you need to submit a proposal and have it accepted. To host an open space, you just need to sign up early enough during the conference to grab an open spot in the schedule. Open spaces allow people to come together to discuss anything of interest to conference attendees. There are open spaces about all kinds of Python-related projects, topics relevant to software development in general, and topics that have nothing to do with programming at all. Open spaces used to be organized by adding post-it notes to a big board, but now they're managed online. You can see all the open spaces that happened at PyCon US 2025 here.

If you've been reading the debugging series, you'll know I recently released a project called py-bugger. That project generated some initial interest when I shared the first proof-of-concept version. But I wanted to know if it was likely to have sustained interest, so I decided to host an open space about the project. I'm really glad I did!

Initial interest

If you're building a new project for yourself, you don't need to worry much about validating the idea. You know the problem you're trying to solve, and you can continually evaluate whether your project addresses that problem in a helpful way. But if you're building a project aimed at other users, early validation of the overall idea is really important. It's way too easy to spend a long time, sometimes years, working on something that other people really aren't that interested in using.

When I had the idea for py-bugger I made a minimal working version, which was only capable of introducing one kind of bug. I made a brief post on Mastodon, and asked for feedback. The post spurred some interesting discussion, and the project quickly got about 20 stars on GitHub.

But how much is that initial validation worth? It certainly shows the project has some real-world value. But with a small network of friends in the programming world, it's not that hard to get a few stars on a new project. I have a friend who's fond of saying, "GitHub stars are only good for measuring how many GitHub stars you have."

Heading to PyCon, I wanted to have some face to face conversations about the project, hopefully with people I don't already know. An open space is perfect for that.

Hosting an open space

If you're thinking of hosting an open space, sign up early and write a clear description of the discussion you hope to have. People will show up based on what you write, so make sure they know what they're showing up to. Share your post on social media with the event tag as well.

The py-bugger open space

About eight to ten people showed up for the py-bugger open space. I asked if people had tried it, or just seen the description on the open space schedule. Most people hadn't tried it yet. I had prepared a lightning talk about the project in case the opportunity arose, so I did a quick run-through of those slides on my laptop. It's not as nice as a talk with a full projection screen, but for a group this size it was enough to get everyone familiar with the project so we could have a more focused conversation.

A number of concrete things came out of the discussion:

• People generally agreed with the idea that how we teach debugging is not very satisfying, especially in comparison to how we teach most other aspects of programming. People agreed that we tend to make up a few small examples to teach from, and then wait for bugs to show up in students' code.
• There was interesting discussion about how to generate bugs that induce some less obvious exception types. For example, how do you modify a codebase in order to generate an IndexError? Someone suggested looking for a range() call used to define a sequence, and noting the length of that sequence. Someone else suggested adding a pop() call somewhere in a loop. It was really helpful to have this kind of conversation in person, and in a small group setting. These thoughts have been swimming in my head since I started this project.
• Someone asked if it would be possible to target a specific block. Currently you can target a specific directory, or a specific .py file. At first I wasn't clear on the reason for wanting to target a specific block of code, but then I reminded myself that people want to introduce bugs with a specific teaching goal in mind. It didn't take long to start thinking of ways to target specific blocks. It's not the highest priority feature, but this project is one where feature creep isn't really an issue; it's quite modular, and a more-featured bugger is useful to everyone.
• Someone else surprised me with the first non-educational use case I've heard for py-bugger. They work on a codebase that ingests the output of other Python programs. As part of their test suite, they want to induce specific kinds of errors in the programs that feed into their project. They'd love to have a mature version of py-bugger to use as part of their testing pipeline. This is different from mutation testing, which inserts less targeted changes into your codebase.
• Someone mentioned the possibility of doing static analysis on the target codebase. That's a really interesting idea, if the target project uses type hints.
• Someone wanted to know why the project requires Python 3.9 or newer. I always pin new projects to the currently-supported versions of Python. Some people are stuck on older versions, so I made a note to find the oldest version of Python that works with py-bugger, and drop the requirement to that version. I'm not planning to address support issues related to older versions of Python, but I won't stop people from using it with older versions if it doesn't require additional work.
• One person said they really like the logo. I don't usually come up with logos for my projects, so it was nice to hear that this one is appealing to people. A good logo really can help people connect with a project. I don't necessarily think this should be the final logo for the project, but it's a good start.

One thing was clear from all this discussion. There are lots of ways to consider introducing bugs into a project, and lots of legitimate reasons to want to do so. When you bring together a diverse group of people to discuss a real-world project, there will almost always be some new use cases you hadn't originally thought of.

py-bugger at the sprints

At PyCon US, the main conference runs from Friday through Sunday. There are a few pre-conference events such as tutorials and summits, and there are four days of "sprints" after the main conference. People can choose to stay for one to four days after the main conference and work on open source projects. It's a rare chance to get to work in the same room with other people on an open project, and to work around a significant number of people working on a wide variety of projects. A lot of code gets written during the sprints. But perhaps even more importantly, a lot of conversations take place that tend not to happen when only collaborating remotely.

I stayed for three days of sprints. Most of my focus was on django-simple-deploy, but I also shared that I'd be happy to work on py-bugger with anyone who was interested. I had numerous conversations with people throughout the sprints about py-bugger, which was just as helpful as the open space. The clearest thing that came out of these discussions for me was awareness of tutorials where the focus is on debugging progressively more complex programs. For example, the Rustlings project is a set of exercises that help people learn Rust. py-bugger is quite different than these tutorials, but a tool like py-bugger may make it easier to develop learning tools like this. Even if it turns out not to be helpful in that way, it's clearly part of an ecosystem of tools and projects that bring much stronger pedagogy to the way we teach and learn about debugging.

Conclusions

PyCon is a fantastic immersion into all things Python, and the people who make up the Python community. If you have a project that's in an early phase of development, bringing it to an open space is a great way to get feedback about what people like about the project, and where they'd like to see it go. And aside from code-based projects, open spaces in general are an important part of many conferences. If you're attending a conference, look for the open spaces and check some out.

I'll continue to use py-bugger in the debugging series, and I'll continue to share updates as the project grows overall. It's an interesting tool in teaching and learning debugging, but it's also an interesting window into the Python language overall. Asking the question, "How can I break a project in very specific ways?" leads to lots of insights into the detailed working of the language itself.

Note: If you're interested in trying py-bugger, see the Quick Start guide. If you're interested in contributing, please see the Contributing guide in the official docs.