Mark Shuttleworth Keynote at Linux Collaboration Summit

I'll skip Mark's intro - he's easy to google (Thawte, Verisign, Space Shuttle, Ubuntu).  He gets the keynote address at the LF Collaboration Summit.



How to collaborate.  Non-traditional folks are starting to hear about Open Source software.  But headlines come from "contests of will" such as Red Hat vs. Novell, MS vs. Ubuntu, etc.  However, innovation works better when people are inspired, when they have an itch to scratch, and you provide an environment for them to scratch their itch.



Community requsts:  pass stuff upstream.  Distro:  we didn't know where to send it (not all projects are well maintained).



Loudest ideas tend to bubble up, look to talk on Poisonous people, how to make sure best ideas win, as opposed to loudest ideas.  We have lots of collaboration tools - wikis, mailing lists, etc, which focus on collaboration within a project.  However, collaboration between projects is weaker.  Translations rarely move upstream.  Can distros create a "star topology" for passing fixes between distros, thus facilitating upstream adoption.



(Battery dying here, time to swtich).



Back now - Mark has been talking about Federating our interactions, with a focus on several facts, including multiple distributions working on the same projects, with similar inputs/bugs/needs, developers working cross projects, e.g. accessibility and translation being places where non-experts contribute to many projects, so many projects on different schedules being collated into distributions, bugs spanning multiple products for a single user-experience flaw, etc.  Mark used the example that creating an account on every bugzilla, sourceforge site, etc. would be prohibitive for any individual who just wanted to contribute translations, for instance.  The model today dos not span multiple projects, although the collaboration models work quite well within individual projects.



Ubuntu used Mozilla and Gnome as models (Mozilla - roadmapping; Gnome, committment to release cycles) as influences.  Each feature develops a micro-community, a branch, etc. in some projects which seems to work well.  IETF has a similar model for creating an idea and building a consensus around that idea.  How do we generally lower the barriers around development and contribution?  Why can't people do an apt-get of the source of a project, create a branch, allowing everyone to develop like the core developers, being able to easily contribute changes back to where they can be reviewed, integrated, etc.



Ubuntu uses bazaar (a brach of arch) for source control.  Matt Mackall has convinced them to look at Mercurial, Git is fairly common, Mark mentioned a couple of others.  However, each source control system raises the barrier for participation by the average developer.  His major point seems to be to advocate a standard mechanism for bug tracking, source management, etc., not by having everyone use the exact same tool set, but instead defining some basing API's etc.



In conclusion, Mark encourages greater collaboration across projects (and no, I didn't state this as well as he did, sigh).  But I, for one, agree.

Powered by ScribeFire.