mozilla

Mozilla Nederland LogoDe Nederlandse
Mozilla-gemeenschap

Abonneren op feed Mozilla planet
Planet Mozilla - http://planet.mozilla.org/
Bijgewerkt: 13 uur 12 min geleden

Mozilla Reps Community: Reps Weekly Call – February 26th 2015

vr, 27/02/2015 - 14:10

Last Thursday we had our weekly call about the Reps program, where we talk about what’s going on in the program and what Reps have been doing during the last week.

serious-funny

Summary
  • RepsIDMeetup
  • Alumni status and leaving SOP
  • New mentors coming soon
  • GMRT event Pune
  • Teach The Web Talks
  • FOSS Asia
  • BuddyUp
  • Say Hello Day

Detailed notes

AirMozilla video

Don’t forget to comment about this call on Discourse and we hope to see you next week!

Categorieën: Mozilla-nl planet

Kaustav Das Modak: Firefox OS for everyone

vr, 27/02/2015 - 13:59
While a good number of events around Firefox OS have focused on helping developers understand the technology behind it, there has been very little effort in helping people understand Firefox OS from a non-technical and non-developer perspective. I’ve started a series of events titled “Firefox OS for everyone” to solve this gap. The content has […]
Categorieën: Mozilla-nl planet

Pierros Papadeas: FOSDEM 2015 Bug sprint tool

vr, 27/02/2015 - 13:58
“Reclama” Experiment report Intro

FOSDEM 2015 is a premier open source developers’ event in Europe. Mozilla is heavily participating in the event for over 10 years now, with booths and dev-rooms. This year the Community Development team decided to run an experimental approach on recruiting new contributors by promoting good-first bugs.

Scope

Given the highly technical nature of the audience in FOSDEM 2015, the approach decided has a straight-forward promotion of bugs and prizes for them, for people to track and get involved.

Following sign-off meeting with the stakeholders (William Quiviger, Francisco Piccolini and Brian King) the specifications agreed for the first iteration of the experiment were as follows:

  1. A straight-forward interface displaying hand-selected good first bugs, ready to be worked on
  2. Next to bugs, prizes should be displayed.
  3. Viewing from mobile devices should be also accounted for.
  4. Public access to all content. Ability to edit and add events on selected accounts (hardcoded for v1)
  5. The interface has to be properly Mozilla branded (high visibility and promotion in an event)
  6. It needs to be future-proof for event to come (easily add new events and/or bugs after deployment)
  7. Solution URL should be short and easily memorable and digestible.
  8. It needs to be delivered before the start of FOSDEM 2015 ;)
  9. A report should be compiled with usage statistics and impact analysis for the experiment
Development

Given the extremely short timeframe (less than 3 days), ready, quick or off-the-shelf solutions were evaluated like:

  • An online spreadsheet (gdocs)
    • Not meeting requirements #3, #5, #6, #7
  • A bugzilla query
    • Not meeting requirements #2, #7, #6
  • A scrappy HTML plain coded solution
    • Not meeting requirements #4, #6

Thus, given the expertise of the group it was decided to create a django application to meet all requirements in time.

Following 2 days of non-stop development (fantastic work from Nikos and Nemo!), testing and iteration we met all requirements by developing the app which is codenamed “reclama” (Italian -shortof-  for claim).

Code can be found here: https://github.com/mozilla/reclama

Screen Shot 2015-02-27 at 14.57.26Deployment

In order to meet requirement #7 (short and memorable URL) and given the timeframe, we decided to acquire a URL quickly ( mozbugsprints.org ) and deploy the application.

For usage statistics, awstats was deployed on top of the app to track incoming traffic.

Usage statistics

During the weekend of FOSDEM 2015, 500 people with almost 5000 hits visited the website. That’s almost 10% of the event participants.mozbugsprint-stats

Saturday 31-Jan-2015 traffic analysis

mozbugsprint-saturdayBooths and promotion of the experiment started at 9:00 as expected. With mid-day (noon) pick which is consistent with increased traffic in booths area of the event.

Traffic continues to flow in steadily even after the end of the event, which indicates that people keep the URL and interact with our experiment substantial time after the face to face interaction with our booth. Browsing continues through the night, and help might be needed (on call people/mentors ?) during that too.

Sunday 1-Feb-2015 traffic analysis

mozbugsprint-sundaySecond day in FOSDEM 2015 included a Mozilla dedicated dev-room. The assumption that promotion through the dev-room would increase the traffic in our experiment proved to be false, as the traffic continued on the same levels for day 2.
As expected there was a sharp cut-off after 16:00 (when the final keynote starts) and also people seem to not come back after the event. Thus the importance of hyper-specific event-focused (and branded) challenge seems to be high, as people relate to that understanding the one-off nature of it.

Impact

32 coding bugs from different product areas were presented to people. 9 of them were edited (assigned, commented, worked on) during or immediately (one day) after FOSDEM 2015. Out of those 9 , 4 ended up on first patch submission (new contributors) and 3 received no response (blocked contributor) from mozilla staff (or core contributors).

