GStreamer, Fluendo and Collabora

10:31 am General, maemo

I tagged an announcement by Collabora that they were hiring Christian, Edward and Wim from GStreamer, formerly of Fluendo, with the comment “Is this how Free Software acquisitions work?”

That got some response in the comments, and especially from Julien Moutte, CEO of Fluendo.

First, let me say that I wish the project well. I’m convinced that GStreamer is a core part of Collabora’s activity, and that GStreamer consultancy will make up a decent chunk of revenue for them. I also expect that Fluendo will continue to invest in a core technology that they depend on for their growing range of products, and that others depending on GStreamer such as Nokia will continue to support and encourage its development.

Julien confirms that Fluendo are continuing investment in GStreamer (great!), and affirms that all of a sudden, it’s just become a much more open project, since people are spread across many companies.

I hope that’s the case, but it’s not an automatic consequence of a few people leaving. Project governance is much more complicated than who employs the N most active hackers.

In the past, there has been rumblings that decisions affecting the project were being made in private in Barcelona, and then discovered by the community (see comment on GStreamer design – I remember other similar comments, but can’t find them right now).

GStreamer’s not alone in this – pretty much every project with one primary company sponsor/owner runs into the problem (OOo, Java, Mozilla, Evolution, and yes, even OpenWengo come to mind). The results are that company employees feel frustrated that they’re not getting community traction, and the community is frustrated because they have a feeling the company is looking for cheap labour to implement its agenda, rather than equal partners.

Whether GStreamer in particular becomes a more open project depends, now, on the governance model that is put in place. A model can be informal and ad-hoc, as long as it’s efective. Who gets to say what goes into the main tree? What’s the patch review process? Who are the core developers who can just commit? If those processes aren’t in place, or if one company controls all of the processes, then you will continue to see the kinds of problems which OpenOffice is currently seeing, even if there are many companies and individuals bearing the burden of development.

3 Responses

  1. Ludovic Says:

    Just thinking out loud …
    Christian, Edward and Wim are commiters to GStreamer I think. And Wim is even maintener so I don’t see your point.
    And comparing to OOo situation might be a bit far streched, don’t you think ?

    Or maybe I’m missing som informations. Have the commiting rights of Christian, Edward and Wim been revoked ? Or do I misread you and you just want more formal policies to be discussed ?

    Could you elaborate please as I fail to see the point here.
    I’m not being ironic here or provocative, just would like to understand the problem better.

    Thanks.

  2. Stéphane Loeuillet Says:

    Julien Moutte, he’s not a bird 😉 (mouette)

  3. Tim Müller Says:

    Dave, I can’t say I really understand what your concerns are exactly, but whatever they are they seem to stem from a misconception of the GStreamer project, the people involved and the wider community around it.

    The comparison with OpenOffice in particular doesn’t hold water in my book. GStreamer has been an open-source/free software project from the start with developers firmly rooted in various other communities; it is not released by a company, nor are there versions of it with different licenses; and no copyright assignment is required either. I’m also not aware of any “company employees feel[ing] frustrated that they’re not getting community traction”, or of “community [members being] frustrated because they have [the] feeling [a] company is looking for cheap labour to implement its agenda”.

    I think most, if not all, GStreamer developers would regard themselves as ‘well-embedded’ members of the GNOME, KDE, freedesktop, Linux, GNU, or whatever community.

    I also like to think that decision-making within the GStreamer project is fairly transparent and either done on the mailing list, in bugzilla or on IRC, with decisions being made on technical basis. I don’t see any of this changing in future either.

    This is not to say that everything’s perfect in the Kingdom of GStreamer; of course there are always time constraints, so patches don’t get reviewed as quickly as they should, bugs fixed as quickly as they should, or new features implemented as quickly as we’d like to, but I don’t see this as having a lot to do with who’s working for which company, and I don’t think GStreamer is faring much worse in this respect than other big projects like, say, Gtk+. If anything, the situation will only get better with more companies involved, since there’ll (hopefully) be more eyes and hands working on the GStreamer codebase.

    Just to make sure this is clear: we’ll certainly continue to develop, debug, fix and maintain GStreamer in much the same way that we did before, and our continuing activity in CVS, bugzilla, IRC and the mailing list hopefully demonstrates this.

    In short: if you have any particular gripes with the current decision-making process in GStreamer, or the transparency of it, I’d really like to know about it (and so would most of the other GStreamer developers I presume). If not, well, then I still don’t really know what your blog was about. (Disclaimer: it’s late)

Leave a Comment

Your comment

You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Please note: Comment moderation is enabled and may delay your comment. There is no need to resubmit your comment.