FOSDEM 2011: Saturday

In advance of FOSDEM 2012, I’m publishing previous years’ notes. Here’s 2011 day one: Saturday.

FOSDEM is the Free and Open Source Software Developers’ European Meeting, an annual free event hosted in Brussels and entirely organised and run by volunteers. Typically around 5-6000 developers attend. The event is run over a weekend, with a networking beer event the Friday beforehand. This year around 1500 people showed up for the beer, according to the estimates of the security staff.

The event comprises a number of keynotes and multiple parallel tracks of volunteer talks. 2011’s main tracks were:

  • System
  • Web Browsing
  • Languages
  • Web Frameworks
  • Cloud
  • Office
  • Lightning talks
  • Developer Rooms – BSD, Cross Distribution, Cross Desktop, Data Analytics, Embedded, Free Java, GNU, Jabber and XMPP, Mono, Mozilla, MySQL and friends, Security and hardware crypto, World of GNUStep, Accessibility, Configuration and Systems Management, LibreOffice, Virtualisation, Open Source Telephony, Perl, PostgreSQL.

Some thoughts from the event overall:

  • Attendance
    • Attendance once again seemed higher than previous years, with a broad mix of attendees in terms of age, profession, geography, language.
    • Many businesses as well as projects now count FOSDEM as a “must attend” event.
  • “Android is a bucket of arse” / “has anyone noticed the only Android talk is about setting it free?” / “Google’s Android is not the perfect embedded OS”
    • The general mood amongst delegates is that Android is an appalling technical implementation, and very few seemed interested in developing for the platform. This was in stark contrast to the level of interest in Linaro and MeeGo.
  • WebOS has problems too
    • Even though Palm WebOS is widely admired by the community, apparently HP has spent the last year since acquisition dealing with licence compliance issues.
  • Consolidation
    • Previous years have seen rooms devoted to specific distributions and specific desktop software. This year all the distributions were in one room and the theme was typically how to work together and on cross-distribution packaging initiatives. All the desktops shared talks on important cross-desktop key components.
  • Device fashion
    • Despite being superseded in the marketplace, the Nokia N900 was still an extremely popular device at FOSDEM. Second most common device sighted was the G1, followed by a range of Android and iPhone models.
    • Some delegates had a range of tablet devices, but these were still very few compared to laptops and netbooks. The most common laptops were Apple Macbooks and Macbook Pros, many of which were running linux.
  • Trends
    • There is an increased interest in the embedded end of the market with more talks and also large crowds around the embedded/beagleboard stands.
    • Firefox and HTML5 seemed significantly more popular this year, and there continues to be notably few talks about WebKit/Chrome.
    • Last year’s buzzword NoSQL has been superseded this year by “big data”.

Some of the talks attended:

Lightning Talk: Is the UK Government backing free software?

Two reasons for attending this talk: firstly, it’s a useful barometer for the acceptance level of open source in general and the progress of open source in large organisations. Secondly, I’ve worked with Sirius on rolling out infrastructure, so it’s good to keep tabs on what else they are doing.

There were about 200 people in the auditorium for the lightning talks. This talk started by pointing out that despite many open source policies and statements of support, the government has never implemented open source to any great degree. The last Labour government were very pro-business, typically favouring large multinationals, and so vendor lock-in through proprietary formats prevented any real adoption of open source.

The civil service typically work with and are supplied by large system integrators who historically have not been open source friendly.

The new administration is taking a top-down approach to driving change and wider adoption of open source. Examples of this include an SME Summit at the Treasury on 11th February 2011, and an Open Source supplier forum on 21st February 2011 where all open source suppliers will be present.

In addition, Bristol City Council are conducting research using a large system integrator paired with a small open source company (Sirius), and Cardiff council are running a series of workshops amongst key stakeholders, facilitated by Sirius, to explore options for using open source.

I wanted to get into the Firefox talks next, but the room was full (standing room only, no-one else allowed in for health and safety reasons).

How to be a good downstream

FOSDEM how to be a good downstream

Reason for attending this talk: I’ve seen first-hand the very real economic and technical problems with the way large mobile platforms relate to upstream projects, in that code is often forked and patched and rarely contributed back, providing both an economic burden of maintenance and technical difficulties in backporting bug fixes and enhancements. It was hoped that by attending this talk key remediation strategies might be identified.

There were about 50 people in this talk. This talk was given by noted Debian developer Thomas Weber, and was subtitled “How to make both your and upstream’s life easier”. It was a follow-up to last year’s talk “How to be a good upstream”.

Key points that need to be remembered:

Communication

  • when you make some specific changes, discuss with upstream what changes were made and why
  • being pro-active is key