Recommendations
  • Re-do experiment in a different cultural environment, but still with related audience, so we can cross-compare.
  • Continue the experiment by implementing new functionality as suggested by the stakeholders (notes, descriptions etc).
  • Experiment random sorting of bugs, as current order seemed to affect what has been worked on.
  • Submission of bugs to be featured on an event should be coordinated by event owner and related to event theme and topics.
  • A/B test how prize allocation affects what bugs are worked on.
  • Expand promotional opportunities throughout the event. (booth ideas?)
  • On call developers on promoted bugs would eliminate the non-answered section of our bugs

PS. Special thanks to Elio for crafting an excellent visual identity and logo once again!

Categorieën: Mozilla-nl planet

Gervase Markham: An Encounter with Ransomware

vr, 27/02/2015 - 12:31

An organization which I am associated with (not Mozilla) recently had its network infected with the CryptoWall 3.0 ransomware, and I thought people might be interested in my experience with it.

The vector of infection is unknown but once the software ran, it encrypted most data files (chosen by extension) on the local hard drive and all accessible shares, left little notes everywhere explaining how to get the private key, and deleted itself. The notes were placed in each directory where files were encrypted, as HTML, TXT, PNG and as a URL file which takes you directly to their website.

Their website is accessible as either a TOR hidden service or over plain HTTP – both options are given. Presumably plain HTTP is for ease for less technical victims; Tor is for if their DNS registrations get attacked. However, as of today, that hasn’t happened – the site is still accessible either way (although it was down for a while earlier in the week). Access is protected by a CAPTCHA, presumably to prevent people writing automated tools that work against it. It’s even localised into 5 languages.

CryptoWall website CAPTCHA

The price for the private key was US$500. (I wonder if they set that based on GeoIP?) However, as soon as I accessed the custom URL, it started a 7-day clock, after which the price doubled to US$1000. Just like parking tickets, they incentivise you to pay up quickly, because argument and delay will just make it cost more. If you haven’t paid after a month, they delete your secret key and personal page.

While what these thieves do is illegal, immoral and sinful, they do run a very professional operation. The website had the following features:

  • A “decrypt one file” button, which allows them to prove they have the private key and re-establish trust. It is, of course, also protected by a CAPTCHA. (I didn’t investigate to see whether it was also protected by numerical limits.)
  • A “support” button, which allows you to send a message to the thieves in case you are having technical difficulties with payment or decryption.

The organization’s last backup was a point-in-time snapshot from July 2014. “Better backups” had been on the ToDo list for a while, but never made it to the top. After discussion with the organization, we decided that recreating the data would have taken much more time than the value of the ransom, and so were were going to pay. I tried out the “Decrypt One File” function and it worked, so I had some confidence that they were able to provide what they said they were.

I created a wallet at blockchain.info, and used an exchange to buy exactly the right amount of Bitcoin. (The first exchange I tried had a ‘no ransomware’ policy, so I had to go elsewhere.) However, when I then went to pay, I discovered that there was a 0.0001BTC transaction fee, so I didn’t have enough to pay them the full amount! I was concerned that they had automated validation and might not release the key if the amount was even a tiny bit short. So, I had to go on IRC and talk to friends to blag a tiny fraction of Bitcoin in order to afford the transfer fee.

I made the payment, and pasted the transaction ID into the form on the ransomware site. It registered the ID and set status to “pending”. Ten or twenty minutes later, once the blockchain had moved on, it accepted the transaction and gave me a download link.

While others had suggested that there was no guarantee that we’d actually get the private key, it made sense to me. After all, word gets around – if they don’t provide the keys, people will stop paying. They have a strong incentive to provide good ‘customer’ service.

The download was a ZIP file containing a simple Windows GUI app which was a recursive decryptor, plus text files containing the public key and the private key. The app worked exactly as advertised and, after some time, we were able to decrypt all of the encrypted files. We are now putting in place a better backup solution, and better network security.

A friend who is a Bitcoin expert did do a little “following the money”, although we think it went into a mixer fairly quickly. However, before it did so, it was aggregated into an account with $80,000+ in it, so it seems that this little enterprise is fairly lucrative.

So, 10/10 for customer service, 0/10 for morality.

The last thing I did was send them a little message via the “Support” function of their website, in both English and Russian:

Such are the ways of everyone who is greedy for unjust gain; it takes away the life of its possessors.

Таковы пути всех, кто жаждет преступной добычи; она отнимает жизнь у завладевших ею.

‘The time has come,’ Jesus said. ‘The kingdom of God has come near. Repent and believe the good news!’

– Пришло время, – говорил Он, – Божье Царство уже близко! Покайтесь и верьте в Радостную Весть!

Categorieën: Mozilla-nl planet

Mozilla Reps Community: Impact teams: a new approach for functional impact at Reps

vr, 27/02/2015 - 10:02

When the new participation plan was forming one of the first questions was: how can the Reps program enable more and deeper participation in Mozilla? We know that Reps are empowering local and regional communities and have been playing an important role in various project like Firefox OS launches, but there wasn’t an organized and more importantly scalable way to provide support to functional teams at Mozilla. The early attempts of the program to help connect volunteers with functional areas were the Special Interest Groups (SIG). Although in some cases and for some periods of time the SIGs worked very well and were impactful, they wasn’t sustainable in the long run. We couldn’t provide a structure that ensured mutual benefit and commitment.

