FOSDEM 2017 From the community devroom

A few weeks ago I happily went off to FOSDEM. Saturday I caught up with people, Sunday I spent most of the day in the incredibly busy Community devroom - right until I had to give up my seat for food. I really enjoyed the talks and hope the track manages to get a bigger devroom next year, dozens of people had to be kept out after every session ended (fire safety regulations).

Most talks lasted about 30mn and the videos should be available on the FOSDEM website. Here are some of the highlights from my perspective and notes.

Closing Loops (Greg Sutcliffe)

Link to talk

This talk was more about raising questions and figuring out best practices based on audience participation rather than offering The One Solution. In this context, a "loop" means an RFC still undecided, a discussion dying out, patches unreviewed. How do you decide when a topic has come to a conclusion?

It's important to remember that everybody has the best interests of the project at heart, this is more about blaming the systems we use.

Say, in a Request For Comments discussing significant changes on a mailing list, the discussion tends to peter out after a while, and it can be difficult to track how a proposal evolved. Foreman (Greg's project) decided to move the discussions to an RFC repository instead, but 6 months later it seems to have only moved the problem.

From the audience:

  • For Debian, the discussion ends "when someone starts the work" :)
  • LibreOffice has a "technical council" type meeting/discussion with about 40 people, on the phone. A wiki documents the process to join.
  • In the PHP world, the RFC author gets to choose when to call a vote and the deadline for it (at least 2 weeks ahead). Greg wondered if that might get divisive if there are too many 50/50 situations, but the audience member indicated that it wasn't the case, because most problems get solved during the discussions that precede the vote so they are usually overwhelmingly accepted. Every contributor gets a vote from a certain contribution threshold.

The speaker seemed interested in trying out the technical council direction for his project.

Data science for community management (Manrique Lopez)

Link to talk

Communities need to have a common vision and self-awareness to see if they are walking toward it: what kind of people are part of the community, what are they doing... This helps with governance and transparency (fairness, trust).

What is the role of a community manager? Do communities even need to be managed? "Manage" is a strong word.

A community manager is interested in keeping their community alive, active, and productive. Having visibility into community health is important. There are a lot of tools out there with data relevant to this: JIRA, git, IRC, slack, StackOverflow, ... A lot of places, which individually are only one part of the bigger picture.

Rather than cobling a bunch of scripts together to get to all that data, GrimoireLab does all the work for you and presents it nicely using graphs. One example was the "Pony Factor," which I hadn't heard of: who's doing 50% of the commits? For example in the kernel, the pony factor is about 200 people/10 companies. That's a lot of people!

When you have that data you can see the evolution of the project over time: reviews, gender, demography, pony factor, etc, etc. Cauldron.io, in beta, lets you try it out for free for up to 5 Github organisations.

Getting your issues fixed (Tomer Brisker)

Link to talk

I think anyone trying to get help or start contributing as a user to an open-source project needs to watch this. Tomer summarised a ton of best practices that experienced open-source people "just know" and would likely never think to document.

A super rough summary:

  • Try to ask for help on IRC
  • Try the mailing list. If no one replies and you solve it yourself or find a workaround later, please self-reply. (Mandatory xkcd link)
  • Search the bug tracker. If there is a bug, add your input, your use case. If there are none, create a new issue and include as much information as possible: traces, logs, version (including of the plugin if relevant), screenshots... Anything to help the developers reproduce the issue. If this is a feature request, explain your use case.

Patches:

  • Tabs vs spaces: follow the coding guidelines for the project. If there aren't any follow the standards and conventions of the existing code base.
  • Make the commit message good. Explain "why" as completely as possible. Apparently Github even lets you include screenshots, so that the patch can be reviewed without having to pull the code. "Why" did you do it this way and not another way, explained in such a way people in the future can understand the decision.
  • Include tests. This protects against regressions, so that you don't have to fix the same bug two releases later.
  • Be kind. We're building a community. No one wants to be shouted at. Be patient.

Handle conflict, like a boss! (Deb Nicholson)

Link to talk

