Open development and inner source for fun and profit

2017-05-26 07:17
Last in a row if interesting talks at Adobe Open Source Summit was on Open Development/ Inner Source and how it benefits internal projects given by Michael Marth. Note: He knows there's subtle differences between inner source and open development, but mentioned to use the terms interchangeably in his talk.

So what is inner source all about? Essentially: Use all the tools and processes that already work for open source projects, just internally. (Company) public mailing lists, documentation, chat software, issue trackers. Taken to it's core this is very simplistic though. The more interesting aspects are waiting when looking at the people interaction patterns that emerge.

First off: The goal of making all interaction public and easy to follow for anyone is to attract more contributors. The richest source of contributors can be tapped into if your users are tech savvy as well. Being based on this assumption inner source works best when dealing with infrastructure software, or platform software where downstream users are developers themselves.

As a general rule of thumb: From 100 users, 10 will contribute, one will stick around and become a long term committer. This translates into a lot of effort for gaining additional hands for your project.

So - assuming what you want is a wildly successful open source project: You put your code on Github (or whatever the code hosting site of the day is), start some marketing effort - but still not magic happens, no stars, no unicorns, maybe there's 10 pull requests, but that's about it. What happened?

Architecting a community around an open source project is a long term investment: Over time you'll end up training numerous newbies, help people getting started and convince some of those to contribute back.

According to the speaker Michael Marth where that works best is for infrastructure projects: Where users can be turned into contributors and where projects can be turned into platform software that lasts for a decade and longer. In his opinion what is key are two factors: Enabling distributed decision making to let others participate, and a management style that lets the community take their own decisions instead of having one entity control the project. Usually what emerges from that is a distributed, peer-peer networked organisational structure with distributed teams, no calls, no standups, consensus based decision making.

In Michaels experience what works best it to adopt an open source working model from the very start. His recommendation for projects coming from comercial entities is to go to the Apache Software Foundation: There, proven principles and rules have been identified already. In addition going there gives the project much more credibility when it comes to convincing partners that decisions are actually being made in a distributed fashion without being controllable by one single entity. So telling a customer "We have to check this with the community first" as an answer to a feature request becomes much more credible.

The result of this approach are projects that under his guidance gained ten times as many people contributing to the project outside of the original entity than inside of it. The result Michael observed were partners that were much more likely to stick with the technology by means of co-owning it. Partners were participating in development. Also the project made for a lovely recruiting pipeline filled with people already familiar with the technology.

Note to self - slides for staying sane when maintaining a popular open source project

2017-05-26 07:00
For further reference - Simon MacDonald has a great collection of good advise on how to stay sane when running and maintaining a popular open source project. Link here: http://s.apache.org/sanity

Some things he mentioned:

Include a README. It should tell people what the project is about but also what the project is not about. It should have some sort of getting started guide. Potentially link to a CONTRIBUTING doc.

Contribution guidelines should outline social rules like a code of conduct, technical instructions like how to submit a pull request, a style guide, information on how to build the project and make changes etc.

Add a LICENSE file - any OSS license really, because by default it won't be open source in no jurisdiction. Add file headers to each file you publish.

Decide how to handle questions vs. issues: Either both in the issue tracker, or in separate venues.

Add an issue template that asks the user if they searched for the issue already, asks for expected behaviour, actual behaviour, logs, reproduction code, version number used. A note on issues: Having many issues is a good thing - it shows your project is popular. Having only many stale issues is a bad thing - nobody is caring for the project anymore.

Close issues that don't follow the template. Close issues that are duplicates. Close issues that are non active after asking for user input a while ago. Repeated issues asking for seamingly obvious things: Turn those into additional documentation. Asks for easy to add functionality: Let it sit for a while to give others a chance to do it and get involved. Same for bugs that are easy to fix.

Overall people are more difficult than code. Expect trolls to show up. Remain empathetic, respectful but firm in your communication. Don't be afraid to say no to external requests even if they are urgent for the requester.

Add a pull request template that asks for a description, related issue, type tag. Remember that you don't have to merge every pull request.

Build a community: Make it easy to contribute, identify beginner bugs, document the hell out of your project, turn contributors into maintainers, thank people for their effort.

Have tests but keep build times low.