With the renewed focus on participation we’re trying to think differently about the way that Reps can connect to functional teams, align with their goals and participate in every part of Mozilla. And this is where the “Impact teams” come in. Instead of forming loose interest groups, we want to form teams that work well together and are defined by the impact they are having, as well as excited by future opportunity to not only have deeper participation but personal growth as part of a dedicated team where colleagues include project staff.

The idea of these new impact teams is to make sure that the virtuous circle of mutual benefit is created. This means that we will work with functional teams to ensure that we find participation opportunities for volunteers that have direct impact on project goals, but at the same time we make sure that the volunteers will benefit from participating, widening their skills, learning new ones.

impact-team-2

These teams will crystallize through the work on concrete projects, generating immediate impact for the team, but also furthering the skills of volunteers. That will allow the impact team to take on bigger challenges with time: both volunteers and functional teams will learn to collaborate and volunteers with new skills will be able to take the lead and mentor others.

We’re of course at the beginning and many questions are still open. How can we organize this in an agile way? How can we make this scalable? Will the scope of the role of Reps change if they are more integrated in functional activities? How can we make sure that all Mozillians, Reps and non Reps are part of the teams? Will we have functional mentors? And we think the only way to answer those questions is to start trying. That’s why we’re talking to different functional areas, trying to find new participation opportunities that provide value for volunteers. We want to learn by doing, being agile and adjusting as we learn.

The impact teams are therefore not set in stone, we’re working with different teams, trying loose structures and specially putting our energy into making this really beneficial for both functional teams and volunteers. Currently we are working to the Marketplace team, the Firefox OS Market research team and the developer relations team. And we’ll be soon reaching out to Mozillians and Reps who have a track record in those areas to ask them to help us build these impact teams.

We’re just at the beginning of a lot of pilots, tests, prototypes. But we’re excited to start moving fast and learn! We have plenty of work to do and many questions to answer, join us in shaping these new impact teams. Specially help us now how your participation at Mozilla can benefit your life, make you grow, learn, develop yourself. Emma Irwin is working on making education a centerpiece of participation, but do you have any other ideas? Share them with us!

Categorieën: Mozilla-nl planet

Tantek Çelik: #IndieWeb: Homebrew Website Club 2015-02-25 Summary

vr, 27/02/2015 - 08:00

2015-02-25 Homebrew Website Club participants, seven of them, sit in two rows for a photograph

At last night's Homebrew Website Club we discussed, shared experiences, and how-tos about realtime indie readers, changing/choosing your webhost, indie RSVPs, moving from Blogger/Tumblr to your own site, new IndieWebCamp Slack channel, and ifthisthen.cat.

See kevinmarks.com/hwc2015-02-25.html for the writeup.

Categorieën: Mozilla-nl planet

Tantek Çelik: Disappointed in @W3C for Recommending Longdesc

vr, 27/02/2015 - 06:47

W3C has advanced the longdesc attribute to a Recommendation, overruling objections from browser makers.

Not a single browser vendor supported advancing this specification to recommendation.

Apple formally objected when it was a Candidate Recommendation and provided lengthy research and documentation (better than anyone has before or since) on why longdesc is bad technology (in practice has not and does not solve the problems it claims to).

Mozilla formally objected when it was a Proposed Recommendation, agreeing with Apple’s research and reasoning.

Both formal objections were overruled.

For all the detailed reasons noted in Apple’s formal objection, I also recommend avoid using longdesc, and instead:

  • Always provide good alt (text alternative) attributes for images, that read well inline if and when the image does not load. Or if there’s no semantic loss without the image, use an empty alt="".
  • For particularly rich or complex images, either provide longer descriptions of images in normal visible markup, or linked from a image caption or other visible affordance. See accessibility expert James Craig’s excellent Longdesc alternatives in HTML5 resource for even more and better techniques.

Perhaps the real tragedy is that many years have been wasted on a broken technology that could have been spent on actually improving accessibility of open web technologies. Not to mention the harrassment that’s occurred in the name of longdesc.

Sometimes web standards go wrong. This is one of those times.

Categorieën: Mozilla-nl planet

Planet Mozilla Interns: Michael Sullivan: MicroKanren (μKanren) in Haskell

vr, 27/02/2015 - 01:18

Our PL reading group read the paper “μKanren: A Minimal Functional Core for Relational Programming” this week. It presents a minimalist logic programming language in Scheme in 39 lines of code. Since none of us are really Schemers, a bunch of us quickly set about porting the code to our personal pet languages. Chris Martens produced this SML version. I hacked up a version in Haskell.

The most interesting part about this was the mistake I made in the initial version. To deal with recursion and potentially infinite search trees, the Scheme version allows some laziness; streams of results can be functions that delay search until forced; when a Scheme μKanren program wants to create a recursive relation it needs wrap the recursive call in a dummy function (and plumb through the input state); the Scheme version wraps this in a macro called Zzz to make doing it more palatable. I originally thought that all of this could be dispensed with in Haskell; since Haskell is lazy, no special work needs to be done to prevent self reference from causing an infinite loop. It served an important secondary purpose, though: providing a way to detect recursion so that we can switch which branch of the tree we are exploring. Without this, although the fives test below works, the fivesRev test infinite loops without producing anything.