Conflicts often come from a piece of information that is missing. Conflict is natural. If you don't handle it, it will come back worse.

How do we minimise it? Try to understand the other people, where they're coming from.

For example:

  • Passion. When people get so excited about something they forget why they're doing it. Mismatched goals.
  • Identity. When someone's identity is linked to a task, not a goal. For example, the person known to be super helpful with wrangling the complex bug tracker, who'll end up sad when you finally upgrade to something better.

Don't leave conflict unattended or you'll end up in a snake pit. You don't owe your mental health to any FOSS project.

There are 3 styles of handling conflict. We tend to use them all, depending on the circumstances.

  • Avoidance. This is not good in a project! It festers. It looks like you don't care, like you're not connected to the community and its concerns.
  • Accommodation. Doing stuff you don't really want to in order to keep the group happy. For bigger issues it can make it look like you don't mind the way things are going. It works for small things.
  • Assertion. Can also be called Aggression. Name calling, etc. Not a good strategy. It wears out other contributors.

Conversations happen in many places. Document the decisions so that it doesn't feel like they're coming out of nowhere.

If you notice in passing a problem in the community you're probably missing some information. Gather more info in order to understand the source of conflict: misunderstanding goals, stepping on toes (e.g. that person always writes the release notes but someone else went ahead and did it this time instead, without asking), ... Is it new members clashing with the old ones? Go back to the historical vision, step out of the tactical discussion. Are there sekrit goals underway? For example a motivation you're not aware of, someone with different goals for their participation like a new job or internal deadlines...

If the conflict is based on fear, it can be harder to get at, e.g. someone afraid they can't learn a new skill if switching language. Create a back channel where it's safe to discuss, to try to deal with it.

Planning for future conflict:

  • Assume the best.
  • Have a code of conduct. Set expectations.
  • No name calling/ad hominem, only discuss technical merits.
  • Set an example.

We could do so much more in the FOSS world if we didn't spend so much time slagging each other :)

Some references:

Mentoring 101 (Brian Proffitt)

Link to talk

This was a lively talk on both formal mentoring via programs such as the Google Summer of Code as well as daily mentoring.

Onboarding is important. This is not just about keeping people in but helping people get in.

As software project, should you want to participate in formal mentoring: have a plan. Formal programs have their own rules and structure.

As a participant, be a member of the community, pick a project that interests you. Be ready to commit. Be flexible - it takes time but is rewarding. Be ready to ask for help.

Undermentoring is a problem. Have clear, set goals for the mentee. Keep an eye on them while also giving them space.

Issue with mentees disappearing... They really should keep a line of communication open, even if only to say, "sorry, I cant' participate anymore." (From personal experience mentoring, this is quite stressful and it was a relief when the mentee admitted they could no longer participate.) You need to proactively mentor to avoid this.

  • Be consistent. E.g. your style may be authoritative (do it this way), democratic (collaboration) or coaching (guidance). Stick to one. (...with Brian noting that the last one is best for mentoring!)
  • Set expectations. Make sure the goals are aligned, define the process, avoid confusion.
  • Take an interest in the mentee. Listen actively. Build a relationship. Learn their style. Don't be a stalker though.
  • Wait before giving advice. It's easy to try to fix things when someone comes at you with a problem. You might be able to solve it but that won't help them. Hit the pause button. Ask more question, get to the heart, guide them to the solution. It takes time. You may not solve the problem. As long as it's not time-sensitive that's ok.
  • Don't assume anything. Avoid stereotypes. Learn the details of a situation. Emphasise communication.

Remember this one thing: they aren't you!! Understand the mentee. This is not only about getting the project done.

A question from the audience was, how can I help my mentor as a mentee? Once again it's about being proactive: this is what I want to do, how do you help me do this? If it isn't working, reconsider the relationship.

How to recruit mentors? Some projects are easier to get in than others. In oVirt, there's a separate mailing list and no formal process. Spread the word, see who's interested. What about a project where there's a lot of mentees yet no one ever answers the call for mentors? If this is part of a corporate project, a solution could be to make it part of the job.