Add documentation, at the very least a README file, a how to contribute file, break those files into a separate website once they grow too large.

As for releasing: Automate as much as you can. Three options: time based release schedule, release on every commit, release "when it's done".

Async decision making

2017-05-16 06:45
This is the second in a series of posts on inner source/open source. Bertrand Delacretaz gave an interesting talk on how to avoid meetings by introducing an async way of making decisions.

He started off with a little anecdote related to Paul Graham's maker's vs. manager's schedule: Bertrand's father was a carpenter. He was working in the same house that his family was living in, so joining the family for lunch was common for him. However there was one valid excuse for him to skip lunch: "I'm glueing." How's that? Glueing together a chair is a process that cannot be interrupted once started without ruining the entire chair - it's a classical maker task that can either be completed in one go, or not at all.

Software development is pretty similar to that: People typically need several hours of focus to get anything meaningful done, in my personal experience at least two (for smaller bugs) or four (for larger changes). That's the motivation to keep forced interruptions low for development teams.

Managers tend to be on a completely different schedule: Context switching all day, communicating all day adding another one hour meeting to the schedule doesn't make much of a difference.

The implication of this observation: Adding one hour of meeting time to an engineer's schedule comes with an enourmous cost if we factor the interruption into the equation. Adding to the equation that lots of meetings actually fail for various reasons (lack of preparation, lack of participants getting prepared, bad audio or video quality, missing participants, delayed start time, bad summarisation) it seems valid to ask if there is a way to reduce the number of face to face meetings while still remaining operational.

As communication still remains key to a functional organisation, one approach taken by open development at Adobe (as well as at the Apache Software Foundation really) is to differentiate between things that can only be discussed in person and decisions that can be taken in an asynchronous fashion. While this doesn't reduce the amount of time communicating (usually quite the contrary happens) it does allow for participants to participate pretty much on their own schedule thus reducing the number of forced interruptions.

How does that work in practice? In Bertrand's experience decision making tends to be a four step process: Coming from an open brainstorming sessions, options need to be condensed, consensus established and finally a decision needs to be made.

In terms of tooling in his experience what works best is to have one and only one shared communication medium for brainstorming. At Apache those are good old mailing lists. In addition there is a need for a structured issue tracker/ case management tool to make options and choices obvious, decisions visible and archived.

When looking at tooling we are missing one important ingredient though: Each meeting needs extensive preparation and thourough post processing. As an example lets take the monthly Apache board of directors' meeting: It's scheduled to last no longer than two hours. Given each of hundreds of projects are required to report on a quarterly basis, given that executive officers need to provide reports on a monthly basis, given that each month at least one major decision item comes up and given that there is still day to day decisions about personel, budget and the like to be taken: How does reducing that to two hours work? The secret sauce is a text file in svn + a web frontend called whimsy to it.

Directors will read through those reports ahead of the meeting. They will add comments to them (which will be mailed automatically to projects), often those comments are used by directors to communicate with each other as well. They will pre-approve reports, they will mark them for discussion if there is something fishy. Some people will check projects' lists to match that up with what's being discussed in the report, some will focus on community stuff, some will focus on seeing releases being mentioned. If a report gets enough pre-approvals an no mark "to be discussed" they are not being shown or touched in the real meeting.

That way most of the discussion happens before the actual meeting leaving time for those issues that are truely contentious. As the meeting is open for anyone in te foundation to attend questions raised beforehand that could not be resolved in writing can be answered in the voice call fairly quickly.

Speaking of call: How does the actual meeting proceed? All participants dial in via good old telephone. Everyone is on a telephone so the issue of "discussions among people in the same room are hard to understand for remote participants" doesn't occur. In addition to telephone there's an IRC backchannel for background discussion, chatter, jokes and less relevant discussion. All discussion that has to be archived and that relates to discussions is kept on the voice channel though. During the meeting the board's chair is moderating through the agenda. In addition the secretary will make notes of who attended, which discussions were made and which arguments exchanged. Those notes are being shared after the meeting, approved at the following month's meeting and published thereafter. If you want to dig deeper into any project's history, there's tooling to drill down into meeting minutes per project until the very beginning of the foundation.

Does the above make decision making faster? Probably not. However it enables an asynchronous work mode that fits best with a group of volunteers working together in a global, distributed community where participants do not only live in different geographies and timezones but are on different schedules and priorities as well.