The initial version was also more generalized. The type signatures allowed for operating over any MonadPlus, thus allowing pluggable search strategies. KList was just a newtype wrapper around lists. When I had to add delay I could have defined a new MonadPlusDelay typeclass and parametrized over that, but it didn’t’ seem worthwhile.

A mildly golfed version that drops blank lines, type annotations, comments, aliases, and test code clocks in at 33 lines.

<noscript>View the code on <a href="https://gist.github.com/msullivan/4223fd47991acbe045ec">Gist</a>.</noscript>
Categorieën: Mozilla-nl planet

Doug Belshaw: An important day for the Internet

do, 26/02/2015 - 21:40

As I’ve just been explaining to my son, when he’s my age and looks back at the history of the Internet, 26 February 2015 will be seen as a very important day.

Why? The Mozilla blog summarises it well:

We just accomplished something very important together. Today, the U.S. Federal Communications Commission voted for strong net neutrality protections. This happened because millions of people — including many hundreds of thousands in Mozilla’s community — joined together as citizens of the Web to demand those strong protections.

Net Neutrality can be a difficult thing to understand and, especially if you’re not based in the USA, it can feel like something that doesn’t affect you. However, it is extremely important, and it impacts everyone.

Last year we put together a Webmaker training module on Net Neutrality. I’d like to think it helped towards what was achieved today. As Mitchell Baker stated, this victory was far from inevitable, and the success will benefit all of humankind.

It’s worth finding out more about Net Neutrality, for the next time it’s threatened. Forewarned is forearmed.

Image CC BY Kendrick Erickson

Categorieën: Mozilla-nl planet

Air Mozilla: Brown Bag, "Analysing Gaia with Semmle"

do, 26/02/2015 - 21:00

Brown Bag, "Analysing Gaia with Semmle" Title: Analysing Gaia with Semmle Abstract: Semmle has recently added support for JavaScript to its analysis platform. As one of our first major JavaScript analysis...

Categorieën: Mozilla-nl planet

The Mozilla Blog: A Major Victory for the Open Web

do, 26/02/2015 - 19:28

We just accomplished something very important together. Today, the U.S. Federal Communications Commission voted for strong net neutrality protections. This happened because millions of people — including many hundreds of thousands
in Mozilla’s community — joined together as citizens of the Web to demand those strong protections.

This is an important victory for the world’s largest public resource, the open Web. Net neutrality is a key aspect of enabling innovation from everywhere, and especially from new players and unexpected places. Net neutrality allows citizens and consumers to access new innovations and judge the merit for themselves. It allows individual citizens to make decisions, without gate-keepers who decide which possibilities can become real. Today’s net neutrality rules help us protect this open and innovative potential of the Internet.

Mozilla builds our products to put this openness and opportunity into the hands of individuals. We are organized as a non-profit so that the assets we create benefit everyone. Our products go hand-in-hand with net neutrality; they need net neutrality to bring the full potential of the Internet to all of us.

Today’s net neutrality rules are an important step in protecting opportunity for all. This victory was not inevitable. It occurred because so many people took action, so many people put their voice into the process. To each of you we say “Thank you.” Thank you for taking the time to understand the issue, for recognizing it’s important, and for taking action. Thank you for helping us build openness and opportunity into the very fabric of the Internet.

Video message from Mitchell Baker, Executive Chairwoman, Mozilla Foundation

Categorieën: Mozilla-nl planet

Rosana Ardila: Impact teams: a new approach for functional impact at Reps

do, 26/02/2015 - 19:17

When the new participation plan was forming one of the first questions was: how can the Reps program enable more and deeper participation in Mozilla? We know that Reps are empowering local and regional communities and have been playing an important role in various project like Firefox OS launches, but there wasn’t an organized and more importantly scalable way to provide support to functional teams at Mozilla. The early attempts of the program to help connect volunteers with functional areas were the Special Interest Groups (SIG). Although in some cases and for some periods of time the SIGs worked very well and were impactful, they wasn’t sustainable in the long run. We couldn’t provide a structure that ensured mutual benefit and commitment.

With the renewed focus on participation we’re trying to think differently about the way that Reps can connect to functional teams, align with their goals and participate in every part of Mozilla. And this is where the “Impact teams” come in. Instead of forming loose interest groups, we want to form teams that work well together and are defined by the impact they are having, as well as excited by future opportunity to not only have deeper participation but personal growth as part of a dedicated team where colleagues include project staff.

The idea of these new impact teams is to make sure that the virtuous circle of mutual benefit is created. This means that we will work with functional teams to ensure that we find participation opportunities for volunteers that have direct impact on project goals, but at the same time we make sure that the volunteers will benefit from participating, widening their skills, learning new ones.

impact-team-2

These teams will crystallize through the work on concrete projects, generating immediate impact for the team, but also furthering the skills of volunteers. That will allow the impact team to take on bigger challenges with time: both volunteers and functional teams will learn to collaborate and volunteers with new skills will be able to take the lead and mentor others.

We’re of course at the beginning and many questions are still open. How can we organize this in an agile way? How can we make this scalable? Will the scope of the role of Reps change if they are more integrated in functional activities? How can we make sure that all Mozillians, Reps and non Reps are part of the teams? Will we have functional mentors? And we think the only way to answer those questions is to start trying. That’s why we’re talking to different functional areas, trying to find new participation opportunities that provide value for volunteers. We want to learn by doing, being agile and adjusting as we learn.

