Denver Museum promotes Linux

Today we went to the Denver Museum of Nature & Science.

They had this very cool exhibit where this huge sphere would light up as different planets and moons:

And they could add text to point out locations:

But even cooler yet was they explained how they did it and they used “Linux”. Usually when they list an operating system, I assume it’s a paid advertisement, but in this case it just said “Linux”.

They did not say what software they used to control the images and rotation …

Universal Subtitles

I found the coolest tool, Universal Subtitles. With Universal Subtitles you can easily transcribe a talk, add subtitles or captions or translate any video on the web.

I’ve been trying to transcribe my Would you do it again for free? talk forever and I always give up – I can’t type fast enough to keep up and manually pausing required more hands than I have. Universal Subtitles let me type and automatically paused and let me catch up whenever the video got ahead of me. Then I could go back and edit, adjust the timing, etc. Now I could also go back and translate the subtitles into other languages.

Universal Subtitles is an awesome tool to help people share videos and presentations in other languages. Not only does it give you the tools you need to do the job, but it makes it very easy to cooperate. So for example, I could transcribe a GNOME video and then someone from the GNOME Hispano community could translate the subtitles into Spanish and then someone else from the GNOME localization team could translate them into their language. Others can go back and make corrections and adjust timing.

(Note that while the Universal Subtitles tool is awesome, transcription is still hard! I was transcribing myself and I still had trouble at times!)

Universal Subtitles is open source software and funded in part by Mozilla through Mozilla Drumbeat.

Disclaimer: I work for Mozilla.

Stormy’s GNOME update: November 12, 2010

This is for my work done as a volunteer.

Reviewed the 9 slidesets that InitMarketing is putting together probono for GNOME. These are slidesets that anyone speaking about GNOME will be able to use and they cover things like applications, history, accessibility, etc. They are starting to look pretty good.

Forwarded emails to the right people. Talked to a few people about the status of projects and gave my opinion and ideas on things I’d been working on (and some that I am still working on.) Among other things this included reviewing the budget, making some introductions with LWN, forwarding the mail about a new Friends of GNOME subscriber, an a11y conversation, etc.

Gave some feedback on Dave Neary’s slides. He’ll be representing GNOME at an event in Korea in a few days.

Missed being on the board list. Now I will have to wait for the board meeting minutes to hear about the stuff that is going on. 🙂

Followed all the great posts about all that happened at the Boston Summit!

Stormy’s GNOME Update: November 7, 2010

This is my update for work done for the GNOME Foundation. For a higher level overview for what I do as the Executive Director, see What do I do as Executive Director of the GNOME Foundation?

F123.org and Mozilla both gave us grants for GNOME accessibility! We are opening contracts for good work with the funding. Thanks to Joanie Diggs for putting together the proposals and plans for the money. Joanie has been posting the opportunities.

Made a list of all the things I work on. I categorized them into things that could wait a while for a new executive director, things that need a board contact and things I thought the board should try to continue to work on in the short term. The board really stepped up to the plate to cover things. I am impressed by the work they are doing and willing to do.

Followed the Desktop Summit mailing list, had several chats with people about different topics, especially Dave Neary who has been following the progress closely and helping out. Reviewed the website and the press release. Helped Claudia Rauch with the text for the sponsorship brochure and proof reading it. Andreas Nilsson made it into a beautiful looking brochure. Claudia and I divvied up the companies we want to contact and I sent out the first request for Desktop Summit 2011 sponsorships to the companies on my list. Germán Póo-Caamaño and Claudia will continue the work.

Along with Paul Cutler met with Litl about the things they are working on related to GNOME. Litl is sponsoring the Boston Summit this weekend.

Worked on a standard document for terms and conditions for GNOME event sponsorship. It’s often a step that’s skipped as it’s work to put it together for each event. My hope is to make it easy. That said, we’ve had very few misunderstandings over the years.

Worked with James Vasile to write some standard letters for logo infringement. Actually, he wrote it, and then with feedback from the board I turned it into a couple of version to be used depending on the situation.

Wrote up a job description for the new executive director. Discussed the hiring process with the board.

