When we started planning for PgConf US 2017, we knew there would have to be some changes. The conference is the fastest growing and largest PostgreSQL conference in North America. Our requirements have changed, the needs of our attendees have matured, and the overhead in running the conference is growing.
We looked at our infrastructure and the website software used to manage the conference. Like most homegrown community conferences organized by software people, we built our own and it was showing its age. It lacked a lot of essential features (namely scheduling but also others).
Like any good project we started laying down requirements:
- Must be able to use PostgreSQL as the database
This should be obvious. If it isn't, I am not sure what else to say.
- Preferably written in Python/Django
This was my personal bent as I am a Python advocate over other scripted languages but there was also the fact that a good deal of the .Org and .EU infrastructure is Python/Django based.
Again, this should be obvious.
- Must have a developer community
There is a key difference between the developer community and the user community. It is developers that make software. We needed to make sure that the piece of software we adopted to organize PgConfUS was not developed in a silo.
This is exceedingly important when considering the long term strategic view. The more time we spend updating code, modifying code, pushing patches, agreeing on features, and dealing with all the various adventures of open source development, is more time we spend away from organizing PgConf US for the PostgreSQL community. We do not want to invent another wheel. We want to use an already well manufactured wheel. That is not to say we can't do web application development; it is to say it is not a productive use of our time. In this context, we are conference organizers and we should be focusing on producing the most electrifying PostgreSQL Conference in the PostgreSQL community today.
- Must have a user community
The user community is just as important as the developer community. If you have a robust developer community but no users, what is the point?
One of the hardest parts of running a multi-track conference is scheduling. It takes up a lot of time and coffee. It increases silver hair (I have enough, thank you) and sometimes makes the conference feel like it isn't worth the effort.
- Must have ticketing/registration
PgConf US uses EventBrite. EventBrite is a fantastic service but it is a dependency that complicates matters. An inclusive system that allows us more flexibility and usability was key. By having integrated ticketing and registration we will be able to reduce costs to our attendees and reduce the overhead incurred by the organizers.
With the requirements set, we started reviewing a number of open source conference platforms including:
- Multiple versions of Pinax/Symposion
- Software used by DjangoCon (various versions)
- Software used by PostgresOpen and PgConf.EU
- Indico (IETF)
- COD (LinuxFestNW)
- OSEM (OpenSUSE, GNOME, OwnCloud)
The first three are Django/Python based. Indico is Python/Flask, COD is Drupal, and OSEM is Ruby on Rails. It was my absolute hope that one of the first three would qualify for our requirements. They simply did not. As with many open source software projects, they did not meet the usability requirements nor appear to have a user or developer community outside of their respective conferences.
Indico is a fantastic piece of software but it is overkill for what we wanted. In an effort to give a well rounded review we also looked at COD and OSEM. COD in a similar fashion to Indico is overkill for our needs and overly complicated to manage. OSEM was referred to us by OpenSUSE.
In the end we chose OSEM because outside of the language/framework it met our requirements. That isn't to say OSEM is perfect. It isn't. We had to add some functionality and fix bugs but as a whole it provides a much better experience than any other option we reviewed, including:
- Multiple event management and event within event management
- Media management (integration with Vimeo/Youtube)
- Simple sponsor management
- Awesome scheduling (once we fixed a few bugs)
- Track management
- User management
- Analytics
- Tickets/Payments
- Extensibility
Outside of the clear usability advantages that OSEM has, it also has a solid and responsive developer community with standard communication channels (email list, irc channel, public repo etc...). It is also in use by communities that dwarf ours in terms of users, which lends itself to stability and a continued desire to improve!
Before you ask, yes we have pushed or are pushing all of our fixes and enhancements to the OSEM community, with some already accepted (postgresql support etc...).
