Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • stefano 1:30 pm on August 31, 2015 Permalink
    Tags: chair, committee, , tokyo, track   

    How I evaluate submissions for talks at OpenStack Summits 

    As a track chair, I look for content that will be informative for participants live at the event. I also look for entertaining content, well delivered, clear and usable also as a complement to written documentation, something to be enjoyed also after the event on the video channel.

    I’ve been a track chair for OpenStack Summit tracks many times and recent discussions on the community mailing list made me decide to publish the principle that have guided my decisions.

    When I’m evaluating a talk I look at:

    • the title
    • the abstract
    • the bio of the speaker

    A good title conveys immediately what the talk is about and some idea of the argument or area of discussion. A good abstract expands on the title describing the thesis, the argument and the conclusion, includes also a reason for an identified audience to go see it at the conference, or later on youtube. The bio of the speaker needs to reinforce all of the above, explain why the speaker is the best person to deliver the talk.

    By looking only at title, abstract and bio, I discard bad titles, bad abstracts and speakers with a bad bio and who are not known to me, to linkedin, to slideshare and to google in general. Usually that leaves me with twice as many talks as slots available in the track.

    The next criteria I use to discard other talks are: does this talk fit with the overall objective of the Summit? Does it fit with the specific objective of the track? For example, the objective of the Tokyo summit is to focus on application developers and containers. And for the How To Contribute track, the colleagues track chairs decided to focus on content that we didn’t hear before or needed update and to give precedence to more regional-specific content. This pass usually identifies a couple of clear winners and 2-3 tracks with very little debate.

    Now it’s time for group deliberation to finish the selection, starting from those that gained the majority of support and asking for a dissenting opinion. All of our arguments were around title, abstract and bio of the presenters, those provided more than enough information to make a decision and we never had to use anything else.

    We never looked at the public votes because those are easily gamed and I think it would be unfair at this point to give priority to someone only because they work for an organization that can promote talks during the voting process. Each candidate needs to be evaluated based on what they bring to the Summits, not on their marketing teams.

    My argument against using the results votes of the public voting process to judge proposals is exactly that, at best, those votes don’t provide any value: bad titles and bad abstracts proposed by non-involved individuals will gather very few votes anyway, but those are very easy to discard for track chairs anyway. So no value here. But once the decent tracks remain under consideration, looking at the public votes result may skew track chair decisions towards the usual people that speak every time, with lots of twitter followers or the ones working for companies with well organized marketing departments.

    To me the votes are the result of a popularity contest and if used for anything, they dramatically damage the minorities that are not on twitter, the people who are shy by nature and those working for companies that don’t have a strong social media presence (or don’t use it at all). In fact, I’d argue that the results of the votes should be even hidden in the track chair UI.

    I always considered the voting process as a marketing tool for the event, a community ritual, a celebration of the OpenStack community as a whole and not something that the selection committee should use. I find looking at votes extremely unfair to the submitters and diminishing of the selection committee’s role, too. IMO a good committee should evaluate based on quality of content relative to the objectives for that specific summit (overall focus, location), and totally ignore the popularity of their proposers (or their employees).

    I wish we could have the data to analyze and demonstrate if the votes are the expression of a larger community or, as I suspect, are just the result of twitter reactions and push from marketing efforts of few companies. My gut feeling is that with thousands of proposals nobody has the possibility to read and vote them all. So the proposals voted are necessarily only a fraction.  Also, of all the people rotating around OpenStack, few of them vote. This means that
    few people find some talk proposals. Which talks are more popular? I notice how well organized are companies like Rackspace, Red Hat, Mirantis, IBM, Tesora and few others blogging about their proposals when time comes. Maybe if the data show that the talks from employees of those companies are the most voted probably we can infer that you either push your talks or your talk doesn’t get voted.

    Am I suggesting getting rid of voting all together?  No, that’s not what I’m advocating. I think the voting process is valuable for the summit as a whole and for the community as a whole. It’s a ritual, it’s a celebration, it’s a preparation to the event, it’s a collective, fun activity that we repeat every six months. The voting process is not broken and needs no fixing: it’s great. Only the results IMO are useless for selecting good content at the Summit.

     
  • stefano 10:19 am on August 4, 2015 Permalink
    Tags: comment, , , , , monty   

    A new push for OpenStack public clouds? 

    Monty “mordred” Taylor just announced that he’s leaving HP and going to work at IBM. Usually something like this wouldn’t deserve more fanfare than the twittersphere explosion already in act. In this case, I think the announcement is more important than just an OpenStack board member and technical leader changing employer.

    Monty says on his blog that he is leaving HP because he wants to build public clouds, implying that he can’t do that at HP. At IBM instead he’ll be focusing on a strong OpenStack-based public cloud, to compete head-to-head with Amazon (and surpass it).

    His words confirm the impression I had when analyzing the competitive landscape of public clouds for DreamHost. HP clearly is targeting the enterprise market, with their public cloud used mainly as a supporting mechanism for the private clouds.

    I think OpenStack will benefit from more focus on public clouds: I have the feeling those are taken for granted, since there are working groups for pretty much anything but for public clouds. And all operators running large clusters have nightmare stories instead. Hopefully lots of positive changes aimed at public cloud users will keep going upstream (and we can avoid creating yet another working group in openstack-land).

     
  • stefano 10:29 am on July 17, 2015 Permalink
    Tags: , ,   

    The hard life of OpenStack application developers 

    I’m starting to feel the pain of developers attempting to write applications on top of OpenStack clouds: it hurts, and I haven’t come anywhere close to doing anything special.

    I started following the getting started utorial for First App Application For OpenStack (faafo) and I gut stuck on step 1, authentication. There are way too many things that are convoluted, confusing and sometimes carefully hidden (or ridiculously displayed) on Horizon that make it too hard to get started developing apps on OpenStack. I started following the Get Started document for python-libcloud:

    You need the following information that you can obtain from your cloud provider:

    auth URL
    user name
    password
    project ID or name (projects are also known as tenants)
    cloud region

    Looks simple but it’s not. The auth URL doesn’t include the path say libcloud documentation but in practice every cloud I tried behaves differently. DreamHost and Runabove require not only v2.0/ but also /tokens after the base URL (https://keystone.dream.io/v2.0/tokens) while CityCloud and HPCloud seem to work according to the documentation. Some will throw weird errors if you add /tokens. Libcloud is also confusing regarding support for Keystone API v3 (which Citycloud uses): the official docs don’t mention v3 (bug), but a blog post from libcloud maintainer provides examples on how to use it.

    Finding the right projectID or name is also challenging because some clouds don’t show the project ID immediately in the web control panel (and not every cloud I tested runs OpenStack Horizon). Chances are you’ll have to find the RC file, which is fairly easy if the cloud you’re targeting is using Horizon.

    Even after I found all the pieces, I haven’t managed to authenticate using libcloud on CityCloud, Rackspace (using openstack provider) and HP. Only with OVH I managed to authenticate and get a list of images with my stock Ubuntu 15.04. I managed to authenticate on DreamHost only on Ubuntu 14.04 and on a clean, updated virtualenv.

    It took a lot of trials and errors to get rid of the Method Not Allowed errors and get libcloud.common.types.InvalidCredsError: ‘Invalid credentials with the provider’, which at least is hinting that I have guessed the auth_url for Citycloud and HP. But I have no idea why credentials are not accepted, since the username and password are those I use on the Horizon panel on HP and on on the custom Citycloud panel. My guess is that I haven’t guessed correctly the project_name or tenant_id or whatever it’s called. This is too confusing.

    OVH seems to works, but it requires the full url:

    auth_url = ‘https://auth.runabove.io/v2.0/tokens

    it won’t work without /v2.0/tokens.  So, after spending one day reading docs, trying to guess permutations I started thinking that probably libcloud is not a feasible approach.

    I’ve started looking at OpenStack Infra homegrown interoperability library shade instead: authentication went smoothly immediately with DreamHost and HP on my machine. At least that part was easy and I managed to make some progress in my test with that, finally. Hopefully by the end of the day I’ll have the FAAFO running on

    The end result is that it shouldn’t be this hard, even for a very modest developer like me, following a well written, copy-and-paste tutorial should not be as confusing. A lot of work needs to be done to make OpenStack clouds friendly to app developers.

     
  • stefano 8:07 am on June 23, 2015 Permalink
    Tags: , , foundation,   

    So long OpenStack community, see you soon 

    Let’s call it a “ciao” and not an “addio.”

    After almost four years (un)managing the OpenStack community, I have decided to move on and join DreamHost’s team to lead the marketing efforts of the DreamCloud. The past three years and 10 months have been amazing: I’ve joined a community of about 300 upstream contributors and saw it grow under my watch to over 3,600. I knew OpenStack would become huge and influence IT as much as the Linux kernel did and I still think it’s true. I’m really proud to have done my part to make OpenStack as big as it is now.

    During these years, I’ve focused on making open source community management more like a system, with proper measurement in place and onboarding programs for new contributors. I believe that open source collaboration is just a different form of engineering and as such it should be measured correctly in order to be better managed. I am particularly proud of the Activity Board, one of the most sophisticated systems to keep track of open collaboration. When I started fiddling with data from the developers’ community, there were only rudimentary examples of open source metrics published by Eclipse Foundation and Symbian Foundation. With the help of researchers from University of Madrid, we built a comprehensive dashboard for weekly tracking of raw numbers and quarterly reports with sophisticated, in-depth analysis. The OpenStack Activity Board may not look as pretty as Stackalytics, but the partnership with its developers makes it possible to tap into the best practices of software engineering metrics. I was lucky enough to find good partners in this journey, and to provide an example that other open source communities have followed, from Wikimedia to Eclipse, Apache and others.

    OpenStack Upstream Training is another example of a great partner: I was looking into a training program to teach developers about open source collaboration when I spoke in Hong Kong to an old friend, Loic Dachary. He told me about his experiment and I was immediately sold on the idea. After a trial run in Atlanta, we scaled the training up for Paris, Vancouver, plus community members repeated it in Japan already twice. I’m sure OpenStack Upstream Training will be offered also in Tokyo.

    It’s not a secret that I can’t stand online forums and that I consider mailing lists a necessary evil. I setup Ask OpenStack for users hoping to provide a place for them to find answers. It’s working well, with a lot of traffic in the English version and a lot less traffic in Chinese. My original roadmap was to provide more languages but we hit some issues with the software powering it (Askbot) that I hope the infra team and the excellent Marton Kiss can solve rapidly.

    On the issue of diversity, both gender and geographic, I’m quite satisfied with the results. I admit that these are hard problems that no single community can solve but each can put a drop in the bucket. I believe the Travel Support Program and constant participation in Outreachy are two such drops that help OpenStack be a welcoming place for people from all over the world and regardless of gender. The Board has also recently formalized a Diversity working group.

    Of course I wish I did some things better, faster. I’m sorry I didn’t make the CLA easier for casual and independent contributors: I’m glad to see the Board finally taking steps to improve the situation. I wish also I delivered the OpenStack Groups portal earlier and with more features but the dependency on OpenStackID and other projects with higher priorities delayed it a lot. Hopefully that portal will catch up.

    I will miss the people at the OpenStack Foundation: I’ve rarely worked with such a selection of smart, hard workers and fun to be around, too. It’s a huge privilege to work with people you actually want to go out with, talk about life, fun, travel, beers, wines and not work.

    When we Italians say “ciao,” it means we’re not saying good bye for long.

    So long, OpenStack community, see you around the corner.

     
  • stefano 3:13 pm on June 4, 2015 Permalink |
    Tags: , ,   

    OpenStack is as start-up friendly as anything 

    I read someone complaining about OpenStack being not friendly enough to startups one time too many. Latest post by Rob Hirschfeld 10 ways to make OpenStack more Start-up Friendly made me want to respond. I just can’t stand the Greek chorus of complaints, especially from someone who sits on the board and can actually push for changes where necessary. I promised I’d spend time on his 10 points and here is my take on each of them:

    Accept companies will have some closed tech – Many investors believe that companies need proprietary IP. An “open all things” company will have more trouble with investors.

    Why is this an OpenStack problem? If the VC industry have a problem with open source then the problem is of open source as a whole or of the VC (depending on your point of view). Maybe customers prefer to buy open source based solutions instead of buying proprietary code from small startups. This is not an OpenStack issue.

    Stop scoring commits as community currency – Small companies don’t show up in the OpenStack committer economy because they are 1) small and 2) working on their product upstream ahead of OpenStack upstream code.

    Code is the most valuable currency in an open source project, there is absolutely no way OpenStack should be any different. Companies small and big will be contributing compared to their size and code is how a small company doing great work can gain more influence than a large company doing little stuff. If you’re saying that the community shouldn’t put first and foremost the “top ten” charts of companies contributing (like stackalytics does), then I agree with you. The Foundation celebrates individual contributors to the release and only counts company. This is not an OpenStack problem. Maybe it is a stackalytics problem and one of the reasons I prefer to partner with Bitergia for the community dashboard.

    Have start-up travel assistance – OpenStack demands a lot of travel and start-ups don’t have the funds to chase the world-wide summits and mid-cycles.

    OpenStack has already has addressed this problem with the Travel Support Program. In Vancouver the Foundation spent around $50k to send about 30 people from all over the world, from startups and students. If that’s not enough, I’m sure more money can be raised for that. This is not an issue, there is a solution in place already.

    Embrace open projects outside of OpenStack governance – Not all companies want or need that type of governance for their start-up code base.  That does not make them less valuable, it just makes them not ready yet.

    I don’t even know where this comes from: is anybody forcing anyone to host code on git.openstack.org/openstack namespace? And isn’t the OpenStack project offering for free its resources to host code in our systems, without imposing governance or rules with git.openstack.org/stackforge? If there are companies interested in getting under the OpenStack governance, it’s their choice and based on my knowledge they choose because they get business value off of it. This is a non-issue.

    Stop anointing ecosystem projects as OpenStack projects – Projects that are allowed into OpenStack get to grab to a megaphone even if they have minimal feature sets.

    Even if this was a problem, and I don’t think it is, it should work in favor of startups: many of them have nothing to show but good intentions, for which a megaphone is exactly what they want and use. This is a non-issue.

    Be language neutral – Python is not the only language and start-ups need to make practical choices based on their objectives, staff and architecture.

    Nobody forces anyone to become an OpenStack official project (which requires some level of standardization). It’s a choice. And, in any case, there is a lot of javascript and ruby in OpenStack, with pieces in Go also coming. This is a non-issue.

    Have a stable base – start-ups don’t have time to troubleshoot both their own product and OpenStack.  Without core stability, it’s risky to add OpenStack as a product requirement.

    This is a tautology also it’s something that is being constantly advocated and keeps on improving.

    Focus on interoperability – Start-ups don’t have time evangelize OpenStack.  They need OpenStack to have large base of public and private installs because that creates an addressable market.

    So let me get this straight: IBM, EMC, Cisco are scooping up the first waves of startup that tried to build a product on the rudimentary OpenStack. Such big guns have the clout to create that large addressable market, lending their credibility to OpenStack as a whole. They also pay good checks to the OpenStack Foundation to power its awesome marketing machine.  This is good for startups: they ride on a wave created with someone else’s money.

    Limit big companies from making big pre-announcements – Start-ups primary advantage is being a first/fast mover.  When OpenStack members make announcements of intention (generally without substance) it damages the market for start-ups.  Normally corporate announcements are just noise but they are given credibility when they appear to come from the community.

    Yeah, right, like you can really put on a rule against vaporware. It’s the way this market has worked and will continue to work this way. Startups, in any field have to learn how to live with it. This is not an OpenStack issue.

    Reduce the contribution tax and patch backlog – Start-ups must seek the path of least friction.  If needed OpenStack code changes require a lot of work and time then they are unlikely to look for less expensive alternatives.

    Here I guess you’re talking about contributions to existing OpenStack projects, like Nova, Neutron and the like. If you think that some company can innovate fast on Nova while keeping the interoperability and stable release you talk about above then you’ve managed to confuse me. How realistically can you have some startup rip Nova apart and replace parts of it (all of it?) with the greatest big thing and keep the thousands of users out there with a happy upgradeable path, interoperability and stability? This is just impossible to reconcile. Startups cannot innovate on something that is mature and in production. It would be like asking Apache HTTPD to be something else. Guess what: nginx happened outside of Apache and it’s only natural. As a parallel to OpenStack, if someone comes up with a better Neutron, written in Go or Rust, and wide support I’m ready to bet it will be admitted in the big tent rapidly.

    Let me tell you why I think that OpenStack is at least as friendly as any other business environment, and maybe more:

    1. Corporate sponsorship for startups is low, a lot lower than for big corporations. And there are ways to lower the admission price even further (just ask).
    2. The ecosystem is now so huge that cool startups innovating on the edges can get exposed to potential customers, investors and buyers very quickly (the megaphone works).
    3. The ‘cloud’ space is so rapidly changing that the big guys cannot keep up and count on startups to do the risky experimentation. There are lots of big companies in OpenStack, I suppose there are opportunities to find good contacts.
    4. The OpenStack Summits have a whole track dedicated to startups, with talks about funding, business, strategies, acquisitions and more.

    And finally a reminder: all startups operate in extremely unfriendly environments, most startups fail for various reasons.

    The recent exits of companies that innovated on the edges when OpenStack was held together with shoestring and spit as glue are to me a confirmation that the edges where innovation can happen are just moving outside of Nova and Neutron. It’s just normal and to be expected with the maturity of the project.

    Let’s celebrate and be happy for Piston and Blue Box and the others. Startups will always be welcome and will always find a good home in and around OpenStack.

     
  • stefano 6:55 pm on May 14, 2015 Permalink |
    Tags: , ergonomic, , touchscreen, xps13   

    A week with Dell XPS13 9343 (2015 model) 

    Last week I have received the new Dell XPS 13 from the Sputnik program, the one with Ubuntu pre-installed. I wanted to vote with my wallet since I believe Ubuntu is a pretty solid desktop environment, on par with Mac OS X and various Windows.

    Design-wise  Dell has produced a very good looking machine, nothing to say about that. Kudos to Dell’s team on designing something much prettier than a Macbook Air. The screen with no border is fantastic with almost no frame and it’s great to look at it.

    The only complaint I have towards Dell are the options they picked for the Sputnix program: the only way not to get a touchscreen is to buy a severely limited machine with only 128MB disk. No way. All the other options force you to spend money and sacrifice battery power on a useless feature.

    I think touchscreens are uncomfortable to use on desktops and I said so a long time ago. Unless the desktop OS is radically re-designed for touch and hand gestures on the monitor, it makes no sense. I would have never bought the touchscreen if Dell had offered a 256MB option with the regular monitor.

    On the Ubuntu side there are quite a few glitches like this issue with the cursor becoming sticky on some applications even if the touch-to-click on the touchpad is disabled and some difficulty to adapt to the ultradense display. By the way, that’s another reason not to get the touchscreen: lower resolution is good enough on such a small laptop anyway. Installing Ubuntu Vivid also was a bit more painful than I thought.

    All in all, I didn’t return the laptop as I thought I would, mainly because I needed to upgrade to a machine with 8GB rapidly.

     
  • stefano 9:32 am on March 25, 2015 Permalink |
    Tags: bitnami, , ,   

    Vote to get Mediagoblin on Bitnami 

    I’m a fan of GNU Mediagoblin, the media publishing platform that anyone can run. You can think of it as a decentralized alternative to Flickr, YouTube, SoundCloud, etc. It would be great to have it packaged for Bitnami so more people can run it easily. Vote for Mediagoblin!

     
  • stefano 4:35 pm on December 16, 2014 Permalink |  

    How to get better at IRC-based meetings 

    Marvel’s Professor X sure knows how hard IRC meetings are

    When people approach discussions via IRC for the first time, most of the time they get overwhelmed. Being IRC the most common way to hold meetings in OpenStack, practicing written communication on IRC should be suggested to start immediately to all new contributors.

    I still remember the first time I went on IRC: I felt like I was in a room where everyone was speaking loudly and I could hear every single person in the room. It wasn’t like being in a loud crowd where all you hear is noise and your brain is perfectly trained/evolved to filter out: I felt like comic book characters may feel when they actually hear and comprehend everything everybody is saying. It was scary. It took me a while to learn how to filter the written noise and follow multiple threads in real time, write an answer to someone while reading a question from someone else.

    In the past days I’ve been working closely with people in teams that had no practice of holding conversations on IRC. Especially some of these people had no practice in holding meetings on IRC. I hear often the complaint that written chat meetings are too slow but I believe it’s the opposite: they’re too fast, they require skills and training that may take months of daily practice to master. IRC has strong advantages though, that speed at which discussions can progress with 10-15 people and more is sweet, so sweet that when I am stuck in audio-video conferences, everything seems to be too slow and distractions abund.

    To all people new to IRC I suggest to practice and practice and practice some more. It’s really not that hard to join an IRC channel and just spend few minutes a day to read the history and try to make sense of it. It’s a habit: if your job description includes writing a specs for OpenStack then an IRC client should start every time you login in your machine. Even if you think you have nothing to say: get started when you don’t need to say anything, just start to get your brain trained for IRC super-hero powers, like those of telepath Professor X. Learn to filter the background, follow multiple threads if needed, improve your typing speed. The OpenStack wiki page has some basic pointers to get started. If you have suggestions, feel free to edit that page.

     
  • stefano 3:19 am on November 13, 2014 Permalink |
    Tags: , , , , , ,   

    Tips to improve organizations contributing to OpenStack 

    The slides of my presentation at OpenStack Summit in Paris 2014 (download ODP source, 9M).

    And the sessions’ recording:

     
  • stefano 1:23 pm on November 11, 2014 Permalink |
    Tags: , ,   

    Post-summit summary of OpenStack Paris 

    Seven straight full time working days, starting from 9am Saturday and Sunday for the second edition of OpenStack Upstream Training to the feedback session on Friday evening at 6pm are finally over and I’m starting to catch up.

    I spoke on Monday, highlighting some of the findings of my research on how to change organizations so they can better contribute to OpenStack, later lead with Rob, Sean and Allison the creation of the Product working group (more on this later). The double-length session dedicated to addressing the growth pain in Neutron has removed the “if” and left the question to “how and when do we empower drivers and plugin developers to take their fate in their own hands”.

    I think this has been one of the most productive summit, I’m leaving Paris with the feeling we keep on improving our governance models and processes to better serve our ecosystem. Despite the criticisms, this community keeps on changing and adapts to new opportunities and threats like nothing I’ve seen before. I’m all charged up and ready for the six months of intense work leading up to Vancouver!

     
c
Compose new post
j
Next post/Next comment
k
Previous post/Previous comment
r
Reply
e
Edit
o
Show/Hide comments
t
Go to top
l
Go to login
h
Show/Hide help
shift + esc
Cancel