Made a quick inquiry about health insurance in case that’s important to the new executive director. The way it works in the United States, it would be expensive. If we have a candidate from another country, we’ll have to research their employment laws.

Was very excited that we announced the interns for the GNOME Outreach Program for Women.  We had a couple of marketing applicants – which was exciting to me – but they faced tough competition from the other projects. They did submit, as part of their applications, a very nicely and uniquely designed brochure and a website of screenshots among other things. Marina Zhurakhinskaya did an awesome job putting the whole Outreach Program together from encouraging applicants to working with all of the potential mentors to putting out the press release. Thanks to to Google and Collabora for enabling us to accept so many awesome candidates!

Published a wiki page of the advisory board member responsibilities. It’s something every new advisory board member asks but something I had always done verbally so it was good to get it in writing.

Followed up with some of the advisory board members that have missed a few meetings. Most of them have just been very busy – some with great GNOME work!

Worked with Egencia, an online travel reservation system, to see if they could help the travel committee and the GNOME community with travel. We believe they can but we are working out the costs now.

Reviewed the annual report. It is ready to be published!

Gave my feedback about the Grace Hopper Conference Open Source track. I hope they do it again!

Wrote my rough draft of CiviCRM requirements. Passed the task off to Rosanna. She will work with the sys admin team and a consultant to get them implemented.

Attended the GNOME Foundation IRC meetings. Two this month! Was impressed by the attendance and the discussion.

Talked to Canonical about Unity. They plan to continue to work with and support GNOME.

Got the LWN agreement officially signed. They gave us an awesome offer and all Friends of GNOME subscribers will get an LWN subscription.

Attended the Boston Summit. Great job by John Palmieri on organizing it again! Got to meet a see a lot of people in person. Had a lot of conversations about potential candidates for the executive director job. Attended the board meeting which was very productive. Led the Friends of GNOME planning session. Lots of great plans with a great team working on it! Jason Clinton, Joey Ferwerda, Og Maciel, Vincent Untz and Jeff Fortin. Many others participated and gave feedback like Heidi Ellis and Brian Cameron and Vinny. And obviously there are others on the team that weren’t here who will help out as well!

GNOME was invited to a Samsung open source conference in Korea. Dave Neary will be representing us and speaking. Others are welcome to attend.

Pinged teams about the quarterly report. Set up a new process where people submit their reports to the wiki.

Made some substantial edits to the hackfest wiki pages to include other events and to clarify the parts of the process where we’ve gotten the most questions.

Floated the idea that the Foundation hire a part time event manager to help with hackfests and other events. Had several discussions about what that person might do and be funded and most importantly how the position might interact with the travel committee. No decision made.

Excited that the GNOME Event Box has a new home for a while while Christer Edwards gives it some tender loving care. He’s used it a few times and has some ideas for improving it.

Worked with InitMarketing on some slide presentations they are making for GNOME advocates to be able to use. They are looking good.

Followed up with Friends of GNOME “adopt a hacker” hackers and the post cards they’ve been sending out. Everyone wants to continue even if the numbers are going to ramp up soon!

Had some conversations about the GNOME Ambassadors. Plan to invite mentors to join as well.

Talked to Jim Herbsleb from Carnegie Mellon about work they are doing to research how communities work and how we can learn from them and make them more effective. One idea was to do a joint survey to help set Foundation goals. Germán Póo-Caamaño will be following up.

Held the GNOME Advisory Board Meeting. We discussed moduleset reorgnization, GNOME Asia and the Boston Summit.

Attended board meetings, met with Rosanna, met with Brian.

Took some vacation to visit my parents.

What’s next in GNOME’s future?

The thoughts and ideas in this post are mine and not necessarily representative of what the GNOME Foundation thinks or plans to do.

Canonical will be shipping Unity as the default desktop for Ubuntu 11.04. It’ll still be GNOME technologies underneath, GNOME applications will run on it and it’s still optimized for GNOME, but it won’t be the GNOME shell. Not the traditional GNOME shell that we all know and love nor the new GNOME Shell coming out in GNOME 3.0.

Disappointing News

