"Anything which is physically possible can always be made financially possible; money is a bugaboo of small minds." --Robert A. Heinlein, The Moon Is a Harsh Mistress
We are hoping to encourage other companies to take an organized approach to open source contributions. That is why we, from the day one, decided to document our endeavors in creating the concept and scope for this program, defining the goals, trying to get key people interested and involved, selecting and arranging the various activities that flesh out the concept… all that.
Some of this learning might come in handy even if your program does not deal with open source.
This is the current summary of the gathered information. We are planning to add a program timeline, when we finally reach an agreement on its visual design.
It is essential that you start by defining your motivation for having the program.
Why do you consider it important to have an open source program? How will it be beneficial to your company? What would you like to change?
It is also essential that you don’t spend too much time on this phase. Consider your company culture and you should find what you need right there. Listen to your people. Listen to people in general. Sit down and have a think.
Here our motivation:
Yeah… I am sure you’ll agree we didn’t over-engineer this step! The first statement should be self-evident, if you are considering a program like this. If you do not subscribe to the ideology at all, I suppose you’re reading this to get to know your enemies. Hi there! Pistols at dawn?
The second statement might benefit of some background. The core business of Futurice is to develop and maintain digital services for our customers. The emphasis here lies strongly on the last words; for our customers.
In a customer project our people can often find great pride in what they are creating. Futurice has a very open culture and is undeniably a very good place to work. However, this line of business, combined with our ambition in recruitment, results in a specific challenge.
Futurice seeks and attracts ambitious and friendly people who want to be very good at what they do. Many of us dream of making the world a better place. Our daily project work may, or may not allow us this luxury. Time outside the project work is quite limited. How to help our people to do good, while respecting the business realities?
Our program attempts to address this challenge by finding ways to help our people, as part of their daily work, to make the world a better place.
Program goals. MEASURABLE goals! The cornerstone of any sane company development effort, surely no exceptions!
Or are there? Measuring the circumference of your head is trivial, assuming you have the tools. Measuring the project team agile velocity as story points may not be easy, but it’s definitely doable, at least with some time and thought. Measuring the effect of the chosen account strategy to company revenue and growth is damn difficult, but sure, you’ll get some numbers that you can whip out in that board meeting…
Now, defining measurable goals for a program that is quite abstract in nature… You can spend forever and a half on that, while the frustration grows, shadowing your vision. You might end up giving up on the entire program. We got close to that point after the first three months.
Why do I call the program abstract? Well, since the generated value (at least in the early stages of the program) is largely on how people feel about their company, not to mention the philosophical argument of this “being the right thing to do”, getting any statistically solid measurements is a challenge.
We did not give up on the program, but we did give up on the goal measurability – for now. Here are the abstract goals we work towards:
We have also identified these two to likely be very relevant in the future:
We do not claim that there could not be proper measurable goals, just admit that we are unable and somewhat unwilling to define them yet. Since we are exploring new territory here, and we have a general agreement that the rewards may be great, it makes sense to take some risk.
After establishing that the proper ROI calculations will be in the (hopefully) distant future, we agreed with our top management sponsor that we can spend a certain amount of time (read: money) on this program during the first six months (H1/2014). Like so:
Effort estimate for 2014/H1: 60 work days + separately agreed extra expenses
If at the end of that period we cannot make a plausible argument on how at least some of these goals have been advanced, or present alternative acceptable goals that have, oh well. Bury the program or pivot away.
The 10 monthly work days covers the work of the core program team. On top of that there can be plenty of extra expenses, which are negotiated case by case. For these investments measurable goals could apply; even measurable return of investment.
That’s a mixed bag. We achieved moderate success on some goals, but fell short on others. Yet the overall feeling was that we’re on the right track, so we got a six month extension to the end of the year. More information about the particulars later in this wall of text, while we touch upon the activities. Having that timeline right about here would be nice, Matias, if you’re reading this?
We started with an initial minimal line-up to get the program running. The required competence was identified by considering the interest groups; who will the program communicate with?
We combined this with the forms of communication. While I (Teemu) sit alone in a meeting room working on this text, my colleague Matias is waving his hands at the company cafeteria, talking with a whole bunch of people. This is playing to our strengths.
In addition it is necessary to have someone with credibility and enthusiasm for the company strategy on board.
Our initial line-up, as it was presented in our official internal program presentation
We quickly found we will need a designer to help us. Satu helped us to design this site before we lost her to another company ;_;
One justification for selecting a small part-time team is the fact that this is meant to be a program instead of a project. The point of this exercise is not in the optimal use of resources; we are not trying to get as much as possible done with as few as possible people.
Instead the program should grow by getting as many people as possible involved in different ways.
Some activities carried out under the umbrella of the program will require more concentrated effort. A good example is our Summer of Love initiative, for which Futurice hired a talented and enthusiastic dude for an entire summer.
I am pretty sure a program like this will not succeed, if you try to run it as a clockwork waterfall project. You want to have organic development. That is a fancy way of saying we have a lot of planning challenges. It’s pretty damn hard to guess what is feasible, what might work. So we want to try out a lot of stuff, preferring to fail fast!
Some tool quickly becomes necessary to keep track of the ongoing and overlapping actions, and people, but this is a basic project management challenge. We chose Trello because we like it, and it seems good for this program management purpose as well. Especially if we would update it at least once a week, removing or archiving tasks that seemed relevant in the past, but for a reason or another never got done.
Having totally failed in this, it’s a bit of a swamp, and I feverishly update it every few months just before a “big meeting” with Mikko, our supervisor and thus-far-benevolent top management sponsor.
Getting feedback is essential, and a good way to go about that is to frequently present your program to different interest groups. It also helps to groom the scope of the program. Keep track of what aspects of the program you talk about. The ones you rarely every touch upon… or find outright embarrassing… well, take them out back and bury them.
Also if you concentrate on your presentations and give them frequently, you will learn to be very good at it. This will greatly help in getting people interested and keeping them so. We decided to present at least once a month to a larger audience. During the first six months, we have failed this miserably, and it shows. Right now, when I am asked “so what about that program of yours?”, I fail to produce a coherent response. I ramble, end up sounding insecure at best, uninterested at worst. Not cool; we seriously need to get our shit together in this department ._.
The program can have a fancy concept and an idealistic manifesto but it will not amount to anything, unless you actually do stuff. Walk the walk, and all that. Substance!
It’s been easy to think of stuff to do. Quite quickly we realized that it’s a good idea to categorize our activities; the categories being such that they reflect the program goals.
Using the color coding in Trello we can then see at a glance what we would otherwise just suspect deep within – we are mainly concentrating on the Fun and Easy Stuff, and making much less headway with the Soul-wrenchingly Difficult Stuff. Our categories look like this. They haven’t changed since we first defined them:
The categories are perhaps not self-evident so here goes, with actual example activities. Check the yet non-existent program timeline (MATIAS!!) to get a better understanding of the whole.
Summer of Love was our sub-program for publishing our fancy internal tools and services. Futurice has done quite a bit of internal development to make working efficient and fun. These we want to share. You can read more on Summer of Love at http://www.spiceprogram.org/summer-of-love/.
Fun and games
We brewed a Free Beer variant. That’s a beer with an open source recipe. The original Free Beer initiative can be found at [LINK]. Our endeavour has been documented at http://www.spiceprogram.org/freebeer/.
Some time ago Futurice created apps for Ruisrock, a large rock festival held annually in Finland. They were paid for by Fonecta Oy, a Finnish online media company. Fonecta kindly allowed us to open source the apps. We arranged a hackathon where students from several universities helped us transform the apps to be fit for publishing.
Here’s a good read, a blog post by the ‘customer’ from the festival organization: The project can be found here http://blog.futurice.com/designing-a-festival-app-a-hackathon-experience/
Creating this site might count as an education activity, at least we have learned a lot. Hopefully there’s useful information for others as well.
Networking and Collaboration
We suck! We haven’t really done anything here, even though it’s supposed to be in the core of our program.
Guidelines and Policy
We have been dancing around this stuff because it’s hard. But finally we’re making progress! Right now we’re attempting to establish several things:
There will be a proper article on these as soon as we have something concrete.
Accounts and Sales
We have created contract clausules allowing us to contribute fixed and enhancements to OSS projects that we use in our customer projects. Several of our wonderful customers have already accepted these terms! You can find the clausules (please make use of them!) and more information at http://www.spiceprogram.org/contracts/.