Notebook - OSS office at Adobe

2017-05-12 06:46
tl;dr: This post summarises what I learnt at the Adobe Open Source Summit last week about which aspects to think of when running an open source office. It's mainly a mental note for myself, hopefully others will find it useful as well.

Longer version:

This is another post in a series of articles on "random stuff I leant in Basel last week". When I was invited to Adobe's open source summit I had no idea what to expect from it. In retrospect I'm glad I accepted the invitation - it was a great mix of talks, a valuable insight into how others are adopting open source processes and their motivation for open sourcing code and helping out upstream.

The first in a series of talks gave an overview of Adobe's open source office. Currently the expertise collected there includes one human with a software development background, one human with a marketing background and one human with program management background showing the breadth of topics faced when interacting with open source projects.

The self-set goal of these people is to make contributing to open source as easy as possible. That includes making people comfortable internally with the way many open source projects work. It means making (e.g. legal, branding) review processes of contributions internally as easy as possible. It means supporting teams with checking contributions for license conformance, sensitive (e.g. personal) information that shouldn't be shared publicly. It also means supporting teams that want to run their own open source projects.

One idea that I found very intriguing was to run their team through a public github repository, in a sort-of eat-your-own-dogfood kind-of way.

One of the artifacts maintained in that repository is a launch checklist that people can follow which includes reminders for creating a blog post, publishing on the website, sharing information on social media. Most likely those are aspects that are often forgotten even in established projects when it comes to topics like releasing and promoting a new software release version.

Another aspect I found interesting was the creation of an OSS advisory board - a group of people intersted in open development and open source. A wider group of people tasked with figuring out how to best approach open development, how to get the organisation to move away from a private by default strategy towards an open by default way of collaborating across team boundaries.

Many of these topics fit well within what was shared earlier this year in the Linux foundation webcast on how to go about creating an open source office in organisations.

Agile, inner source, open development, open source development

2017-05-07 15:53
Last week I had the honour of giving a keynote at Adobe's Open Source Summit EU in Basel. Among many interesting talks they hosted a panel to answer questions around all things open source, strategy, inner source, open development. One of the questions I found intersting is how inner source/ open development and agile are related.

To get everyone on the same page, what do I mean when talking about inner source/ open development? I first encountered the concept at ApacheCon EU Amsterdam in 2008: Bertrand Delacretaz, then Day Software, now Adobe was talking about how to apply open source development principles in a corporate environment. A while ago I ran across the term http://innersourcecommons.org that essentially wants to achieve the same thing. What I find intersting about it is the idea of applying values like transparency, openess to contributions as well as concepts like asynchronous communication and decision making at a wider context.

What does that have to do with Agile? Looking at the mere mechanics of Agile like being co-located, talking face to face frequently, syncing daily in in person meetings this seems to be pretty much opposite of what open source teams do.

Starting with the values and promises of Agile though I think the two can compliment each other quite nicely:

"Individuals and interactions over processes and tools" - there's a saying in many successful popular projects that the most important ingredient to a successful open source project is to integrate people into a team working towards a shared vision. Apache calls this Community over code, ZeroMQ's C4 calls it "People before code", I'm sure there are many other incarnations of the same concept.

Much like in agile, this doesn't mean that tools are neglected alltogether. Git was created because there was nothing quite like this tool before. However at the core of it's design was the desire for ideal support for the way the Linux community works together.

"Working software over comprehensive documentation" - While people strive for good documentation I'd be so bold as to suggest that for the open source projects I'm familiar with the most pressing motivation to provide good documentation is to lower the number of user questions as well as the amount of questions people involved with the project have to answer.

For projects like Apache Lucene or Apache httpd I find the documentation that comes with the project to be exceptionally good. In addition both projects are supported with dead tree documentation even. My guess would be that working on geographically distributed teams who's members work on differing schedules is one trigger for that: Given teams that are geographically distributed over multiple time zones means that most communication will happen in writing anyway. So instead of re-typing the same answers over and over, it's less cost intensive to type them up in a clean way and post them to a place that has a stable URL and is easy to discoveri. So yes, while working software clearly is still in focus, the lack for frequent face to face communication can have a positive influence on the availability of documentation.