Empathy

  • Different people/projects have different goals and constraints
  • Remember that upstream is busy too
  • if you forward bugs, include all necessary information in the bug report – don’t force upstream to use your bug tracking system
  • do not propose unscalable solutions eg. “upstream can subscribe to my distribution’s bug tracking system” : Debian alone has 120+ derivatives

Packaging (initially and ongoing)

  • Introduce yourself – so upstream knows about the package and has a point of contact
  • Keep in contact with upstream and ensure they understand that you are packaging for a distribution
  • Take a look at upstreams bug tracking system before your own release
  • If you leave or stop packaging inform upstream!

Example: xdebug 2.0 bug fixed in 2.1 Aug 2009; first stable was june 2010, in Ubuntu 10.04 LTS it’s still not fixed.

Cooperative work

  • Forward patches (ideally before applying them)
  • Be present on upstream’s communication channels
  • Intercept the questions of the users of your distribution (you know the details of your distribution far better than upstream). This generates good karma.

Key takeaways: mobile platforms don’t always do this. They should all consider identifying their upstream projects, identify all their modifications made against upstream, do an audit of their releases against upstream bug trackers, and introduce their maintainers to all the upstream projects.

Swimming upstream

FOSDEM swimming upstream

There were about 75 people in this talk. This talk started with a quick survey of the audience: the audience were geographically well-distributed, some had travelled 1000+ miles to attend. 80% of the audience don’t speak english as their first language, and no-one in room has been using linux for less than 2 years – most have been using it for more than 10 years.

Jared asked “does innovation happen in a conference room?”, and then proceeded with an analogy of why salmon swim upstream and why contributors should push their code upstream. He used another analogy of how multiple streams form a river to describe how “code starts out as 1 or 2 people working together then it forms a larger community”.

What is a community? It is the relationship of people with shared goals and common interests. With a software community: what is the difference between people working on same piece of software and a software community? A software community is a table – where people with different backgrounds, experiences, goals can come together and have healthy discussions. Sometimes they talk more about the process of the table itself!

What is a distribution? It is a bundling of software. When Fedora started, they didn’t want to push upstream – but this approach didn’t work as it became impossible to maintain the platform. Fedora now push upstream aggressively to carry as few custom patches as possible.

Upstream -> Fedora -> Redhat Enterprise Linux

“people take pride in working with open source, contributing to something bigger than themselves”

Key takeaways: Fedora, a relatively large and well-supported open source linux distribution, were unable to handle the burden of maintaining the platform without pushing upstream. Mobile platforms should learn from this experience and understand that it is not possible for them alone to support a forked platform.

Downstream Packaging collaboration

FOSDEM downstream packaging

This talk suffered from poor audio, starting too early whilst people were still arriving, and people were talking over the introduction.

The speaker started off with the premise that packaging an open source project is easy, but modifying it (patching) to fit the distribution’s requirements is hard due to the maintenance burden incurred by patches.

The obvious answer is to get the patches upstream as soon as possible, but this is not always possible as some open source projects have missing maintainers or are unresponsive to distribution contributions.

A workaround is for distributions to work together to form a new upstream, but maintaining a new upstream is hard.

One suggestion was to create canonical-package-name-maintainers@distros.freedesktop.org and then subscribe the email address to per distribution package VCS commit mails.

Question: how many examples of upstream abandonment? Several key ones: X11R3, X11R4, lesstif, nedit. Most niche packages, but still with a significant number of users.

FOSDEM patch sharing

The second part of the talk focussed on patch sharing:

  • store all downstream patches at same place
  • give write access to maintainers
  • read to everybody
  • let maintainers collaborate

Advantages: differences are more obvious, one patch can be used for multiple versions.

Whenever someone creates a new patch:

  • push into common repo
  • all maintainers will know shortly
  • know whether it is distro-specific
  • know what it does
  • know when it get upstreamed
  • know about fixes
  • can incorporate it
  • can help cleaning it up
  • can help pushing it upstream

cf. openembedded:

  • one repo with recipes and patches for software
  • everyone works together (even on packaging)
  • only differences are marked

patch conventions – easily parseable metadata:

  • upstream package name and version
  • maintainer (for patch)
  • strip level (-p prefer)
  • list of bugs
  • description
  • status (quick hack, send to upstream, upstreamed)
  • distributions included in

Start with debian patch policy. Other key links:

Bdale Garbee summed it up best: “if you maintain a piece of software for a particular distribution and you don’t know the maintainers from other distributions, you are failing”.

Key takeaways for mobile linux platforms: maybe they should be a patch farm against an existing distribution, rather than a platform in their own right. They could sponsor work toward a common patch store, by helping developers get together to talk about it and plan it. This would help them by mitigating their maintenance burden.

E17

FOSDEM enlightenment