The impact teams are therefore not set in stone, we’re working with different teams, trying loose structures and specially putting our energy into making this really beneficial for both functional teams and volunteers. Currently we are working to the Marketplace team, the Firefox OS Market research team and the developer relations team. And we’ll be soon reaching out to Mozillians and Reps who have a track record in those areas to ask them to help us build these impact teams.

We’re just at the beginning of a lot of pilots, tests, prototypes. But we’re excited to start moving fast and learn! We have plenty of work to do and many questions to answer, join us in shaping these new impact teams. Specially help us now how your participation at Mozilla can benefit your life, make you grow, learn, develop yourself. Emma Irwin is working on making education a centerpiece of participation, but do you have any other ideas? Share them with us!


Categorieën: Mozilla-nl planet

Air Mozilla: Reps weekly

do, 26/02/2015 - 17:00

Reps weekly Weekly Mozilla Reps call

Categorieën: Mozilla-nl planet

Pascal Finette: What Every Entrepreneur Should Know About Pitching

do, 26/02/2015 - 09:12

The following post is a summary of a series of earlier Heretic posts on the subject compiled into one comprehensive list - compiled by the wonderful folks at Unreasonable.is

Your pitch deck MUST start with a description of what it is that you’re doing. Your second slide (after the cover slide) is titled “What is NAME-OF-YOUR-COMPANY” (e.g. “What is eBay”). Explain in simple English what you’re doing. This is not the place to be clever, show off your extraordinary grasp of the English language or think that your pitch deck is a novel where you build tension and excitement in the first half and surprise the reader in the end.

If I (or any investor for that matter) don’t understand what you are doing in the first 10-15 seconds you already lost me. I know investors who don’t go past slide two if they don’t grasp what the company does.

Simple and obvious, eh? The crazy thing is, I get tons of decks which make me literally go “WTF?!” Let me illustrate the point. Here are two pitches which get it right (names and some product details have been changed):

What is ACME CORP?

  • A unique coffee subscription business…
  • 1) Rare, unique, single-origin coffee
  • 2) Freshly roasted to order each month
  • 3) A different coffee every month, curated by experts
  • delivered monthly through the letterbox.
  • A subscription-only business—sign up online—available for self-purchase or as a special gift

Moving on — pitch #2:

ACME CORP is an E-FASHION club that provides affordable trendy shoes, accessories and PERSONALIZED style recommendations to European Women!

Clear. They are a shopping club focussed on shoes for European women. Crisp and clear. No fancy language. Just the facts.

And now for something different—pitch #3:

ACME CORP is an online collaboration hub and development environment for makers, hobbyist and engineers.

I have mostly no clue what they are doing. Worse — as I actually know the team and their product — this isn’t even an accurate statement of what they are up to. What they build is Github plus a deployment system for Arduinos. Their statement is overly broad and unspecific.

So your first slide (not the cover — your first actual content slide) is the most important slide in your deck. It’s the slide where I decide if I want to see and hear more. It’s the slide which sets the tone for the rest of your interaction. And it’s the slide which forms my first image of you and your company. Spend time on it. Make it perfect. Pitch it to strangers who know nothing about your company and see if they get it. Show them just this one slide and then ask them to describe back to you what your company does. If they don’t get it, or it’s inaccurate, go back and revise the slide until you get it right.

The Team Slide

We all know that investors put their money into teams not ideas. Ideas are cheap and plentiful. Incredible execution is rare. Ideas evolve (yeah — sometimes they “pivot“). Great teams excel at this, mediocre teams fall apart. So you invest into people.

Which means your team slide better be good.

I can’t tell you too much about the composition of your team — as this is highly dependent on your idea and the industry you’re in.

Teams of one are usually a bad sign. If you can’t bring a team to the table when you ask for funding it just doesn’t reflect well on your ability to recruit. Teams that have a bunch of people listed as “will come on board once we can pay her/him a salary” don’t work. People who are not willing to take the risk are employees, not cofounders.

Don’t bullshit when you talk about your team. Sentences such as “X has 10 years of Internet experience” make me cringe, then laugh and then delete your email. Every man and his dog has ten years of “Internet experience” by now. Be honest, tell me what your team did. If your team hasn’t done anything interesting. Well, that’s something you should think about. You won’t be able to hide it anyway. “Y is a Ruby ninja?” I let your teammate speak with one of our portfolio companies for three minutes and I know if he’s a ninja or a backwater coder who still designs MySpace pages for his school chorus. Oh, and by the way: Nobody is a fucking ninja, superstar or what-have-you. Cut the lingo.

Lastly—and this shows your attention to detail — make sure the pictures you use have a common look and feel and don’t look like a collection of randomly selected vacation snapshots. Unless you’re all totally wasted in the shots. That might be funny.

Let’s Talk About Advisors

Typically you add them to your team slide. And most of the time you see something along the lines of a list of names a la “John Doe, Founder ACME Corp.,” sometimes with a picture.

Here’s the deal—advisors provide two signals for an investor:

  1. Instant credibility if you have “brand name” advisors
  2. A strong support network