"Customer collaboration over contract negotiation" - this is something open source teams take to the extreme: Anybody is invited to participate. Answers to feature requests like "patches welcome" typically are honest requests for support and collaboration, usually if taken up resulting in productive work relationships.

"Responding to change over following a plan" - in my opinion this is another value that's taken to the extreme in open source projects. Without control over your participants, no ability to order people to do certain tasks and no influence over when and how much time someone else can dedicate to a certain task reaciting to changes is core to each open source project cosisting of more than one maintaining entity (be it single human being or simply one company paying for all currently active developers).

One could look further, digging deeper into how the mechanics of specific Agile frameworks like Scrum match against what's being done in at least some open source projects (clearly I cannot speak for each and ever project out there given that I only know a limited set of them), but that's a topic for a another post.

The idea of applying open source development practices within corporations has been hanging in the air for over 15 years, driven by different individuals over time. I think now that people are gathering to collect these ideas in one place and role them out in more corporations discussions around the topic are going to become interesting: Each open source community has their own specifics of working together, even though all seem to follow pretty much the same style when looked at from very high above. I'm curious to what common values and patterns can be derived from that which work across organisations.

Note to self: Backup bottlenecks

2014-03-23 18:26
I learnt the following relations the hard way 10 years ago when trying to backup a rather tiny amount of data, went through the computation again three years ago. Still I had to re-do the computation this morning when trying to pull a final full backup from my old MacBook. Posting here for future reference: Note 1: Some numbers like 10BASE-T included only for historic reference. Note 2: Excluded the Alice DSL uplink speed - if included the left-hand chart would no longer be particularly helpful or readable...

How hard can it be - organising a conference

2014-03-15 19:37
Setup a CfP, select a few talks, publish a schedule, book a venue, sell a few tickets - have fun: Essentially all it takes to organise a conference, isn't it?

In theory maybe - in practice - not so much. Without scaring you away from running your own here's my experience with setting up Berlin Buzzwords (after two years of running the Berlin Hadoop Get Together, putting up a NoSQL half day meetup).

Disclaimer: Though there's a ton of long-ish posts in my blog, this one is going to be exceptionally long. It's years since I wanted to write all this up for others to learn from and in order to point others to it - never got around to it though.

Venue booking

Lets start with the most risky part: Booking a venue. If you are a student - great - talk to your university to get your event hosted. As much hassle this may entail when it comes to bureaucracy this is by far the largest monetary risk factor in your calculation, so if there is any way to get rid of this factor use it. FOSDEM, FrOSCon, Linux Tage Chemnitz and several other events have handled this really well.

