Mel Chua is a contagiously enthusiastic hacker, writer, and educator with over a decade of teaching and curriculum development experience and a solid track record in leadership positions at Red Hat, One Laptop Per Child, Sugar Labs, Fedora, and other Free, Libre, and Open Source Software (FLOSS) communities. A graduate student at Purdue University, Mel bridges academic research on successful communities with deep personal experience getting her hands dirty building them.
These days, Mel spends most of her time with on open source in education, teaching professors how to teach open source and otherwise working to push patches of successful open source cultural habits around learning and teaching "upstream" to classrooms in academia. In her hypothetically existent amounts of free time, she collects quirky textbooks, works on undergraduate engineering education reform, and plays piano, occasionally at the same time.
Authored Comments
Good point - I should have made that distinction. The original talk was to an audience of developers (I'm an engineer myself), so I had developer documentation in mind; one of my pet peeves in any technical project is how few engineers get their documentation tested by other engineers, then wonder why nobody can interface with or extend their component.
Documenting the purpose of the code and the rationale behind decisions made is also an excellent point. I've seen a lot of young devs join a project and go "Why did they use $technology_foo? They must be idiots; why not $technology_bar - I can rewrite this with $technology_bar in 2 hours!" (or something of the sort), then talk with older devs and learn that the product was written when $technology_bar was unstable, or the customer it was made for insisted on $technology_foo, then demonstrate that $technology_bar crashes after a dozen users and doesn't port to different browsers and is nonextensible, and so forth.
Version control and keeping meeting logs where these sorts of debates and decisions are documented are good ways to help keep track of this, because no, your logic and decision process isn't magically embedded in your code when you check it in.
(For those who don't know: I'm also a Sugar Labs person, as is/was Scott.)
It's a half-implementation of the open source way of doing things that leads to tool-wankery. Since, by open source principles, you can't tell someone else <em>not</em> to use a tool, you'll have dozens of people with dozens of preferred implementations, all with the ability to implement them. Others can try them out, and eventually the best solution will gain more followers (er, ideally). This is good - "those who do, decide."
The community can decide to grant one person (project leader, infrastructure team lead, etc) the power to "bless" an implementation as "the right way," and this is also good. But it is also potentially dangerous - "those who do, decide" can turn into "those who decide, do" - with those leaders choosing an implementation based on personal idiosyncratic preference rather than consensus on the good of the project, not giving other ideas a fighting chance to take root, and making everyone who wants to participate use whatever they decide.
I struggle to articulate this, because both sides of the argument sound entirely reasonable from different perspectives... I think what we may have with SL's infrastructure is a failure to make it easy to fork, which leads to angst and struggles over tool-fu rather than productive work towards SL's core purpose.
But that's the heart of the argument, and I suspect the reason Scott and I feel the way we do - Sugar Labs' core competency is <em>not</em> setting up collaboration infrastructure. Actually, for 99.9999999% of projects and groups out there (open source software or not), the purpose of the project is not to host mailing lists, it's to get <em>something else</em> done (making a software environment for kids, in this case).
So yes. Let someone else do it. Use open tools so that the work that other people do can be modified if needed - but let other people do that work for you.