The first one only works if you have truly recognizable names which are relevant to your field. Sergey Brin works, a random director at a large company doesn’t. The second one is trickier. In pitch presentations I often wonder what those people actually do for you — as often the entrepreneurs either just rattle down the names of the advisors on their slide or even glance over them and say something to the tune of, “and we have a bunch of awesome advisors.”

If you want to make your pitch stronger I recommend you make sure that your advisors are relevant (no, your dad’s buddy from the plumbing shop down the road most likely doesn’t count) and that they are actual advisors and not only people with whom you emailed once. You can spend 15 seconds in your pitch describing the relationship you have with your advisors. (e.g. “We assembled a team of relevant advisors with deep expertise in X, Y and Z. To leverage their expertise and network we meet with them every month for a one-hour session and can also ask for advice via phone and email anytime in between.”)

By the way, there is something to be said about the celebrity advisor. As awesome as it might be that you got Tim Cook from Apple to be an advisor I instantly ask myself how much time you actually get out of him—he’s busy as hell. So you might want to anticipate that (silent) question and address it head on in your pitch.

The Dreaded Finance Slide

The one slide that is made up out of one hundred percent pure fantasy. And yet it seems (and it is) so important. Everybody knows that whatever you write down on your finance slide is not reality but (in the best case) wishful thinking. That includes your investor.

Why bother? Simple. The finance slide shows your investor that you understand the fundamentals of your business. That you have a clue. That he can trust you with his money.

So what do you need to know about your finance slide? As so often in life the answer is: it depends. Here’s my personal take. For starters you want to show a one-year plan which covers month-by-month revenue and costs. Lump costs into broader buckets and don’t fall into the trap of pretended accuracy by showing off precise numbers. Nobody will believe that you really know that your marketing costs will be precisely $6,786 in month eight. You’re much better off eyeballing these numbers. Also don’t present endless lists of minutia details such as your telecommunication costs per month. Show your business literacy by presenting ballpark numbers that make sense (e.g. salaries should come as fully loaded head counts—not doing this is a strong indicator that you don’t know the fundamentals of running a business).

On the revenue side you want to do a couple of things. First of all explain your business model (this is something you might want to pull out on its own slide). Then give me your assumptions—sometimes it makes sense to work with scenarios (best, base and worst case). And then use this model to validate your revenue assumptions bottom-up. If you say you will have 5,000 customers in month three, what does that mean in terms of customer acquisition per day, how does that influence your cost model, etc.

This is probably the most useful part of putting together your financials. It allows you to make an educated guess about your model and will, if done right, feed you tons of information back into your own thinking. Weirdly a lot of entrepreneurs don’t do this and then fall onto their face when, in a pitch meeting, their savvy investor picks the numbers apart and points out the gapping holes (something I like to do—it really shows if someone thought hard about their business or if they are only wanna-be entrepreneurs).

And then you do the same for year two and three — this time on a quarterly basis.

Above all, do this for yourself, not because you need to do this for your investors. Use this exercise to validate your assumptions, to get a deep understanding of the underlying logic of your business. Your startup will be better off for it.

The Business Model Slide

You have a business model, right? Or at least you pretend to have one? If you don’t and you believe you can get by, by using a variant of the “we’ll figure it out” phrase you better have stratospheric growth and millions of users.

Here’s the thing about your business model slide in your pitch deck: If you spend time to make it clear, concise, easy to understand and grasp, I am so much more likely to believe that you have at least a foggy clue about what you’re doing. If you, in contrast, do what I see so many startups do and give me a single bullet, hidden on one of your other slides which reads something like “Freemium Model” and that’s it… well, that’s a strong indicator that you haven’t thought about this a whole lot, that you are essentially clueless about your business and that I really shouldn’t trust you with my money.

With that being said, what does a great business model slide look like? It really depends on what your business model is (or you believe it is to be precise—these things tend to change). What I look for is a clear expression of your model, the underlying assumptions and the way the model works out. Often this can be neatly expressed in an info graphic—showing where and how the money comes in, how the value chain looks like and what the margins are alongside the chain. Here’s an example: it’s not perfect yet much better than simply expressing your model as “we take a 25% margin.”

Spend some time on your business model slide. Make it clear and concise. The litmus test is: Show someone who doesn’t know anything about your company just this one slide and ask them to explain back to you your business model. If they get it and they get it in its entirety you are off to the races.

The Ask

You know that you always have to have an ask in your pitch, right? It might be for money, it might be for partnerships or just feedback—but never ever leave an audience without asking for something.

There’s a lot of art and science to asking. Here’s my view on the science piece: Let’s assume you pitch for money. Don’t start your pitch with your ask. By putting your ask first you A) rob yourself of the wonderful poetry of a well delivered pitch (as everyone only thinks about the dollars), B) you might loose a good chunk of your audience who might not fall into your price bracket (believe me, more often than not they gladly invest if they just hear you out and get excited by your company) and C) you will have every investor judge every single slide against the dollar amount you put up.

That said, don’t just close your pitch with a “We’re raising $500k. Thank you very much.” but give me a bit more detail what you need the money for and how long it is projected to last (pro tip: Make sure you budget for enough runway—raising for too short an amount of time is a classic beginners mistake). You want to say something like: “We’re raising $500k which will go towards building out our engineering team, building our Android app and getting the first wave of marketing out which should get us to 500k users. The round is projected to last 12 months and will validate our milestones.”