If this is not an option for you depending on the number of targeted attendees you are faced with a smaller (some 500 Euro for 100 people per day and track) or larger (some 20.000 Euros for 300 people, two days and two tracks including chairs, tables, microphones, screens, projectors, lighting, security and technicians) sum that you will have to pay up front, potentially even before your attendees purchased any tickets (here's one reason why there is such a thing as an early bird ticket: The earlier money flows in the less risk there is around payments).

In Germany there's three ways to limit this risk: You create a so-called e.V., essentially a foundation that will cover the risk. You create a GmbH, essentially a company that assumes limited risk, namely only up to the 25.000 Euros you had to put into the company when founding it. The third way is to find a producing event agency that assumes all or part of the risk. After talking to several people (those behind Chaos Communication Congress, those setting up the Berlin Django Con back in 2010, those working on JSConf, those backing Hadoop World) for me it was logical to go for the third way: I had no idea how to handle ticket sales, taxes etc. and I was lucky enough to find an agency that would assume all risk in turn for receiving all profit made from the event.

One final piece of advise when selecting your venue: Having a place that is flexible when it comes to planning goes a long way to a relaxed conference experience. As much as it is desirable you won't be able to anticipate all needs in advance. It also helps a lot to keep the event on your home turf: One of the secrets of Berlin Buzzwords is having a lot of local knowledge in the organising team and lots of contacts to local people that can help, support and provide insight:

By now at Berlin Buzzwords we have a tradition of having an after conference event on Monday evening. The way the tradition started relied heavily on local friends: What we did was to ask friends to take out up to 20 attendees to their favourite bar or restaurant close to the venue in turn for a drastically reduced ticket price. This approach was highly appreciated by all attendees not familiar with Berlin - several asked for a similar setup for Tuesday evening even. Starting from the second edition we were able to recruit sponsors to pay for beers and food for Monday evening. Pro-Tipp: Don't ship your attendees to the BBQ by bus - otherwise the BBQ cook will hate you.

Something similar was done for our traditional Sunday evening barcamp: In the first two years it took place at the famous Newthinking Store - a location that used to be available for rent for regular events and free for community events. Essentially a subsidary of our producer. In the second year the Barcamp moved to one of the first hacker spaces world - c-base. Doing that essentially was possible only because some of the organisers had close contacts among the owners of this space.

The same is true for the Hackathons and meetups on Wednesday after the main conference: Knowing local (potential) meetup organisers helps recruiting meetups. Knowing local startups helps recruiting space for those people organising a meetup though themselves travelling e.g. from the UK.

Catering

Another risk factor is providing catering: If catering is included in your ticket price, the caterer will probably want to know at least one week before door open roughly how many people will attend (+/-10 people usually is fine, +/- 100 people not really). When dealing with geeks this is particularly tricky: These guys and gals tend to buy their tickets Saturday/Sunday before Berlin Buzzwords Monday morning. In the first two years that meant lots of sleepless nights and lots of effort spent advertising the conference. In the third night I decided that it's time for some geek education: I suggested to introduce a last minute ticket that is expensive enough to motivate the majority of attendees to buy their tickets at least two weeks in advance. Guess what: Ever since we the problem of "OMG everyone is buying their ticket last minute" went away - and at least I got my sleep back.

The second special thing about catering: As much as I would like to change that Berlin Buzzwords has an extremely skewed gender distribution. When dealing with caterers what they usually only want to know is how many people will attend. If you forget to tell them that all your attendees are relatively young and male they will assume a regular gender distribution - which often leads to you running out of food before everyone is fed.

Sponsoring

Except for tickets - are there any other options to acquire money apart from tickets? Sure: convince companies to support your event as sponsors. The most obvious perk is to include said company's logo on your web page. You can also sell booth space (remember to rent additional space for that at your venue). There's plenty of other creative ways to sell visibility. For package sizing I got lots of support from our producer (after all they were responsible for budgeting). Convincing companies to give us money that was mostly on Simon, Jan and myself. Designing the contracts and retrieving the money again was left to the producer. Without a decent social network on our side finding this kind of financial support would not have been possible. In retrospect I'm extremely glad the actual contract handling was not on me - guess what, there are sponsors who just simply forget to pay the sum promised though there is a signed contract...

Speaking

So, what makes people pay for tickets? A convincing speaker line-up of course. In our case we had decided to go for two invitation only keynote speakers and two days with two tracks of CfP based talks. Keynote speaker slots are still filled by Simon and myself. In early years where CfP ratings, schedule grid (when and how long are breaks? how many talks will fit?) and scheduling itself were on Simon, Jan and myself. As submission numbers went up we decided to share the review load with people whose judgement we trust - ensuring that each submission gets three reviews. All after that is fairly algorithmic: See an earlier blog post for details.

A note on review feedback: As much as we would like to give detailed feedback to those who didn't make it: We usually get three times as many submissions as there are open slots. So far I haven't seen a single submission (except for very clear product pitches lacking technical details) that wasn't great. So in the end, most feedback would boil down to "It was really close, but we only have a limited number of slots to fill. Sorry."

Back in 2011 we tried an experiment to fit more talks into the schedule than usual: Submissions ranked low that were supposed to be long talks were accepted as short versions forcing speakers to focus. Unfortunately this experiment failed: Seems like people rather get a reject mail than getting accepted as a short version. Also you need really good speakers who prepare exceptionally well for the event - in our case many shortened talks would still include all introductory slides even though the speaker just one slot earlier had covered those already.

Marketing

Next step is to tell people that there is going to be an event. In the case of Berlin Buzzwords this meant telling people all over the world and convincing them to not only buy a conference ticket, but also a hotel room and a flight to the venue (we started with only half of all attendees coming from Germany and pretty much kept this profile until today). As a first step this meant writing a press release and convincing local tech publishers (t3n, heise, Golem, Software und Support, Open Source Press and many more) to actually publish on the event. For some of these I am an author myself, so I knew which people to talk to, for some of these newthinking as the producing event agency could help. It was only years later that I participated in a media training at Apache Con by Sally Khudairi to really learn how to do press releases.

From that day on, a lot of time went into convincing potential speakers to submit talks, potential sponsors to donate money, potential attendees to make it to the event. With a lot of event organising experience on their back (they are running a multiple thousand attendees new media conference called re:publica each year - in addition to many "smaller" events) newthinking told me upfront that they would need half of my time to cover those marketing activities, essentially as I was the only one who knew the community. The offer was to re-imburse 20h per week from the conference budget. I was lucky enough to be able to convince my manager at neofonie (the company I was working for back then) though that sponsoring the event with my time in turn for a silver sponsorship would be a great opportunity. One of the reasons for doing that on their side was that they were themselves providing services in the big data and search space. Without this arrangement though Berlin Buzzwords 2010 would have been a whole lot harder to do.

Now how do you reach people for a tech conference? You talk to the press, you create and promote a twitter account. I still have the credentials for @berlinbuzzwords - by now though it is fully managed by our social media expert, back until 2011 I was the face behind it. Ever since my twitter client is set to follow anything that contains bbuzz, berlinbuzzwords or "berlin buzzwords" - so I can still follow any conversation relating the conference. You create and maintain LinkedIn and Xing as well as Facebook groups for people to follow. You use whatever channels your target audience are reading - in our case several Apache mailing lists, a NoSQL mailing list, sourceforge hosted lists - remember to sign up for these before posting, otherwise your mail won't get through. Also make sure that people at least roughly know your name, trust you and you provide enough context in your mail for others to not view your invitation as plain spam.

Finally you go through your personal address book and talk to people you know would be interested personally. As a result you will wake up to 20 new mails each morning and answer another 20 new mails every evening. For me this got better after having shaped all contacts into a format that I could hand over to newthinking. However even today, every single mail you send to [target]@berlinbuzzwords.de, every comment you submit through the contact form, every talk wish you submit through our wishlist still ends up in my personal inbox - as well as the inbox of Simon and everyone involved with the conference at newthinking.

Essentially you need this kind of visibility once for announcing the event, once for filling the CfP with proposals, once the schedule in published, once to convince sponsors to support the event and finally once to convince people to buy tickets.

As for the website - the most frustrating part is being a technical person but lacking the time to "just do things right". Drupal, I'm sorry, but I have learnt to hate your blogging functionality - in particular the WYSIWYG editor. Your administrative backend could be much simpler (I gave those rights away I believe in 2012). I learnt to hate comment spam more than anything else - in particular given the fact that I pretty much would have loved to get everyone involved and able to contribute content. The only thing that helped accepting the deficiencies here was to force myself to hand of any and all content handling to the capable event managers at newthinking.

Misc

Videos: Great way to get the word out (and follow the talks yourself, though organisers may find time to go to talks they'll never remember the actual content due to information overload). Make them free - people pay for tickets to take part in the live event. If you fear selling less tickets as a result, make them available only a little while after the event is over.

Pictures: Get someone with a good camera - can be a volunteer, can be a professional or anything in between. I've had it many times that it took half a year for me to go over the pictures again and suddenly realise how many nice people attended Buzzwords without me knowing them when they did - except they remembered my face when we met again (sorry if you are one of those people I should have remembered once :( )

Inbox: Your's will never be empty again. Especially if as in our case your mail address was used as primary point of contact and reference in the first few years. It took two editions to train people to use info@berlinbuzzwords.de instead of my personal mail address. Trust me - this mail address actually does get attention: Mails sent there end up in my private inbox, they end up in Simon's private inbox and most importantly they end up in those event managers' inboxes involved with Buzzwords at newthinking. Answers typically don't take much longer than half a day even during holidays. Today there is no reason left to contact neither Simon or myself privately - using info@ is way faster. If you still aren't convinced: Even I'm using that same address for general inquiries and proposals.

Incentives: Think early about which behaviour you would like to see. On site behave accordingly. Pre-conference set incentives: Two weeks before doors open our ticket prices go up drastically to motivate people to buy tickets before our catering deadline bites us. Speakers get travel support and hotel room paid for. However it costs us nothing to list their employer as travel sponsor should they decide to pay for the speaker - and it provides an incentive for the speaker to get their employer to pay for travel costs.

Ticket prices: You will get people arguing that ticket prices are too high. Know where you stand in comparison to other conferences of the same type. Clearly you want students if the main focus of your sponsors is to recruit - provide drastically reduced student tickets to anyone with a student id, that includes PhD. students. For everyone else: Buying early should be rewarded. Also you'll need help on site (people moderating sessions, keeping full rooms closed, people helping with video taping, networking etc.) - hand out free tickets to helpers - if those complaining aren't willing to help their need for a cheap ticket probably isn't large enough.

The "they are stealing our attendees syndrome": Unless there is a clear trademark infringement there's no way to stop other people from running events that on first sight look similar to yours. First of all start by making it hard to beat your offering - not in terms of prices but in terms of content and experience. After you've done that follow the "keep your friends close but your enemies closer" principle by embracing those who you believe are running competing events. What we had in the past was events close in topic to ours but not quite overlapping. Where there was enough overlap but still enough distinction we would go out and ask for partnering. This usually involved cross-raffling tickets. It also meant getting better visibility for our event though different channels. Usually the end result was one of two: A) The competing event was a one-of or otherwise short-lived. B) The seemingly competing event targeted an audience that was much more different from ours than we first believed.