Many developers were really disappointed to hear that Unity will be the default shell on Ubuntu. Some are disappointed because they don’t like Unity. Others are disappointed because they feel like Canonical is doing its own thing instead of working with the greater GNOME community to reach a compromise that works for all.

I understand. We’ve put a lot of work into GNOME Shell, our next big thing, and Canonical is saying that it’s not the best thing for their users. It’s disappointing because we are excited about our new plans and expect lots of users to enjoy them. And we rely on our distribution partners to get GNOME into the hands of users, so we were expecting Canonical to help us in that. We also expected Canonical to push for any different user interfaces they wanted within our community, not to design them and announce them independently. In a sense it feels like a child who’s decided to move out of the house. We thought they were going to stay with us forever and listen to our wisdom and instead they’ve told us they’ve learned from us, they like some of what we are doing and they have grand plans for the future. They plan to use some of what we work on (like kids come home for some holidays) but they plan to do their own thing too. Perhaps they’ll make mistakes that have been made before or perhaps they’ll do something grand.

Trying New Alternatives

The beauty of open source software is that they can decide to try something new, without convincing all of us to do it too. And they aren’t forking the project. They’ll still be using a lot of GNOME technologies – the same ones we are using – with just a different shell on top.

In a way, it’s not all that different from what Moblin and Maemo did. They used GNOME technologies with a different shell. We were ok with that because they were expanding into new markets – netbooks and tablets – and because it didn’t seem like a step away from GNOME but a step forward with GNOME. Canonical’s move with Unity is similar. Except that they aren’t starting from scratch, they are moving from a traditional GNOME desktop to Unity. So we feel the change more.

Changing Open Source Ecosystem

I’d also say we are seeing a change in the open source ecosystem here.

On one hand, we are getting more companies joining us that know very little about open source or who have interacted very little with open source communities – device manufacturers for example. We have been actively working on how best to get them involved in the our community in order to improve our project and in order to ensure that they have a good experience with open source software. We want to be sure that they use it in a way that doesn’t require them to do lots of rework every time we update our product.

On the other hand, we have companies that have been using open source for a long time and are developing their own ideas for what works. We aren’t always going to agree with them. For example, Canonical believes copyright assignments will benefit open source software. The GNOME community feels copyright assignments are potentially detrimental to free software projects. But while we don’t agree, we need to find a way to best work together.

What’s next?

Canonical has a lot of work to do, but I assume they know that and I won’t presume to tell them how to do it other than to encourage them to continue to work with us on the GNOME technologies they use. I do wish them the best of luck. As one of GNOME’s partners and as a company that gets open source software into the hands of users, I hope they succeed.

In GNOME’s case, I think we need to understand what companies are looking for from us and how we want to position and brand ourselves.

What do we call projects that use GNOME technologies but aren’t a GNOME desktop? What if it’s a device that has no screen? Or a small device like a smartphone? Or a full desktop distribution? Do we want them to be GNOME branded? If so, how do we want them to be GNOME branded?

What do we want to focus on? Awesome technologies that can be used and pieced together independently? Or an awesome desktop that solves a particular problem? Or a set of user interfaces that solves a set of problems? Right now I think we are working on one awesome desktop that we hope solves lots of problems. But it’s unlikely that one desktop is going to work for a huge set of diverse people. For example you might have a developer with two 24″ screens or a student with an 8″ netbook or a mom with her smartphone. Either GNOME needs to develop solutions for all of those or they need to enable others to do so. And we need to figure out what that means for the project and how we want to brand ourselves.

We also need to continue to work on better integration between the desktop and the web. While both GNOME Shell and Unity say they are addressing the way people work today with the web, there’s still a huge gap between the applications I run on the web and the ones I run on my desktop. They don’t seemlessly integrate. Email is the best example of how things could work. Most web email services and most desktop email clients integrate very well these days. But calendars, contacts, banking systems, recipe management systems, etc. all have a ways to go.

We are doing the groundwork to enable that integration between the desktop and the web in projects like GNOME Shell and WebKitGTK+ and many other projects. There’s still work to be done to maximize the entire user flow including the 7 applications they have open on their desktop and the 15 tabs the currently have open in their browser. Fortunately we have many smart people working on it.