A Word About Design

One question I get quite often about pitch decks is: How much text should be or need to be on the slides? This can be a tricky question—you will both present the deck to an audience (in which case you tend to want to have less text and more emphasis on your delivery) and you’ll send the deck to investors via email (in which case a slide with just an image on it won’t work—the recipient doesn’t have the context of your verbal presentation).

Guy Kawasaki famously formulated the 10/20/30 rule: 10 Slides, 20 Minutes, 30 Point Minimal Font Size. This is a great starting point—and what I would recommend for your in-person investor presentation. But it might not work for the deck you want to email.

Here’s what I would do (and have done): Start with a slide deck where each and every slide can stand on its own. Assume you give the slide deck to someone who has no context about you and your startup. And at the same time—treat your deck like a deck and not a word document. Keep text short, reduce it to the bare necessity, cut out unnecessary language. Keep the whole deck short—one should be able to flip through your deck in a few minutes and digest the whole thing in 10-15 minutes.

Once you have this, which will be the deck you send out to investors, you take the deck and cut out all the words which are not necessary for an in-person presentation. This will give you the deck that you present. Keeping the two decks in sync with regards to slides, order and design will make it easier for someone who saw your deck recognize it in your pitch.

Flow

The best pitch deck fails to deliver if your overall flow isn’t right. Flow has as much to do with the logical order of your slides as it has with a certain level of theatrical drama (tension/relieve) and your personal delivery.

Guy recommends ten slides in the following order:

  • Problem
  • Your solution
  • Business model
  • Underlying magic/technology
  • Marketing and sales
  • Competition
  • Team
  • Projections and milestones
  • Status and timeline
  • Summary and call to action

Personally I think this is as good an order as most. Some people like to talk about the team earlier (as investors invest into people first and foremost), others have specific slides talking about some intricate issues specific to the business they are pitching.

For me, it comes down to a logical order: talk about the problem you’re solving first, then present the solution (the tension and relieve arch), and what feels good for you. I prefer a slide deck that is a bit off but comes with amazing in-person presence over a great slide deck and an uninspired presentation any day.

Note that you want to have a bit of drama in your deck—yet it’s not your school play where you try to outcompete Shakespeare. Don’t spend half an hour on building tension and then, TADA!, present your solution. In the end it’s all about balance.

And hey, send me your deck and I’ll provide honest, direct feedback. I won’t bite. Promise.

Categorieën: Mozilla-nl planet

Cameron Kaiser: IonPower passes V8!

do, 26/02/2015 - 05:48
At least in Baseline-only mode, but check it out!

Starting program: /Volumes/BruceDeuce/src/mozilla-36t/obj-ff-dbg/dist/bin/js --no-ion --baseline-eager -f run.js
warning: Could not find malloc init callback function.
Make sure malloc is initialized before calling functions.
Reading symbols for shared libraries ....................................................................+++......... done
Richards: 144
DeltaBlue: 137
Crypto: 215
RayTrace: 230
EarleyBoyer: 193
RegExp: 157
Splay: 140
NavierStokes: 268
----
Score (version 7): 180

Program exited normally.

Please keep in mind this is a debugging version and performance is impaired relative to PPCBC (and if I had to ship a Baseline-only compiler in TenFourFox 38, it would still be PPCBC because it has the best track record). However, all of the code cleanup for IonPower and its enhanced debugging capabilities paid off: with one exception, all of the bugs I had to fix to get it passing V8 were immediately flagged by sanity checks during code generation, saving much labourious single stepping through generated assembly to find problems.

I have a Master's program final I have to study for, so I'll be putting this aside for a few days, but after I thoroughly bomb it the next step is to mount phase 4, where IonPower can pass the test suite in Baseline mode. Then the real fun will begin -- true Ion-level compilation on big-endian PowerPC. We are definitely on target for 38, assuming all goes well.

I forgot to mention one other advance in IonPower, which Ben will particularly appreciate if he still follows this blog: full support for all eight bitfields of the condition register. Unfortunately, it's mostly irrelevant to generated code because Ion assumes, much to my disappointment, that the processor possesses only a single set of flags. However, some sections of code that we fully control can now do multiple comparisons in parallel over several condition registers, reducing our heavy dependence upon (and usually hopeless serialization of) cr0, and certain FPU operations that emit to cr1 (or require the FPSCR to dump to it) can now branch directly upon that bitfield instead of having to copy it. Also, emulation of mcrxr on G5/POWER4+ no longer has a hard-coded dependency upon cr7, simplifying much conditional branching code. It's a seemingly minor change that nevertheless greatly helps to further unlock the untapped Power in PowerPC.

Categorieën: Mozilla-nl planet

The Mozilla Blog: A Major Victory for the Open Web

do, 26/02/2015 - 02:00

We just accomplished something very important together. Today, the U.S. Federal Communications Commission voted for strong net neutrality protections. This happened because millions of people — including many hundreds of thousands
in Mozilla’s community — joined together as citizens of the Web to demand those strong protections.

This is an important victory for the world’s largest public resource, the open Web. Net neutrality is a key aspect of enabling innovation from everywhere, and especially from new players and unexpected places. Net neutrality allows citizens and consumers to access new innovations and judge the merit for themselves. It allows individual citizens to make decisions, without gate-keepers who decide which possibilities can become real. Today’s net neutrality rules help us protect this open and innovative potential of the Internet.