On being special

What makes people coming back? I have been told Berlin Buzzwords has a certain magic to it that makes people want to come back. I'm not sure about the magical part - however involving people, providing space and time for networking, choosing a venue that is not a conference hotel, always at least trying to deliver the best experience possible goes a long way to make attendees feel comfortable. As a last note: If you ever once organised a meetup or conference you will never attend other events without at least checking what others do - you will suddenly see all the little glitches that otherwise slip from your attention (overly full trash bins anyone?). On the other hand each event brings at least one story that when it happened looked horrible but turns out to be hilarious and told over and over again later ;)

Berlin Buzzwords - Associated Events

2014-02-13 17:00
Back in 2011 I had a weird idea: Berlin Buzzwords as a core event kicks off on Sunday evening with a Barcamp but closes on Tuesday evening. There's way too little time to meet with all the interesting people. On the other hand the organising team really was all tired on Tuesday evening, so just adding another day at the end wasn't really an option.

Now Berlin is known as one of the hottest European Startup Capitals. There's literally at least one meetup for any topic you can imagine. There's co-working spaces and companies happy to welcome developers for a one day meetup or Hackathon. So the idea was born to invite people to organise meetups, hackathons, workshops, unconferences or any kind of dev session of their choosing on Wednesday after Berlin Buzzwords - the goal being to keep Buzzwords speakers and attendees in town for longer.