Over 106 companies have contributed to GNOME and over 3500 individuals have made contributions. While we may have lost a distribution channel for GNOME Shell, Canonical will still be using and building with many GNOME technologies and working with the GNOME Foundation. And we still have all of our substantial technical resources working on GNOME Shell and other GNOME technologies.

Time, and our strategy, will determine what the free and open source software user interfaces of the future look like.

Forking an open source project: regaining internal motivation

Can forking a free software project enable you to regain your internal motivation to work on a project? My current theory is that if you work on free software, then you get paid to work on it and then you get laid off, that you would work on a different project. Because the first one is no longer good enough to get paid, then it must not be good enough to work on for free.

If my theory is correct, then I think there’s a great trend going on. Ex-employees are getting around this mental block by blaming the failure (the fact that they can’t get paid to work on it anymore) on the company’s strategy and forking the project to create a new one that they can then justify working on.

One of the strengths of open source software licenses has been that you can fork the project. If at some point in the future, you don’t like what the project is doing, you can take your copy of the code and go do your own thing. Many have argued that it’s that right to leave that makes people work hard to get along. Nobody wants to fork a project is the theory.

Recently most of the forks we’ve seen have come from ex-employees who are unhappy with the direction their previous employer is taking the project.

For example, take Mandriva/Mageia. Part of the Mandriva community, including ex-employees of the company, is forking Mandriva and creating Mageia, a new Linux distribution.

Their website doesn’t say exactly why they are forking but says they no longer trust the company’s motivations. The move seems to be prompted by layoffs:

Most employees working on the distribution were laid off when Edge-IT was liquidated. We do not trust the plans of Mandriva SA anymore and we don’t think the company (or any company) is a safe host for such a project.

Certainly I can see how people who have been laid off would no longer trust the company.

It does look like Mandriva is restructuring to give  more power to their community. However, I doubt they will reverse their decision to move the desktop development to Brazil. In addition to having lots of great free software developers in Brazil, I bet development costs are much cheaper in Brazil.

In the mean time, the ex-Mandriva employees have created a project worth working on for free, Mageia. Something they care about and can invest in, an independent, community run distribution with a community and an associated nonprofit organization.

I wish Mageia the best of luck with their project and I wish Mandriva the best of luck with their company. I think they will both solve different problems in different ways. And I’m really glad that the Mageia will continue working on what they love even if they are not currently getting paid to do that. Their project is worth it.

How do I raise enough money to work on my project full time?

“How do I raise enough money to be able to spend all my time working on my favorite free software project?” is a question I hear often.

I have a few ideas and I’m very interested in hearing others as I think the world would be a better place if we all could afford to do work we loved and thought useful.

  1. Focus on the difference you’d make. First off, I wouldn’t approach it as “I need to raise money to pay myself.” Unless you are raising money solely from people that love you, whether or not you get paid is probably not going to sway them one way or the other. You need to tell them what $100,000 a year would do. How would your project be great then? Who would it help? How would it make the world a better place? How would it help this particular type of sponsor?
  2. Believe it. You need to truly believe your project would benefit from the money and your work. If you aren’t convinced, you won’t convince anyone else.
  3. Figure out how much you need. It helps to have a goal. Would you quit your day job if you had $20,000 in funding? $100,000? $200,000? (Don’t forget costs like health care, vacation time, etc.)
  4. Identify different types of sponsors. Are you going to raise money from developers? Or software companies? Or philanthropic grant givers? Also think about how much money that type of sponsor is likely to give. Be realistic. Maybe they gave a project $100,000 once but they gave five other projects $10,000. You are probably going to get $10,000 if you get anything. Then figure out how many sponsors you’ll need. Figure out where those people are and how you are going to get introduced to them.
  5. Create a pitch. You need a really good web page, a good email, an elevator pitch and unfortunately, you probably need a slide deck too.
  6. Tell the world. Don’t ask everyone for money. But tell everyone about your project and what your goals are. (Hint: your goal is not to raise money but to make your project better. The money is a means to an end.) Use your elevator pitch. Listen carefully to their questions, their skepticism, their ideas. Evolve. Make your pitch better. Figure out how to pitch it to different types of people.
  7. Sell your project. Don’t forget to talk about your project. You aren’t just asking for money, you are selling the potential of your project.
  8. Collect stories. Studies have proven that people are willing to give more money to save one child identified by name and ailment than they are to save 100 kids. Personal stories are moving. Find a couple of stories of how your project has made a difference.
  9. Learn about them. You are not going to get any money from someone whom you don’t understand. Know them, know their business, know what they care about, know how they view you.
  10. Work with an organization that can help. For example, maybe you want money to work on your favorite project and you found companies that are willing to sponsor it but they don’t want to manage it. Would they be willing to funnel the money to you through a nonprofit organization that also supports your type of project?
  11. Ask. Talk to lots of potential sponsors, ask them for money, apply for grants, look for opportunities. If you don’t ask for the money, you will never get it.