Samsung have a high level of investment in Enlightenment technologies, having hired the principle developer. This talk is therefore critical to understanding the core graphics in Samsung’s Linux platform. There were around 100 people in the room for this talk.

e16 was released in 1997, and e17 has been in development for over a decade. Embedded devices are the main target and e17 has been rewritten from scratch based on e16 experience.

Enlightenment is a lightweight desktop environment based around EFL – Enlightenment Foundation Libraries. Enlightenment takes care of the current layout. All features or gadgets on the desktop are a module – so you can unload them. An e17 desktop consists of a set of modules loaded – a profile. A default basic profile is defined for different use cases. e17 is totally modular so you can load only what you want to use.

e17 supports themes. With edje everything can be themed. There’s only one file to download for the whole theme.

e17 has full compositing support.

e17 is opengl and opengl-es compliant. If the platform has bad graphics drivers it can switch to software engine.

e17 supports textures from pixmaps and indirect rendering.

e17 works on desktop and embedded.

The gui: there is a basic toolkit, there is no complete toolkit, just basic widgets (button, list, scroller…) and some tools to make life easier for coders (for example dbus bridge). You use ecore and evas to create windows. You use edje to create a new widget.

The future: Release. Maintain compatibility.

In e18 the plan is to integrate a complete toolkit for widgets.

Questions from the audience:

  • Do you have a release date?
    • “no”
  • what is the footprint?
    • Around 40mb? 30mb? (the second e17 talk stated around 24mb)

The Enlightenment stand at FOSDEM also had e17 running on a range of devices including what looked like an HTC phone and a Samsung Galaxy Tab.

Key takeaways: there is a fair amount of developer interest in e17, but despite a very long development cycle it still seems relatively incomplete. However, the minimal footprint, embedded target and eye candy focus might provide a more consistent user experience closer to iPhone than it is possible to provide using GTK or Android graphics.

Open Sourcing Java

This talk was given by former Sun Chief Open Source Officer Simon Phipps. It was very well attended with approximately 200 people in the room and a long queue of people unable to get in.

Governance

Sun nearly broke opensolaris with heavy governance. They learnt from that lesson and with OpenJDK they took action first, open sourcing the platform and then wrote the governance after the fact. Another key lesson is that setting up an open source foundation does not fix anything – it is important to make the open source platform work first.

All community members matter

  • it’s a mistake to assume a competitor can’t help
  • there are approximately zero people who show up just to break things
  • the rules you make to control those zero people break things worse than the zero people do

Real relationships help and heal

  • written communications only support existing relationships
  • second languages affect understanding (easy to believe you mean what you say – but you only use the words you know) (saying “I’m not a native English speaker” is a great way to excuse almost anything else you say)
  • old hurts can be cured by positive healing (have breakfast lunch and dinner with people you don’t agree with)

training reptiles takes time (corporations are reptiles)

  • corporations don’t exist, people do (you can’t trust a corporation)
  • confronting corporate problems rarely works (no point going to MS and telling them patents are evil)
  • solutions need to layer and build over time – create habits not traps (gradually change the environment)

Open source isn’t about licenses or code – it’s about a certain set of liberties. Software freedom has to be the guiding principle in what you do.

Software Business Value is the first derivative of Software Freedom

  • Ability to share code -> grows user base
  • Ability to study code -> developers not needing training
  • Ability to modify code -> ecosystem of companies
  • Adopting posture of freedom is not delivering freedom

Pragmatic compromise to achieve larger goal can be acceptable

  • contributor agreement
  • assembly exception to allow mixed licensing

Licenses are constitutions for communities

  • licenses normally bilateral agreements
  • open source licenses are multilateral circle around the community that defines the boundary.

The fact that java wasn’t open sourced in 2003 and packaged in a usable fashion on linux meant it lost a huge amount of momentum.

Why was apache license not chosen? BSD/Apache/GPL were all considered. Apache patent grants and lack of contribute-back would have removed commercial incentives to collaborate. BSD/MIT don’t convey patent grants in any concrete way, so could have been an option.

Bdale commented that it’s a balancing act that GPL represents between conveying rights and ensuring everoyone plays openly.

The most important thing Sun ever did to get Java adopted was not licensing under GPL but sending Tom to debconf to make debian packages. This made the JDK a second class citizen and not a third class citizen.

Key takeaways: companies must work together across commercial boundaries. Foundations / holding organisations should lighten up on governance and focus on software freedom and deriving value from building the platform. Making the platform usable is critical to widespread adoption.

Simon’s slides: Lessons I learned liberating Java

 

 

This entry was posted in Computing, Mobile Tech, Planet, Research and tagged , , , , , , , , , , , , , , , , , , , . Bookmark the permalink.

Comments are closed.