In the mean time several meetup groups actually started by having their first event on Wednesday after Berlin Buzzwords. It's grown increasingly easy to find meetup space for these Wednesday meetups.

So how does it work? Essentially it's very easy: All that is needed is one person interested in a particular technology who is willing to organise a meetup for 20 to 120 people in Berlin on Wednesday after Buzzwords (or the weekend before, or the weekend after, it's really up to you).

It'd be greatly appreciated if you get in touch with info@berlinbuzzwords.de or even submit your meetup through the official CfP. In return it will receive marketing help and will be included in the official schedule page. (Note: Meetups are accepted as they come in - no review phase, no nothing).

If you need help finding a venue for your meetup (either for free or for rent, up to your preference) talking to info@berlinbuzzwords.de will help you. We'll get you in touch with local startups, co-working spaces and event venues.

Also remember - you don't need to be an expert in the topic you are organising the meetup for. All you need is justified interest in the topic. Don't be shy to invite your favourite developers as speakers for your meetup. Don't shy away from even approaching some of the Berlin Buzzwords speakers.

If you are a developer yourself think about turning your Wednesday event into a hackathon - either in order to get more users familiar with your project or to gt the next release out the door together with other people working on your project also attending Buzzwords. This kind of approach really is the reason why there is a correlation between the date Berlin Buzzwords takes place and Mahout release dates in summer. (If you need inspiration on what it takes to organise a well working Hackathon - a quick search on your favourite search engine for "hackathon howto" should surface plenty of documentation.)