Mozilla builds our products to put this openness and opportunity into the hands of individuals. We are organized as a non-profit so that the assets we create benefit everyone. Our products go hand-in-hand with net neutrality; they need net neutrality to bring the full potential of the Internet to all of us.

Today’s net neutrality rules are an important step in protecting opportunity for all. This victory was not inevitable. It occurred because so many people took action, so many people put their voice into the process. To each of you we say “Thank you.” Thank you for taking the time to understand the issue, for recognizing it’s important, and for taking action. Thank you for helping us build openness and opportunity into the very fabric of the Internet.

Video message from Mitchell Baker, Executive Chairwoman, Mozilla Foundation

Categorieën: Mozilla-nl planet

Planet Mozilla Interns: Michael Sullivan: Parallelizing compiles without parallelizing linking – using make

wo, 25/02/2015 - 21:21

I have to build LLVM and Clang a lot for my research. Clang/LLVM is quite large and takes a long time to build if I don’t use -j8 or so to parallelize the build; but I also quickly discovered that parallelizing the build didn’t work either! I work on a laptop with 8gb of RAM and while this can easily handle 8 parallel compiles, 8 parallel links plus Firefox and Emacs and everything else is a one way ticket to swap town.

So I set about finding a way to parallelize the compiles but not the links. Here I am focusing on building an existing project. There are probably nicer ways that someone writing the Makefile could use to make this easier for people or the default, but I haven’t really thought about that.

My first attempt was the hacky (while ! pgrep ld.bfd.real; do sleep 1; done; killall make ld.bfd.real) & make -j8; sleep 2; make. Here we wait until a linker has run, kill make, then rerun make without parallel execution. I expanded this into a more general script:

<noscript>View the code on <a href="https://gist.github.com/3290e688670c54f8d1a2">Gist</a>.</noscript>

This approach is kind of terrible. It’s really hacky, it has a concurrency bug (that I would fix if the whole thing wasn’t already so bad), and it slows things down way more than necessary; as soon as one link has started, nothing more is done in parallel.

A better approach is by using locking to make sure only one link command can run at a time. There is a handy command, flock, that does just that: it uses a file link to serialize execution of a command. We can just replace the Makefile’s linker command with a command that calls flock and everything will sort itself out. Unfortunately there is no totally standard way for Makefiles to represent how they do linking, so some Makefile source diving becomes necessary. (Many use $(LD); LLVM does not.) With LLVM, the following works: make -j8 'Link=flock /tmp/llvm-build $(Compile.Wrapper) $(CXX) $(CXXFLAGS) $(LD.Flags) $(LDFLAGS) $(TargetCommonOpts) $(Strip)'

That’s kind of nasty, and we can do a bit better. Many projects use $(CC) and/or $(CXX) as their underlying linking command; if we override that with something that uses flock then we’ll wind up serializing compiles as well as links. My hacky solution was to write a wrapper script that scans its arguments for “-c”; if it finds a “-c” it assumes it is a compile, otherwise it assumes it is a link and uses locking. We can then build LLVM with: make -j8 'CXX=lock-linking /tmp/llvm-build-lock clang++'.

<noscript>View the code on <a href="https://gist.github.com/d33029fcda6889b7d097">Gist</a>.</noscript>

Is there a better way to do this sort of thing?

Categorieën: Mozilla-nl planet

Air Mozilla: Product Coordination Meeting

wo, 25/02/2015 - 20:00

Product Coordination Meeting Weekly coordination meeting for Firefox Desktop & Android product planning between Marketing/PR, Engineering, Release Scheduling, and Support.

Categorieën: Mozilla-nl planet

Air Mozilla: The Joy of Coding (mconley livehacks on Firefox) - Episode 3

wo, 25/02/2015 - 19:00

The Joy of Coding (mconley livehacks on Firefox) - Episode 3 Watch mconley livehack on Firefox Desktop bugs!

Categorieën: Mozilla-nl planet

Kim Moir: Release Engineering special issue now available

wo, 25/02/2015 - 16:26
The release engineering special issue of IEEE software was published yesterday. (Download pdf here).  This issue focuses on the current state of release engineering, from both an industry and research perspective. Lots of exciting work happening in this field!

I'm interviewed in the roundtable article on the future of release engineering, along with Chuck Rossi of Facebook and Boris Debic of Google.  Interesting discussions on the current state of release engineering at organizations that scale large number of builds and tests, and release frequently.  As well,  the challenges with mobile releases versus web deployments are discussed. And finally, a discussion of how to find good release engineers, and what the future may hold.

Thanks to the other guest editors on this issue -  Stephany Bellomo, Tamara Marshall-Klein, Bram Adams, Foutse Khomh and Christian Bird - for all their hard work that make this happen!


As an aside, when I opened the issue, the image on the front cover made me laugh.  It's reminiscent of the cover on a mid-century science fiction anthology.  I showed Mr. Releng and he said "Robot birds? That is EXACTLY how I pictured working in releng."  Maybe it's meant to represent that we let software fly free.  In any case, I must go back to tending the flock of robotic avian overlords.
Categorieën: Mozilla-nl planet

Pagina's