Impromptu community talk

One of the talks was cancelled, so a couple of people started a conversation around community and community events (too many pizzas, too much alcohol is the feedback I remember from that part).

The need for "cruel empathy" was brought up: sometimes meeting organisers should be jerks for good reasons. Loud, demeaning people are toxic and need to be called out. Tell them, in private: "I appreciate that you're here, etc, but you're sucking air out of the community." They may not realise they are doing it, so be nice about it.

The Shotwell community was brought up as one with great first contact.

Overcoming culture clash (Dave Neary)

Link to talk

This was a very interesting talk, mainly summarising information and graphs from books, which I'm going to list here. And hopefully read soon!

Basically a lot of what we do and how we interpret things depends on our upbringing (country, culture, ...)

  • The Tragedy of the Commons - Garret Hardin.
  • Moral Tribes - Joshua Greene.
  • Culture and Organizations - Geert Hofstede. That one brings up 6 dimensions of culture, for example tending to be uncomfortable with silence and filling it instantly, vs. leaving a couple seconds pause to make sure the person is finished.
  • Getting to Yes - Roger Fish. This is more psychology-based than about hard negotiation.

There are no easy solutions. Focus on the relationship. Take small steps: one conversation at a time. Encourage local user groups - though keep them connected e.g. via sending mentors/leaders to these meetups to avoid silos. Have short mentoring programs. Learn about the cultural norms and sensitivity of the community. Avoid real-time meetings.

I contributed! But what now? (Bee Padalkar)

Link to talk

Based on the Fedora community, this talk was about improving contributor retention rates by finding patterns about successful contributors.

Why do people stay? According to a survey they ran, usually thanks to the strong, positive and inclusive community. Other reasons were identifying with the Fedora foundations (core values), giving back, constantly learning.

No matter how interesting the project is, if the community is poor people don't stick around.

  • Have a defined onboarding process.
  • Encourage people to speak up.
  • Assign action items early on, to create a sense of responsibility.
  • Let people know they are doing good work, give feedback (e.g. IRC karma).
  • Use inclusive and motivating language.
  • Encourage attending events to meet people in person.
  • Encourage consistency over activity. Let people contribute according to their own time.
  • Inspire, interact, give feedback.
  • Help people identify with your mission.

~

Looking forward to next year's event!

Leave a comment

FOSDEM 2015

FOSDEM logo

Last week-end I attended FOSDEM for the 7th time. It's kinda strange to say and think - if someone tells me they've been going to this or that open-source conference for 7 years I tend to assume they're hardcore and totally know what they're doing. I go to hang out with cool folks and learn new things. This year's FOSDEM didn't disappoint in that regard!

As usual, the conference was packed and most rooms filled up quickly, but I was happily surprised to see it was still possible to squeeze in some of the more popular rooms regardless. I think many devrooms organisers are well aware of the frustration with not being able to get in and they did a great job at encouraging/demanding folks use all seats rather than leave spaces in the middle, which really helped (special kudos to the Legal devroom, which was in a smaller room in H). Also the main conference organisers appear quite good at trying to adjust the room size based on popularity year to year (e.g. the Mozilla room used to be utterly impossible to get into).

Some of the conference highlights from my perspective:

Identity Crisis: Are we who we say we are?

This was the first keynote on Saturday morning, which I think did a good job of bringing up many possible ambiguities hidden in the "we" we use when contributing to a project. One of the strengths of open-source is that we're quick to say "we" and include everyone, but sometimes it bears more thinking or clarification of who we actually mean with "we" - sometimes two "we" can describe different subgroups of contributors even in the same sentence. Taking the time to think explicitly about who we mean, and avoid unintended conflicts of interests is important.

Link

Fog of War - The GNOME Trademark Battle

The story of what was happening in the background during the Gnome battle for their trademark with Groupon last year, told by a Gnome board member and the lawyer that helped them on the case. Interesting insights thanks to the lawyer's perspective particularly, who also took a guess at what possibly happened in the Groupon lawyers' mind during their risk analysis and the consequences (e.g. "Groupon was dealing with an animal they'd never seen before." A charitable org not willing to be silenced or take a big donation.) Not a kind reflection on Groupon.