I love FS 2014

2014-02-13 16:49
It's that day of the year again: Time to buy flowers and chocolate for your beloved one. However as with previous years, FSFE wants you to put the day to good use to also celebrate your favourite free software developer (you know, the people who get way more bug reports and complaints than positive feedback):
I love Free Software!
So here's to the people over at Apache, Debian, Eclipse, Elasticsearch, Linux, ZeroMQ and the many other projects that make my life easier: Happy I love Free Software Day - get yourself celebrated!

FOSDEM 2014

2014-02-03 14:53
By now FOSDEM turned into some kind of tradition in our family: Since 2007 every year in February we are travelling to that one comfy B&B in Brussels for a weekend - not to take a closer look at the city but to attend (together with thousands of other geeks and open source hackers) one of the biggest conferences on all things open source.

I love the conference concept for scaling: As it happens on a university campus they only have a limited number of huge rooms, but a fairly large number of mid-sized and small rooms. They use the venue to their advantage: Only the main tracks are organised by the official conference organisers. All other rooms are each filled with a community (usually a handful of people doing the heavy lifting of inviting speakers, putting a cfp out etc.) provided track. As a result even though they attract well over 5000 attendees it's only the most popular topics (e.g. Elasticsearch, GPL license discussions, configuration management, JDK specifics, kdbus, discussions on the relevancy of distribution packaging) tend to fill rooms completely.

When stuck with full rooms there's always some other talk on that probably is similarly interesting. In addition there is a huge exhibition area to visit where you can talk to the core developers behind the individual open source projects (and buy stuff like T-Shirts, grab a few flyers, stickers etc.). In addition there's so many people to talk to you usually won't get to see too many presentations anyway. In addition as of this year the crazy people of the FOSDEM (formerly Debian-only) video team managed to get (on a best effort, "hopefully the technician doesn't sleep in after that many beers yesterday" basis) all 445 talks video-taped with the goal of putting these online Monday after the conference.

On top I had the huge advantage of being able to simply follow to the talks my husband would go to if all of the stuff I am interested in is full: That would give me insight to completely different topics but also make it extremely easy for me to identify the good speakers and interesting presentations based on his experience avoiding the "if I'm unfamiliar with the topic and area I usually bump into the boring, badly given talks" problem.

I spent most of Saturday in a few talks on software patents, Daniel Naber's Language Tool, the Jolla BoF, the FLA. The rest of the time I caught up with the FSFE (thanks again for the bringing the onesies!), Debian, Open Office, Lucene and Elasticsearch people. The day ended at the Jolla community dinner - with a waitress that was completely overwhelmed by the number of geeks wanting food, beer and soft drinks.

Sunday I started with Chris Kühl's talk on Memory Tuning Android for Low Memory Devices. After that I helped at the Elasticsearch booth - FOSDEM definitely is an incredibly busy event. But given their target audience also is an interesting mix of people to talk to: Some had no idea about how text search works but came over because they had heard about Wikipedia using the project for search and wanted to know more. Some had a very clear idea of how they could benefit from Lucene for their NLP projects and wanted to know more on how that fits with Elasticsearch. Others were switching from Solr Cloud and needed some advise on how the systems compare for their particular use case. Others again were using Elasticsearch to analyse log files in a distributed fashion and needed advise on how to implement some feature. There was this one guy from Debian I've known ever since helping at the FSFE booth at Chemnitzer Linuxtage back in 2008 I believe who wanted to know more about Elasticsearch because one of his fellow package maintainers had been volunteered to work on the Elasticsearch RFP (#660826 if you are interested in reading more).

Overall (as every year) a really pleasant experience. What was in particular interesting this year was to meet people I knew only from completely other contexts (CCC events, system administrators, core Apache httpd people). Seems like FOSDEM is not only growing bigger but also more diverse.

The only kind of feedback I would provide is to split some dev rooms by finer grained topics to parallelise and scale even better (the Java, NoSQL and configuration management ones come to my mind first but there probably are others as well - of course again this depends on room availability and actual community members volunteering to submit a dev room related to their project in particular).

I'm glad I'm travelling home by train like last year - not only does that give me time to code and write the blog post you are reading just now, it's also comfortable to get rid of the usual sleep deprivation :)