veyepar: Deciding between continuity and change in your Open Source community

Author(s):	Christopher Neugebauer
Location	Room 104
Date	aug Sun 14	Days Raw Files
Start	11:50	First Raw Start	error-in-template
Duration	0:30:00	Offset	None
End	12:20	Last Raw End
Chapters
Total cuts_time	None min.

https://2016.pycon-au.org/schedule/153/view_talk
raw-playlist raw-mp4-playlist encoded-files-playlist mp4 svg png

assets release.pdf Deciding_between_continuity_and_change_in_your_Open_Source_community.json
logs
Admin: episode episode list cut list raw files day marks day marks day image_files

State:

Locked:

clear this to unlock

Locked by:

user/process that locked.

Start:

initially scheduled time from master, adjusted to match reality

Duration:

length in hh:mm:ss

Name:

Video Title (shows in video search results)

Emails:

email(s) of the presenter(s)

Released:

has someone authorised pubication

Normalise:

Channelcopy:

m=mono, 01=copy left to right, 10=right to left, 00=ignore.

Thumbnail:

filename.png

Description:

markdown

When you’re a big, for-profit project, it can be easy to justify a change from outdated software to the new hotness: figure out why the old software isn’t working for you, do a cost-benefit analysis, and – if it still seems like a good idea – make the change.
When you’re a community of volunteers, that justification can be less clear: cost-benefit analyses will rarely be about money. Worse still, the human costs can be difficult to justify: It’s difficult to get volunteers to do more unpaid work than they’re already doing. If your community depends on Open Source software, you get the added political difficulty of needing to navigate the divide between large-scale change and making small improvements to systems your community actively contributes to.
Whilst the motivation might be different, the process isn’t: leading a community towards change means understanding why existing systems aren’t suitable, making your community enthusiastic about the need for change, and then actually making that change.
To help make this point more concretely, we’ll look at how and why linux.conf.au – a long-running Open Source conference in Australia – effected a move away away from a bespoke legacy conference management software to one based on Symposion, the popular Django-based software created for the Python Software Foundation. We’ll also look at how that’s led to the PSF funding Registrasion, a Django-based conference sales platform.
With this case study as a guide, we’ll talk about how to make a decision to replace the software that your community runs on. In particular, we’ll cover how to identify and engage with stakeholders within a community; the value of prototypes in maintaining interest; and what a cost-benefit analysis might look like when your currencies are human joy, and burnout prevention.

Comment:

production notes