Link

Why Samba moved to GPLv3: Why we moved, what we gained, what we lost.

Emboldened by having managed to get a seat in the Legal devroom, I decided to also stick around for the next talk. I hadn't attended a talk on GPLv3 in a few years and I wasn't to be disappointed. It was a very honest and funny talk - I knew of Jeremy Allison aka the Samba guy, but I didn't know he was such an entertaining speaker. Overall Samba seems very happy with the move to GPLv3, it simplified a lot of things for them especially in terms of copyright managenent (some companies are just nasty), and most of the contributors and users they initially lost ended up returning (multiple closed-source vendors being bought out and leaving their customers in the cold likely helped). They felt really let down that the FSF didn't force their own projects to move as well (though I understand that is not the case anymore) and of course the Linux kernel being GPLv2-only is hurtful too. The speaker is convinced that all the scary stuff around GPLv3 is FUD and everyone should switch to using GPLv3+ right now if they don't have to link to v2 stuff. An audience member did raise an issue/unclear point with the v3 licence, for when a company rents a device to a customer (that the user doesn't actually own and thus perhaps? shouldn't be allowed to modify).

Link

Participation metrics at Mozilla: A story of systems and data

For projects that depend so heavily on volunteer contributions as Mozilla does, understanding who the community is made of and where/when people are being lost or leave is really important. The speaker started by showing us some of the ways they tried and failed to measure participation and what they ended up with. They defined what "participation" means by formalising paths a contributor might take across their systems (e.g. file a bug, comment on a bug, translate a string, etc) and they extract and map the data they have to these paths. This enables them to also deduplicate contributor information: for instance it's not because you have 100 translators and 300 developers that you have 400 contributors, people can do more than one thing, and it also lets them identify more clearly whether someone is leaving the project altogether or simply moving to another area. Very interesting stuff!

This is work in progress but their current results and reports are available at Are we a million yet.

Link

Maintaining & growing a technical community: Mozilla Developer Network

The other Mozilla talk I attended explored the meaning of community and the motivations behind why people start contributing, why they continue to contribute and how to help folks feel involved and want to contribute. The speaker made some really good points, one that really stuck with me being that contributors ≠ community. It's really important to connect contributors to your community or they will not stick around! The example she used was getting people to contribute at hackathons-like events, but then disappear - as someone who's run such events that certainly rang true, simply showing folks they can make a positive impact easily is not enough to make them come back or feel part of the community.

Link

Retooling Fedora: A Retrospective on Fedora 21 (and looking to 22)

I knew Fedora had been changing their model since the past release but I hadn't been following closely. This clarified the goals and the why, and I was very impressed with the beginning of the talk where the speaker (Matthew Miller, the current Fedora Project Leader) took a really hard look at where distributions are today and why they appear to be becoming less relevant - for instance looking at the contrast between the number of open-source projects available on platforms like Github compared to what is actually packaged in the distro. People used to care about getting their software into the major distributions but it doesn't seem to matter as much nowadays. In that light the "ring" graph showed toward the end, explaining that perhaps the apps at the outer layer don't need as strict and stringent criterias for inclusion than the more core OS components, totally makes sense and the future looks interesting.

Link

¤

