My Journey to Open-Source Development
Tags: python, webdev, opensource
Published: 2022-07-29 05:49:19

---
title: My Journey to Open-Source Development
published: true
description: How I started as a developer of the Roundup Issue Tracker.
canonical_url: 
cover_image: https://www.roundup-tracker.org/_images/index_logged_out.png?ref=dev.to_1
tags: #python, #webdev, #opensource 
series: Roundup Tracker - notes from an open-source developer
---

Welcome to the first article on the ongoing development of the [Roundup Issue Tracker](https://www.roundup-tracker.org?ref=dev.to_1). Before we get started, a little about me.

I have a B.S. in Physics which included some advanced computer science courses. But, my career ended up in system administration. I have [taught](https://www.usenix.org/legacy/events/lisa09/training/tutonefile.html#s2) and published a [few](https://www.usenix.org/legacy/events/lisa04/tech/full_papers/rouillard/rouillard_html/index.html) peer-reviewed [papers](https://static.usenix.org/publications/library/proceedings/lisa94/rouillard.html) at conferences over the years. Trying to reduce toil and improve operations, lead to my interest in ticketing systems. Tools from LEAN and Six Sigma have proven valuable in analyzing ticketing and real-time logging data.

## Issues Need Tracking
In 2002, I ran a lab that installed a system monitoring solution on Sun computers. We needed to track requests that came to the lab. I evaluated ticketing systems across a few dimensions. The [Roundup Issue Tracker](https://www.roundup-tracker.org?ref=dev.to_1) scored the highest.

Five minutes after downloading the software, I had a classic tracker running in demo mode. After entering a few tickets and adding a few keywords (tags), my co-worker and I decided it could work. It was flexible and looked like we could extend it to support our future growth. Little did I know that this was the start of a 20+ year relationship.

## Roundup Basics
Roundup tracker has two components: the Roundup core and the tracker instance. The core is written in Python. The tracker instance supports one of two HTML templating engines: ([Zope Page Templates](https://pagetemplates.readthedocs.io/en/latest/introduction.html) or [Jinja2](https://palletsprojects.com/p/jinja/)). It is programmed in Python.  The tracker instance controls the look/feel/functionality of the tracker. It:

   * defines the database schema/data model,
   * provides the web interface (with customizable
     HTML and CSS),
   * executes Python code to [validate
     entered data and react](https://www.roundup-tracker.org/docs/customizing.html?ref=dev.to_1#detectors-adding-behaviour-to-your-tracker) to a change
     (e.g. by emailing notification messages),
   * can [hook into the core code](https://www.roundup-tracker.org/docs/customizing.html?ref=dev.to_1#interfaces-py-hooking-into-the-core-of-roundup) to control how the core operates.

One instance of the Roundup core can run many trackers. Each tracker can have a very different presentation and function.

## Getting My Feet Wet
When I started, Roundup was still very new. I started developing my customized tracker to learn Python and experiment with Roundup. My tracker implemented several ideas from [Request Tracker (RT)](https://bestpractical.com/request-tracker/). I developed the key components, [replies/comments](https://rt-wiki.bestpractical.com/wiki/ManualUsingWebInterface#Replying_and_commenting), [dependencies, and grouping (parent/child)](https://rt-wiki.bestpractical.com/wiki/ManualUsingWebInterface#Links), in less than 40 hours of effort over a few weeks. Roundup's implementation and documentation made building these significant features easy.

The other advantage was that Richard Jones, the developer, was in Australia. We set up a "follow the sun" development cycle. I emailed him a problem when I went to bed. By the time I got up the next morning, he would have a fix ready for me to use when I got home after work. This fast feedback is something I try to maintain in the Roundup community.

I never deployed my custom tracker, but the classic tracker worked well for the lab. As a result, the sales engineering group requested (and got) a tracker. After I left the company in 2005, they upgraded the Roundup core and converted the database to MySQL (from a dbm key/value store).

## Back in a More Active Role
My next IT job used Request Tracker. I followed Roundup development but didn't contribute much. In 2012, there was some interest at work in setting up a customer-facing portal based on Roundup. I started development on my tracker again and re-joined the Roundup community. Over the next few years, I developed code to add:

  * a transaction source property for data changes. Makes changes from the web interface but prevents the same change if it originated from (unsigned) email.
  * the filter command to the `roundup-admin` command line interface makes data searching easier.
  * `nofollow` relationships to links which makes Roundup less useful to spammers.
  * [CSRF](https://owasp.org/www-community/attacks/csrf) 
    protection using [synchronizer tokens](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#synchronizer-token-pattern) makes Roundup more secure.

## Releasing Roundup
By 2018, Richard had stepped back, the last release was January 2016. I took over as a lead developer and release engineer. I released version 1.6.0 in July of 2018. This merged several existing patches, cleaning up [Roundup's issue tracker](https://issues.roundup-tracker.org?ref=dev.to_1).

Since 2018, there were two major changes added by other developers:

   * support for both Python 2 and Python 3 (which required a 2.0.0 release)
   * addition of a [REST interface](https://www.roundup-tracker.org/docs/rest.html?ref=dev.to_1)
     beside the [XML-RPC](https://www.roundup-tracker.org/docs/xmlrpc.html?ref=dev.to_1)
     interface

On July 13th, 2022, I made my [fifth annual release](https://sourceforge.net/p/roundup/mailman/roundup-users/thread/20210713043457.083CE6A0022%40pe15.cs.umb.edu/).

Since Roundup deployments are on-prem, I established a yearly release cadence. Other issue trackers have more frequent releases. But, many of those releases address UI or workflow issues. In Roundup these are implemented in the (customized) tracker instance. So the user is not dependent on the fixes pushed from upstream. Each release includes [upgrading instructions](https://www.roundup-tracker.org/docs/upgrading.html?ref=dev.to_1). These instructions can include changes for the tracker instance to bring it up to date.

The slower release cadence has an advantage for the users. It reduces the need to update tracker instances to once a year rather than every few months. However, the yearly cadence results in less public visibility for Roundup.  

I plan more articles on developing and maintaining an open-source application. Some future topics I am considering include (<small>in no particular order</small>):

   * The Customisability Trap
   * Kitchen Sink Development
   * Accessibility
   * Responsive Design
   * The Problem with Selects
   * What?? No Javascript!
   * Docker All the Things
   * Colors and Themes
   * The Bus Factor
   * Evaluating Tracking Software

The [Roundup 20<sup>th</sup> anniversary article on lwn.net](https://lwn.net/Articles/869118/) includes more information on Roundup.

I hope you enjoyed this article. Thanks for reading.