What else would you recommend?

P.S. If you are looking to raise money to work on GNOME, please consider the GNOME Foundation your ally.

Putting all the Hackfest pieces together

Planning a hackfest is not an easy process. You need an:

  • organizer – someone willing to put some time into making the whole thing happen
  • topic – what are you going to be hacking on, what do you hope to accomplish
  • attendees – this is usually a particular group of people that work on a specific project or team
  • date – have you ever tried to schedule a multi-day meeting with multiple people? Agreeing on a week can be really hard.
  • place – a place with affordable lodging and food with a comfortable place to hack with great internet. Preferably some place easy and cheap to travel to.
  • sponsors – flying a group of people to the same place often costs quite a bit of money

Luckily we’ve had people and companies willing to invest the time and resources to make this happen. During the past year we’ve had a record number of very productive hackfests and we have even more coming up!

And we have more opportunities! Not only are a lot of teams looking to have hackfests in the near future but we have people offering up venues!

  • Dave Richards from the City of Largo is interested in hosting a hackfest. Many of you know Dave from his participation in the Boston Summit. The City of Largo is a big GNOME fan – they use a lot of thin client solutions.
  • Daniel Siegel has once again offered up Bolzano and the Free Software Center of South Tyrol as a GNOME hackfest location in conjunction with their annual event in November. It’s a beautiful location and we’ve had several successful GNOME hackfests there over the years like the Zeitgeist one. This year all of the groups that I’ve contacted can’t make the dates work, so if you know of a team looking for a venue, this might be right for you!

So if you are interested in organizing a hackfest, please let us know. The GNOME Foundation is here to help – we can help find sponsors, venues, mentors, checklists, etc. The Board of Directors have even offered to act as mentors for any one planning a hackfest!

Words are important – just not always the way you think

Recently I met someone who insisted on describing every department in his organization, all the acronyms and what they stood for. By the time he got around to describing how this whole thing related to me, he had lost my interest. (And I tried hard to hang in there!) He had given me too many irrelevant terms that didn’t relate to me.

We focus a lot in the free software community about what words we use: free software, open source software, free and open source software, …

When using words we should think not only about the meaning of our words but also about our audience. And what we want to teach them.

You don’t teach kids about magenta, mauve, carmine, you teach them about red. Then later you teach them the shades. And, unless you’re my grandfather, you are unlikely to teach them about magenta, mauve and carmine unless it comes up in a scene, in a story.

I’ve been talking about “web services” for a while and people often immediately tell me I’m using the term too generally and start defining web services versus SaaS versus online applications versus … While I think that’s important in some conversations, I think if your audience is only vaguely familiar with the term “web service” and has never heard of “SaaS”, you’ll lose them before you start if you insist on defining and using a whole bunch of new terms. (But I do agree that you should use each term appropriately.)

When you talk to someone who has said “open source software” for the past 10 years, and you use the term “free software”, they will likely think you are talking about something else. Something that is not open source software nor free software as you think of it. If you really want to teach, focus on telling your story rather than teaching a vocabulary lesson.

If you start out by defining terms, you’ll lose your audience. You need to explain meaning by either showing or telling stories.

So if free software versus open source software is important to you, tell as a story where the difference is clear. If web services versus SaaS is important, tell a story or give examples where the two are obviously different.