I continue to be hugely impressed by how much Mozilla cares about improving the experience for new and existing contributors (impressed but not surprised! Their "Get Involved" page remains excellent, letting you get in touch with real people while showing at one glance all the different ways you can help, and having a mentored bugs process for new contributors is an awesome step-up from simply tagging easy bugs. Keep rocking and showing us all how it's done Mozilla!)

Videos of the talks should be available in time on the FOSDEM website.

Leave a comment

FOSDEM 2010: Gnome talks Bug triaging, Plugin framework, A new kind of IDE

There were quite a few talks about Gnome, I'm going to highlight here 3 of them.

Gnome foot

Gnome Bugsquad

The first talk was about bug triaging in Gnome. I can't believe there are only 5 active bug triagers in the project (as in, people fully focused on cleaning up the bug database). Tobias Mueller, the happy and dynamic speaker, made a good job explaining why this is such an important task, as the bug tracker is basically a window to the world. This is what people will be confronted with when they try to interact with the project, and having unanswered bugs lingering around doesn't give a very good impression.

In itself, bug triaging is a great entry point into the project because it doesn't require in-depth knowledge and it brings you closer to the community as you get to know the developers by name, so it's a good way to get involved, learn more about Gnome and help out.

The way triaging work:

  • There are bugs. People find them and complain about them in the bug tracker.
  • We need to understand and get all the necessary information for the developer to be able to fix it.
  • So the status of the bug needs to be kept accurate (more on that later)
  • And bug triagers can identify severe issues, such as bugs that come back often or many times so we can inform the adequate people.

I love that quote: "Bug triaging is about making people happy." We want our users to be happy, Gnome is about the people in the end!

Some other happy mottos:

"Be nice, be friendly, be happy."

"Answer early, answer often."

There are several ways to get in touch, through IRC, the mailing list, they're trying to hold bug days but currently lack the manpower to do so. They have a triage guide that is apparently so awesome even the KDE guys use it! :D Here's a link, I have to carve out time to read it.

After showing us some tools to find duplicate bugs and what sort of information to ask for, Toby walked us through the different statuses and how to use them, like what to do if you can't get information from the bug reporter after 6 weeks (the assumption is that this is not a problem anymore so resolve the bug), or if you're triaging a bug from more than 2 releases ago (resolve it as obsolete). Some statuses are reserved for the module maintainers. It's all summarised in a shiny diagram available on the wiki. When you start out you actually can't modify the status yourself, so you should add a comment explaining why you think the status should be updated and someone with the Power on #bugs will change it for you. Quickly enough, once you've shown you understand how this works, you can ask for the ability to change statuses yourself.

The final statement was that they need people and it's a good way to start if you want to get involved, it's not too hard for beginners and it doesn't cost too much time or requires that much knowledge. And you get to know the people and projects.

To get started:

  1. Create a Bugzilla account,
  2. Read the wiki,
  3. Ask questions on IRC,
  4. Get started. You can't do anything yet, so write it in the comments,
  5. If it all makes sense ask for access to do it yourself.

At the end, he asked who he convinced, I think he should have asked who would consider contributing to bug triaging, that's less commitment while still showing interest :) I joined the ML while he was speaking but I didn't raise my hand when he asked, because my way of doing things is to lurk for a while and then see if/how I can fit something in my schedule, rather than making promises I will break. We'll see how that one goes! I'd love to get more involved with Gnome.

Adding plugins to your Gnome apps

Steve Frécinaux talked to us about libpeas, a framework being developed to make plugin development within Gnome applications easier and more consistent across applications.

Plate of peas

Building a plug-in API is very, very hard, and having dissimilar APIs makes it harder -- that is, if you write a plugin for Nautilus, you will have to relearn from scratch to build a plugin for gedit. There's a heavily duplicated code base as well, as most projects seem to have taken the gedit plugin framework as a basis, but it's all slightly different because of bug fixes and fitting their own special needs that are not transmitted upstream.

Libpeas aims to fix all this. Plugins are good because they enable the main codebase to remain simple and clean while allowing for lots of additional functionality.

The goals are:

  • Ease of use: the framework should be minimalist with little boilerplate code
  • Extensible: different applications have different needs, not every project is like gedit
  • Lightweigth: it should only load what you use, e.g. not load python if it's not needed by any plugin

Plugins can be written in C, Python, or Javascript.

A plugin is what you install, which can consist of one or more extension. An extension is the implementation of an extension point (hooks). So plugins can register extensions with several extensions points within the application.

The speaker walked us through the different principles of plugins vs extensions, and finally showed us the steps to follow to make your applicable extensible and create hooks.

I can't find a page for the project on the Gnome wiki though, which is not cool :/

Gnome Development Tools: High-Level Debugging and the Misha Research IDE

To be honest I'm not sure this was particularly Gnome-specific, although it WAS written using Gtk tools :) Nick Papoylias introduced us to a new genre of IDE, based on the premise that debugging hasn't really evolved in the past 20 years when really, there are many ways it could be used besides stepping line-by-line through a program after encountering a problem. Debuggers can be integrated to different phases of the development life cycle, and there are many ideas that academia has put forward that are slow to be adopted, if at all (reverse debugging just made it into the latest gdb for instance).

He admitted that they didn't respect every Gnome UI guideline but as they were experimenting with a new approach to IDE and programming workflow, it made sense to experiment with a different UI as well to save space. The interface felt really busy but I'm not particularly worried about that, that's how IDE tend to be by nature.

They are adding new things to rethink the debugging workflow, that work together with the symbol debugger (gdb).

  • Syntax parser: Navigate code in terms of structures, loop iteration, functions -- not only line by line
  • Data visualisation
  • General purpose extension language: Python
  • Reverse debugging

It supports stepping through the syntactic structure while having a up-to-date data visualisation. This is a very nice way to see what is happening as we run through the code, he showed an example of variable insertion in a Binary Search Tree and it was amazing to see the tree be updated for every iteration of the loop. That'd be a much faster way to catch silly little bugs that tend to creep up as you develop (so you can catch them even before writing lengthy unit tests).

The presentation ended by showing us what the extension language could do and wow. Was that impressive. You can use Python functions to call your C code, for both simple and elaborate calls. The Python code directly calls C functions with no intervention from the developer. And through the debugging console we can visualise what's going on (e.g. the tree that is created through Python).

Additionally, if you create a main.py in your project, you can attach callbacks buttons to the IDE. This is really cool. He had it call a plotting application to display random results in a graph and check the distribution or whatever. It was really impressive.

So Python can be used to make inter-language calls, import external libraries, add functionality to the IDE, and call C programs directly. Check out the project website.

Leave a comment

FOSDEM 2010: Saturday morning keynotes Welcome to FOSDEM, Promoting open-source methods in large companies, Evil on the Internet

I barely took any pictures at FOSDEM this year, so I'm going to steal (with credit!) pictures from various Flickr streams.

Saturday morning began with the customary welcome keynote, with a little twist for the FOSDEM dance (heh!). Wireless was up and running well before 12.00, which was a nice surprise.

FOSDEM dance
(Picture credit: itkovian, Creative Commons "Attribution-Non-Commercial-Share Alike 2.0 Generic", taken from Flickr)

Promoting open-source methods in large companies

The first keynote was on promoting open-source methods in large companies. Not using slides made it quite hard to follow, that made me realise how slide stacks help with understanding the structure of a talk, what was said when there is noise around, or just remember/understand where we're at after being distracted and having zoned out for a couple of minutes... (and let's be honest that's always going to happen!)

Brooks Davis described his journey getting open-source adopted internally. It was more in the sense of having people open-source their projects within the company than anything larger, although quite a lot of open-source projects were used to achieve that (Apache, PostgreSQL, trac...) He started from quite far since he had to sell people on the concept of version control itself to begin with! (I empathise with that, it's very hard to make devs who are not familiar with it  use version control tools to their full potential. For instance I keep having to remind my team that it's ok to delete a now-unused file or big chunk of code because we can find it again if we need to. Dead files and dead code just make maintenance more painful.) The policy they set out for their internal open-source repository was that ALL projects had to be ENTIRELY open-source (can't keep any section secret.)

The barriers to adoption were mostly driven by fear:

  • Fear of misuse: People need to trust their colleagues! (This is actually an interesting point. The speaker works with space-related software so I'm guessing there's quite a lot of IP and other trade secrets in their software. I wonder how they ensure and/or convince management that no employee would sell them out to the competition. I understand how the policy is tremendously useful to avoid duplication, foster collaboration between internal projects and just make sure part of the project doesn't disappear or get lost with a single developer. It's possible the speaker talked about this and I missed it though, the keynote should have been recorded... I guess this point includes "trust your employees" as well.)
  • Misplaced sense of ownership, with people believing "this is MY code" when actually, this is the COMPANY code!
  • Credit: Although the open-source community is quite good at it, within a company people tend not to be so good at giving credit where it's due (although they are learning, according to the speaker!)
  • Another concern was that "people will like it and then they will modify it and make it better," quite a confusing complaint

The positive points of this approach and policy are that:

  • anyone can access the code in the public repository, rather than have it exist on only the one guy's laptop, that has to be hunted down when someone wants to reuse the code or needs it for another project
  • there is a snowball effect once people start using the system

Along the way a few lessons were learnt and changes were made accordingly:

  • The "everything must be open and available" policy was relaxed a bit to accommodate for NDA, work by contractors, etc. A project must submit an application to justify such security requirements, to be reviewed and approved (many teams believe their project require such mechanism when really, it doesn't)
  • Moved from mod_python to wsgi (easier to manage)
  • Performance: They bought more RAM to handle the multiple Python instances (1/project), and thanks to WSGI have the project sleep when not accessed (they still have issues with the internal search crawler though, as it means every project page gets accessed within a few seconds!)

The barriers to adoption by development teams are:

  • Team isolation, each team kinda works in its own island
  • People don't know it exists
  • People think it's a heavy-weight project involving lots of paperwork (e.g. fill 6 forms to make a change)

There was a bit of talk on distributed version control. He finds it interesting but as his people are just getting used to the concept of centralised version control it might be a bit early. There is also the issue of backing up the projects, because the distributed nature of those tools could mean that people revert to only having a copy on their own machine. He's interested to see how people in open-source deal with this, and hopefully learn from it.

They are working on a few improvements to trac that they aim to contribute back (e.g. seeing tickets for multiple projects on the one screen.)

In the end I was a bit disappointed by the talk, because it focused so much on implementation (which is cool, I love hearing about this kind of stuff but I already had this with Ship It!. I know I want it.) when I was hoping for more strategies on how to help management and developers see the benefits of open-source. I'm interested in understanding how to get it adopted internally, how to bring change. Someone in the audience actually asked kind of a similar question, asking how he got management to pressure one particular internal project to use the new tools (mentioned during the talk.) I think the answer was along the lines of if the company spends a couple of millions a year on a project or another, they're interested in seeing it reused and easily available internally. Which doesn't really help us, but I guess if he has support from management to begin with it's just difficult to answer.

Evil on the Internet

The second morning keynote was about Evil on the Internet. The poor speaker, Richard Clayton, was severely booed at the beginning when the Windows screen showed up as people struggled to get Windows to play nice with the projector, but once he started with his talk it was most excellent because presented in such a funny way. Apparently the only thing bad guys have to do all day is design very nice and sleek looking websites, while trying to screw people over every possible way. To me the highlight of the talk was the job ad for Millenium Inc., a phishing company (though it doesn't present itself as such, for obvious reasons.) Their vacancies page advertises for a lot of positions, most them "not currently available" ...except for one. They are looking for a "payment processing assistant." Your job would consist of receiving payments from their clients onto your bank account, that you then take out and send on to Millenium through Western Union. Very nice. When the bank realises the money was moved onto your account through fraud it will take it away, and you'll be left with no recourse because Western Union will never ever refund any money you send using their services. There were many other examples, and there's more on his blog.

Leave a comment

Back from FOSDEM

FOSDEM is over, and all I can say right now is that I bought way too many tee-shirts (awesome :D and still not enough!). Got most of them in girl size which is great, albeit some of the sizings were a bit messed up (I had to buy a FSF shirt in size L. Granted I did buy it on the last day, perhaps the waffles are to blame ;)). I'll post my notes on some of the sessions in the coming days, really disappointed to have missed the ending keynote by GKH on writing your first kernel patch but I was concerned about missing my plane -- turns out I shouldn't have worried. Will be watching out for the video recording of that one!

Leave a comment

FOSDEM 2010

  I'm going to FOSDEM, the Free and Open Source Software Developers' European Meeting
\o/
 |
/ \

Leave a comment