Tell stories, don’t lecture. (And yes, this post could use a few more stories and bit less lecture!)

10 skills to master to get things done online

I’ve recently watched a few people struggle to get things done in online projects. I’ve written and spoken on 12 tips for getting things done in the open source community but now I see that people also need to learn how to work with mailing lists and virtual teams.

Skills you should master if you plan on working in a virtual environment. I’m interested in any other skills you’d add to the list.

  1. Master your email. You will get a lot of email. There are few in person meetings and there’s a large group to coordinate, so email is the most popular method of communication. Email will become a knowledge base. You need to be able to handle hundreds of emails a day without complaining that they are too many. (You don’t want to be cut off from the knowledge base do you?)
    There are lots of ways to master managing your email. Here are a few of the most common:

    • Touch each email once. If you read it, think about what you need to do with it and do it right then. If it’s something that requires action outside of email, add an action item to your todo list and then tag the email or file it in a special folder. Get it out of your inbox.
    • Use a threaded email client. It’s much easier to catch up on conversations if you can read the whole thread easily at once.
    • Use filters. Many people filter mail from different lists or about different topics to folders. (I personally do not do this. I find I never look at them if I do this.)
    • Dedicate certain time periods to checking email. I spend the first couple hours of every day responding to email. I don’t look at it as “doing email” but rather as communicating and following up with people.
    • Research and try. There are lots of methods and tips for dealing with incoming email. Try a few of them and figure out what works for you.
  2. Learn online tools. You should know how to use mailing lists, IRC, Skype, Twitter, IM, wikis, etc. Each team will use a different set of tools, but you should know the basics of most of them. That way if someone says, let’s have an IRC meeting in a hour, you won’t be googling “IRC” to figure out how to join at the last minute. Or looking for a headset in order to join a Skype call.
  3. Know where to find things. People that work online usually deal with a lot of information. Learn how to search your email archives effectively, how to search the mailing list archives, where the project stores documents or information online and how to search. If you need to ask for information, also ask how the person found it. Often they are simply searching for it. Do not ask for information that you can find easily yourself. Above all, do not ask for the same information twice! If you asked for it and got it, you should be able to find it again. Feel free to ask someone how they found the answer to your question. I learn a lot that way.
  4. Observe how things get done. Every virtual or online team is different. Watch how things get done. Do people present ideas before they are done? Wait for consensus? Present final products for review? If nobody ever responds to your email, it’s likely you are not following the project’s culture.
  5. Be prompt. With people working in different timezones and with different priorities, it’s important to respond to emails and to finish action items promptly. Each delay seems to multiply across the project.
  6. Keep the group informed. If you have a discussion off list, be sure to let the rest of the list know. Don’t be afraid to have the discussion on the list. If you make decisions or agree to something on the group’s behalf, be sure to let the rest of the group know.
  7. Know when to take it off list. Sometimes it’s best to have a discussion offlist first and then tell the group the outcome. For example, if you think your idea is controversial or too vague, you might want to run it by a few trusted people first. But remember, to get buyin and build consensus, some of the discussion has to happen on the list – it can’t be all polished decisions!
  8. Rethink conference calls. If you have conference calls, make sure everyone has access to good technology and make sure everyone is on the phone, not just some people. I think Nat’s Everyone Dials In policy is an excellent one. Also be aware that conference calls are particularly difficult for people that have to dial an international number to join and for people who’s first language isn’t English. While you may think conference calls are the most effective way to get things done, if half the team can’t hear or communicate well, IRC may be a much better choice.
  9. Learn how to read silence. Sometimes you’ll post a great idea or a question to the mailing list and nobody responds. Does that mean nobody liked your idea? Or that they couldn’t understand it? Or that they are all busy on the release that’s going out the day after tomorrow? In the absence of body language, you will have to be more aware of everything else that is going on.
  10. Know what’s been done. When you join a project you should spend some time observing, asking questions and reading the archives. If you suggest a multitude of projects that already exist or have already been proposed, people are going to think you aren’t willing to learn the project.
  11. What else would you add?

For suggestions on how to get things done in virtual teams, see 12 tips for getting things done in the open source community.