Tagged: community Toggle Comment Threads | Keyboard Shortcuts

  • stefano 3:40 pm on October 1, 2014 Permalink | Reply
    Tags: community, , wiki   

    Improving the content of OpenStack wiki 

    The pages on wiki.openstack.org have been growing at a fast pace and it’s  time to give the wiki more shape: new contributors, end users and operators are having a hard time finding documentation since over time it spreads across many places. The wiki can have a role at directing readers where most appropriate. Luckily we have a team ready to help give the ~350 pages a more solid navigation and fixing content while at it:

    • Katherine Cranford (a trained taxonomist) volunteered to get through the wiki pages and propose a taxonomy for the wiki.
    • Shari Mahrdt, a recent hire by the Foundation, has volunteered a few hours per week to implement the taxonomy in the wiki pages, setup templates and write documentation to maintain the wiki.
    • I am overseeing the implementation and looking more carefully at content for contributors.

    We are keeping track of things to do on the etherpad: Action_Items_OpenStack_Wiki. Shari and I started implementing Katherine’s proposed taxonomy: it’s visible as a navigable tree on https://wiki.openstack.org/wiki/Category:Home.

    As an example of how the taxonomy works, let’s look at the tree of OpenStack Programs. One can think of Programs as teams of people using tools (code repository, bug tracker, etc) and coordinated processes to deliver one or more project to achieve a clearly stated objective. For  example, the Telemetry Program has a team of core reviewers responsible to drive development in code repositories for the Ceilometer project and the Ceilometer client, and each has pages for blueprints and specs, meeting notes and more. Programs contain projects, so the tree of categories under Programs will look like:
    • Programs
      • Telemetry
        • Ceilometer
          • Client
          • Blueprint
      • Block Storage
        • Cinder
          • Client
          • Blueprints
      • Compute
        • Nova
          • Client
          • Blueprints

    You can see this live on the wiki on https://wiki.openstack.org/wiki/Category:Programs. Fairly straightforward except that over the years some of the pages have started with describing a project and have now been repurposed to illustrate a Program. Look at Nova page for example: the name of the page is “Nova” but the title is OpenStack Compute. We’ll definitely have to shuffle content around.  For example, the Category:Programs page can be considered a duplicate of the wiki https://wiki.openstack.org/wiki/Programs page: since everything on mediawiki is a page, the Category pages can be edited and can be redirected to/from like all other pages. In this case, it would make sense to make high level content like Programs more of a dynamic page, like Category:Programs. The cool thing of this approach is that we can probably create new category page for new programs automatically when modifications to the programs.yaml are approved via jenkins.

    Adding a taxonomy and templates (more on this later) will help newcomers discover relevant content and find information more easily. While we implement the changes to the wiki we’ll also be reviewing the content on the pages, delete or mark as obsolete the old stuff and make things more readable for all. You can keep up with the progress by looking at RecentChanges.

    If you’d like to help us out or find out more please feel free to contact stefano@openstack.org and shari@openstack.org

     
  • stefano 3:19 pm on September 25, 2014 Permalink | Reply
    Tags: community, contributions, ,   

    How is your OpenStack team organized? 

    I’ve been collecting a lot of good insights talking to directors and managers about how their companies are organized to contribute to OpenStack. For geographic reasons I have mostly gathered comments from people between San Francisco and Silicon Valley and I’d like to expand the research.

    I’m especially interested in learning about internal processes, system of incentives, things that impact performance evaluation for engineers contributing to OpenStack.

    To expand the research I’m asking the OpenStack community to fill in this brief survey or contact me directly (stefano openstack.org) for a quick interview.

     
  • stefano 11:17 am on July 14, 2014 Permalink | Reply
    Tags: blueprints, bugs, community, , , operators, users   

    Only developers should file specifications and blueprints 

    If you try to solve a problem with the wrong tool you’re likely going to have a frustrating experience. OpenStack developers have been using the same workflow to plan and manage development of OpenStack software over time, they chose a set of tools appropriate for the project’s software development. Developers use blueprints define the roadmap for the various projects, the specifications attached to a blueprint are used to discuss the implementation details before code is submitted for review.

    These are the tools for the developers and this doesn’t mean that blueprints and specifications are the only way to interact with developers. Operators and users in general don’t need to dive in the details of how OpenStack developers organize their work and definitely should never be asked to use tools designed for and by developers. When I read ‘s post the place of a non-developer in the openstack community I immediately felt her pain: she was asked to use the wrong tool to solve a problem. I think this case is a major misunderstanding but the comments on the post signal that this is not an isolated case.

    The most common way for a non-developer to highlight a flaw in OpenStack is to file a new bug report. Bugs can be defects that need to be fixed  or they can be requests for enhancement. In this case, Dafna filed a bug report and interacting with the triager, they agreed that the reported bug was not a defect per se but more of a request for enhancement, a wishlist.

    In order to fix a defect or implement a wishlist item, developers need to file a blueprint (and a specification) before they can start writing code. If the person who filed the original bug report is also a developer then s/he can go ahead and continue carrying on the process, file a blueprint to solve a bug # and write specifications (when needed) to describe the details of the implementation. Users interested in the bug can chime in adding comments to the bug and to the specs, provide input to developers.

    The process above works in similar way when the person filing the bug is not a developer, like in Dafna’s case. The proper flow of bug #1323578 would have not required Dafna to file a blueprint and specs, but to have a developer do that. Users are required to interact closely with the developers to discuss the implementation details, and that’s where the new specifications process helps. Gerrit may not have the best UI but it’s definitely better than holding discussions on a mailing list. Adding comments and holding conversations with the developer assigned to resolve the issue, on the bug report itself is also a valid option.

    While I think that as a community we have plenty of ways to improve how we include users and operators in our conversations, in this particular case, I think frustration came from being pulled in the wrong place from the beginning.

    PS: To be super-clear, in this post I’m using the terms developer and operator to describe a role, not a person. One person can be at the same time a developer and an operator, and act at times as a developer writing blueprints, submitting code and as an operator filing bug, giving comments to specifications.

     

     
    • Stephen Balukoff 2:38 pm on July 18, 2014 Permalink | Reply

      So, while an in-depth reading of your article here makes it clear that your comments are meant for developers– that you are saying developers shouldn’t push non-developers to use tools only meant for developers, both the title and several parts of your article can be interpreted to say “stay out of my kitchen” to operators and users. I would suggest altering the title to say something less exclusionary to these other 2/3rds of the OpenStack community. (Something like “Developers should not send non-developers to launchpad or gerrit.”)

      Having said this, I really feel like your article somewhat misses the point of Dafna’s blog post: In my reading she was frustrated because she was not able to contribute to the discussion, and her opinion was considered value-less unless she was willing to go through the (for her, arduous) task of learning two new systems which are neither user-friendly, nor particularly suited to the kind of discussion she wanted to have.

      Your post reads to me somewhat like “there are tools non-developers should be using to communicate with developers, and these are not the same tools developers will use to communicate with each other.” To me this is akin to the cooks getting angry at the waiters and customers for coming into their kitchen whey they have problems or suggestions. That’s all fine and dandy– so long as the cooks are actually providing good tools the waiters and customers can use to communicate to them, and using those tools themselves. I read Dafna’s point being that this obviously wasn’t happening, and instead what was effectively red-tape was being used to make her go away.

      If the OpenStack community wants to change this reputation for being exclusionary to operators and users, then this is exactly this sort of thing that needs to be worked on! Unfortunately, I don’t think the way you worded your article is helping much here. :/

      Also one point in particular in your article I feel I need to take issue with: “Gerrit may not have the best UI but it’s definitely better than holding discussions on a mailing list.” Actually, the mailing list is the perfect place to discuss ideas among a larger crowd of people when a major new idea or significant change is being contemplated. You’ve already said that Gerrit shouldn’t be used by non-developers, so if you limit these kinds of discussions to Gerrit only, then you are thereby ignoring any input that 2/3rds of the OpenStack community might have on the subject. This can lead to solutions which don’t actually meet operator or user needs at all, can lead to really poor design which then is a pain in the patootie to correct (given OpenStacks backward-compatibility policies), and certainly leads to OpenStack not being as good as it could be in the same amount of time.

      Also, I don’t think any search engine is indexing Gerrit (from what I can tell), and it’s far too easy for comments on early revisions of a patch to get lost forever when later revisions of the patch are uploaded for review (since Gerrit doesn’t carry comments forward– this needs to be done manually by attentive reviewers).

      That’s not to say Gerrit isn’t a good tool. In fact, as consensus among the community is neared on a mailing list discussion, it’s important for the details of that consensus to be translated into blueprints and specifications. Gerrit is actually probably the best tool we could be using when it comes to things mostly concerning developers (comments on specific lines of code, or specific details within a specification). But it is wholly the wrong place to be having design or feature-improvement discussions, especially with non-developer contributors like operators and users.

      • stefano 10:19 pm on July 19, 2014 Permalink | Reply

        Hi Stephen, I appreciate your comment. In fact, I think you have caught my intention quite well. I worded the title in such way exactly to get this sort of comments: I wanted the article to be challenged.

        I think that the *tools* that Dafna was told to use confused her and that’s wrong. She was put in a position to fail and that is not fair to any user. Her thoughts and comments could have stayed on the bug report or migrated to a mailing list, as you suggested, and eventually become a blueprint+specs lead by a developer.

        I think that OpenStack has done an incredible amount of work to include operators and users in the development loop. In the past 12 months I think we’ve visibly included operators into the decision making process, starting from the user survey to the work on personas and the UX team, the Operators Summits, the working groups within the User Committee and there is even more coming.

        As for the debate about Gerrit… Let me just hope that storyboard accelerates and becomes the tool we can use to discuss specifications. I voiced my concerns publicly against the specs repositories but at the same time, I have a hard time coming up with a radically better alternative.

    • Maish Saidel-Keesing 7:25 am on July 20, 2014 Permalink | Reply

      Hi Stefano.

      I have to agree with Stephen here. I too (not being a developer) find it very difficult to navigate the multiple tools and methods used by the OpenStack project to drive directions, changes, fixes and improvements.

      Let me count.

      There is Gerrit.
      There is Launchpad
      There is IRC
      There is the mailing list.
      There is Etherpad.
      There is the Wiki.
      There is the documentation.
      Oh yeah – there is even a support helpdesk (whatever that is used for)

      Perhaps I missed something here – but those are the ones that come to mind.

      Yes they all have their use cases, and one does not replace the other – nor should it, but the amount of information that flies across all of these – is substancial.

      And as a user/operator – it took me a decent amount of time to understand how to submit a patch – something as simple as an error in a config file.

      I still have problems getting my head around how the whole patch and voting system works, who has to approve, when, how, what is the difference between a +1, -1, -2, +2. What are the intricacies and clicks that need to be handled in order to get a patch submitted or re-submitted or changed. What happens when one core reviewer disagrees with another on my patch?

      What will happen if you are new – will someone work with you to get the change you wanted to submit (and are doing so – only because you want to help out) and approved?

      I have the feeling (and evidently I am no the only one) that the developers community think this is second nature to them – it probably is – and that those who do not know the language – the talk – the culture – are outsiders – and that they do not have the time / patience / incentive to teach them – hold their hand or walk them through it.

      I can personally tell you an experience of where I asked a question in IRC about features in LBaaS and if they existed or were planned. The question that was presented to me – so why don’t you start writing the code to implement these changes? My answer was I am not a developer – so my contribution on this part would not be helpful, the answer that I was given thereafter was “Forget it – we have enough architects and conceptual designers – we need people to make it happen”

      Developers are a different breed, for better or for worse. The feeling Operators/users have is that we are not involved – and therefore should stay out the way of the way the “magic happens”

      I for one would love to see that change. There is room for improvement in every single project – and developers could benefit immensely from the input of those who are actually deploying and using the product, in the real world.

      • stefano 7:11 pm on July 20, 2014 Permalink | Reply

        Thanks Maish. Let me make it straight: I, too agree with Stephen that the tools and processes we use are complex to navigate and such complexity may discourage *casual* contributors. I think this topic deserves a longer conversation than just a reply to a comment, I’ll try to follow up in the next days.

        I substantially disagree with the idea that OpenStack developers don’t want to listen to users: the truth is that things are a lot better in OpenStack than in most other software development projects and they also keep improving. Feedback from users and operators is constantly being fed back into the development process, via the user survey, the operator summits, the design sessions, the conversations on the mailing lists, the comments on bug reports, specs and blueprints. Sure, a lot more can be done, but I don’t accept general criticisms that OpenStack developers don’t listen to users.

        I would not generalize from one single comment on an IRC channel, you should consider a random conversation on IRC exactly like a chat around a pint at a pub.

        • Maish Saidel-Keesing 11:34 pm on July 20, 2014 Permalink | Reply

          Hi Stefano – If it came over that all developers are not interested in hearing what we have to say – then that was not my intention. Really not. I just wanted to re-iterate the comments and feelings that were voiced before. Of course I see improvement – exactly as you said – with the Operators conference – and the joint sessions- but there is still quite a way to go. I do still feel that the developers could make more of an effort to “embrace” the newbies – it will be more beneficial to us all in the long run term.

          I hope that the Foundation will continue to invest time, money and effort into this – it will make the product better for us all.

          I would be happy to assist in any way I can to contribute to the conversation.

  • stefano 10:30 am on February 26, 2014 Permalink | Reply
    Tags: , community, fork, libreoffice,   

    Sustainability of Open Source software communities beyond a fork: How and why has the LibreOffice project evolved?

    via Sustainability of Open Source software communities beyond a fork: How and why has the LibreOffice project evolved?.

     
  • stefano 2:29 pm on February 5, 2014 Permalink | Reply
    Tags: community, gender, , , , profile, sex   

    Tracking gender diversity in the OpenStack developer community 

    The OpenStack Foundation has always tried to increase genders diversity in our community: we joined the Outreach Program for Women, established clear policies for our summits and in general we’ve been actively promoting good behavior across the board. A few weeks ago I realized that we were lacking of a decent way to track our progress in gender diversity in the OpenStack developer community and decided to improve the situation.

    When Anne asked me for the number of women or non-male developers in OpenStack, I realized that we don’t have that number. When people register to become OpenStack developers they need to become members of OpenStack Foundation and have an account on Launchpad. Neither of them track gender information. The best number I had to offer was the t-shirt kind requested at our Summits. If you don’t measure it you can’t improve it, the saying goes. So we thought we need to offer the option for Foundation’s members to tell us their gender, if they want to. How do we ask for gender without being disrepectful to non-binary genders?

    We did some research, discussed them on the bug and adapted the best practices to our case. We wanted to keep the choice short and not to offend anybody by leaving out options. An open entry form leads to hard to use data (people have very creative ways to spell just about anything), using pronouns would have made translations a nightmare. We need a way to restrict options so we can easily count them in the database so the binary options male/female were set first and ‘Prefer not to say’ was soon added as another option, since it’s really not mandatory to disclose that information. For non-binary genders using “Non-binary” sounded too geeky to me; using ‘other’ sounds weird, borderline offensive. We came to a consensus on my suggestion to have an open entry prefixed by “Let me tell you”. I liked this phrase because I feel like “Let me tell you” empowers the member to own their own gender definition. The new form is now live so you can now register or edit your OpenStack Member profile and add your gender (if you want to).

     
  • stefano 1:02 pm on January 20, 2014 Permalink | Reply
    Tags: community,   

    Why people contribute to OpenStack 

    A few days ago, I asked 55 OpenStack developers why they decided to submit one patch to OpenStack and what prevented them from contributing more. The sample polled people who contributed only once in the past 12 months, looking for anecdotal evidence for what we can do to improve the life of the occasional contributor. To me, occasional contributors are as important as the core contributors to sustain the growth of OpenStack in the medium/long term. Since it’s possible that the community has already already hired the best candidates among Python developers and system operators, to sustain the growth of OpenStack we need to tap into the wider Python community and experts of large distributed systems coming from other languages (Java, for starters). Knowing what hurdles new contributors face when they first join OpenStack is a first step to make onboarding easier and multiple contributions more frequent.

    People who replied are for the most parts users of OpenStack, that is developers and dev-ops people working on deployments of OpenStack for internal usage and system integrators who develop and deploy OpenStack for their customers. A third group of occasional contributors are developers of projects that use or are used by OpenStack, like Docker or Ceph.

    The top reasons to submit a patch went from the practical convenience of having patches maintained upstream, to fixing bugs (discovered during a proof of concept or in more advanced phases of a deployment) or to add/fix funcionalities to better integrate OpenStack with other projects. Finally, people contribute patches for personal growth and to enrich resumes.

    Why don’t they submit more? There are three main stumbling blocks. Legal hurdles delayed contributions, and even prevented (at least) one. The reasons for the delays range from NDAs with customers to incompatibility with corporate policies to release software under open source license and sign a Corporate Contributor License Agreement. Another group of reasons for the delay is the long time it takes for contributions to travel the review queue. The time it takes for patches to get in OpenStack repositories was mentioned more than once. Finally, the lack of simple issues to fix in the spare time: apparently the community fixes simple bugs too rapidly.

    The results cannot be considered representative but they seem to confirm that legal hurdles and speed of the reviews are preventing more casual contributions. While there are already many discussions on how to improve reviewing times, changing the way we handle contributions legally requires a massive endeavour to change OpenStack Foundation’s bylaws. The fact that simple issues to fix are hard to find is new to me: it may indicate that there are lots of people joining the community fixing these ‘low hanging fruits’ or something else. I think more analysis is needed in this area.

     
    • everett_toews 11:39 am on January 23, 2014 Permalink | Reply

      What? Nobody fessed up and admitted it was to get a free pass to the Summit?

      • stefano 4:24 pm on January 23, 2014 Permalink | Reply

        Surprising :) But no, I confirm, nobody mentioned that :)

    • tadowguy 6:32 pm on January 24, 2014 Permalink | Reply

      One of the reasons Ubuntu Harvest (http://harvest.ubuntu.com/) was created was to highlight easy opportunities for people to work on in Ubuntu. While it never reached it’s full potential, I think the theory is good. Perhaps a tool like it would help?

      • stefano 6:39 pm on January 24, 2014 Permalink | Reply

        I didn’t know about Harvest, thanks for bringing it up. One comment I heard is that the ‘low hanging fruit’ bugs are solved too rapidly for casual contributors to find/fix them or there are not enough bugs tagged properly.

    • twitter_tadowguy 6:41 pm on January 24, 2014 Permalink | Reply

      @Stefano, sorry I failed to include this before, took me a few minutes to find it, but look at this time to fix chart, it’s basically approaching zero.

      http://activity.openstack.org/dash/newbrowser/browser/its.html

      Last week I had a bug that I’d been working on (and was assigned to me) “taken” when someone submitted code that marked it as fixing it. I worked with the developer who ended up fixing it, but it was frustrating.

  • stefano 10:05 am on January 13, 2014 Permalink | Reply
    Tags: community, , , recruiting   

    Exploring why people contribute to OpenStack 

    No doubt that OpenStack is one of the largest open source development efforts existing at the moment, with Linux, Debian and few others.  What can be improved to make the OpenStack community grow faster? How can we help new contributors become productive more rapidly?

    Whatever dimension you look at, the growth of the OpenStack developers community is astonishing. I’ve looked at the reasons for this growth and I’ve identified four main causes summarized in my presentation at Linux Conf North America and Open World Forum in Paris last year:

    • One clear mission to solve a hard problem
    • One initial core team with strong motivation to solve that problem
    • One team dedicated to recruiting new team members
    • One clear path to onboard new members in the team

    The first two points are pretty clear already and don’t seem to need much tweaking: those ain’t broken, so no need to fix’em. The other two are not broken either but they’re the kind of stuff you want to stay on top of because once you notice they’re broken, the cost to fix them will be higher. Recently I started to ask myself what margins of improvements there are in recruiting and onboarding new members in our communities.

    I quickly realized that while we know a lot about the top contributors to OpenStack, we don’t know much about the ‘long tail’ of contributors. It’s fairly easy to understand why the people responsible for 80% of OpenStack code and documentation work on the project. But who are the occasional contributors and what are their motivations to join the community? I embarked on a quest to get to know this long tail in an effort to understand how we can improve recruiting and onboarding new developers.

    After a conversation with Asheesh Laroia, of OpenHatch fame, I selected 55 random developers from the list of those who submitted a single change to the integrated OpenStack programs during the past 12 months. These people went through quite a huge chunk of trouble only to submit one single patch: besides learning enough of the quite complex OpenStack code, they had to sign the Individual CLA (maybe the Corporate CLA, too), learn about git review and the other tools, go through the code review process. I would expect that whoever goes through that process, does it with the intention to stick around. So I asked the sample two simple questions:

    • What made you decide to submit a patch to OpenStack?
    • What prevented you to submit more patches?

    I’ll wait a few days for their answers and share more details. Feel free to answer the questions leaving a comment here, too.

     
    • Kevin Fox 9:14 am on January 14, 2014 Permalink | Reply

      I’ve been trying to contribute since October. Ran into major issues with the contributor agreement. Mailing list posting here:
      http://lists.openstack.org/pipermail/legal-discuss/2013-November/000101.html

      Motivations for contribution back include:

      Giving back patches to the community as a small payment for receiving so much.
      Getting recognition for the patches we are using internally in our lab.
      Upstreaming of our patches so we do not have to port them on every updated release.

      I have not contributed yet, or was prevented from writing a few other patches due to the CLA really not fitting our situation. Our organization has, after years of effort, figured out how to release software open source. The org has not ever ran into a project that needed a CLA though, and it may take several more years for it to come to grips with them. The OpenStack project itself does not have a CLA that fits the situation either. The legal team is reviewing the issue and is working on it, but it is very slow going.

      IMO, the CLA has been a very high hurtle that projects like the Linux Kernel have very successfully gotten away without.

      • stefano 9:48 am on January 14, 2014 Permalink | Reply

        Thank you Kevin. Your case is indeed a painful one, I apologize for it. I wish the next Board of Directors at the end of January will evaluate a solution.

  • stefano 4:55 pm on November 18, 2013 Permalink | Reply
    Tags: community, , hong kong, , summary,   

    Wrap-up post OpenStack Summit in Hong Kong 

    Back from busy days in one of the most exciting cities I’ve ever visited, I needed some time to put thougths back in order, recover from jet lag and deal with my irremediably broken WordPress installation (will probably blog about this later, too). Hong Kong was a blast in many aspects. The Summit itself started with lions dancing at the sound of drums in front of over 3,000 people:

    And then we saw that Bejing is the first city by total number of contributors to OpenStack in the whole world:

    There has been an incredible growth inside and around OpenStack, the project is growing fast. Growth is good, it’s what we wanted so we have plenty of reasons to celebrate. The second edition of the User Survey brought us more insights about usage of OpenStack around the world. We announced our first OpenStack Ambassadors, people who will help the OpenStack Community team get closer to many communities around the world. It was great to meet personally more women from the Outreach Program for Women of OpenStack. we’ve been doing this for over a year now, it’s a thing.

    IMG_20131111_204451Growth also brings challenges and some of them were evident in some of the conversations had at the Summit, around it and after. A few signals I caught during and around the Design Summit sessions highlighted that we may need to start taking new steps to reinforce the culture of collaboration inside the project. The challenges highlighted go from lack of reviewers (not core reviewers, just developers who pay attention and help others), PTLs getting overloaded, the high traffic on the Development mailing list (which leads to loss of information), the increasing number of questions on Ask OpenStack with no interactions (no up/down votes, comments, etc) and little engagement in its Chinese version, the challenges inside the Internationalization Team with processes and tools. We’ve also heard of a very few Design sessions where it was too hard to have a productive discussion because of one or two uncollaborative people.

    Since we’re getting so many new developers in the project we’re probably getting to the point where we can’t assume they are accustomed to contributing upstream first. The founders and first members of OpenStack all had a brilliant pedigree of open source contributions and collaboration. New members of the OpenStack Foundation may need some help to succeed. I enjoyed the session Getting Your Blueprint Accepted Quicker: the VPNaaS Use Case so much that I’m proposing the Upstream University training as an official program at the OpenStack Foundation to help new members. I’ll write more about this in the future.

    The next six months will continue to be super exciting and full of things to do. If you have missed Hong Kong go watch the recordings of the sessions  keep watching this space for more news.

     

     
  • stefano 10:37 am on July 17, 2013 Permalink | Reply
    Tags: community, linus, , ,   

    What Linus can do inside Linux community and you can't do in yours 

    Linux kernel community has long been considered the greatest of all the open source communities. Linus Torvalds and his team has set the ground for open source development, defined processes and tools adopted and shared by other successful projects. The Linux kernel mailing list with its public review of patches and git, the tool to manage the incredible flow of code among thousands of people in tens of different branches laid the ground for many other open source projects. Even OpenStack doesn’t get close to those number (although OpenStack is only a three years old toddler and the kernel is old enough to vote and drink.) Linus has built an incredible community and an impressive culture around it. A culture where technology rules everything and also profanity and insults are common. And the results are clear: it worked for Linux kernel.

    This doesn’t mean that any community can live and prosper like the Linux kernel with the same culture of harsh criticisms, middle fingers or what Linus calls management by perkele. In fact, I think nobody else can afford managing open source communities the way Linus does. Torvalds can get away saying things like “trying to come up with some ‘code of conduct’ that says that people should be ‘respectful’ and ‘polite’ is just so much crap and bullshit”. I certainly can’t and chances are you can’t either.

    Now if you ask me if Torvalds should change his attitude my answer is: no, he is what he is and he’s made what he’s made because (or despite, who cares: results matter) of what he is. Should his lieutenants be assholes too? Of course not, and that’s why the kernel is still one of the most successful open source projects out there.

    via Linus Torvalds defends his right to shame Linux kernel developers | Ars Technica.

     
    • ladquin 11:18 am on July 17, 2013 Permalink | Reply

      I do think he should, but I also think he’ll never be able to. Not just because he feels completely right and entitled, but also because the success and achievements of the whole community have somehow created a sense of justification for such behaviour: “Hey, this guy is quite offensive…”, “But he created the linux kernel and changed the world! Who cares if he calls you an idiot??”.
      Again, I don’t expect him to change in any way, and I don’t know what the rest of the LK community will do about that, but now that I got some further insights into the communication “style”, will I ever consider joining such a group as a contributor? No.

      • Stef 11:25 am on July 17, 2013 Permalink | Reply

        Laura, I see your point and I agree with you. I probably wouldn’t join such community either. My point is that this harsh culture hasn’t prevented thousands of people to join the Linux kernel development and, more importantly, stick with it. If you wouldn’t join such community somebody else will. Communities don’t need to be for ‘everybody’, they just need to be for enough people to achieve their goals. I will argue for a change in the culture of Linux kernel when the current one starts to become clearly an obstacle to developing the kernel. In other words, until it’s not visibly broken, don’t fix it.

  • stefano 4:16 pm on March 23, 2013 Permalink | Reply
    Tags: , community, , , ,   

    Streaming Audio from Raspberry Pi – part 2 

    Episode two of my experiment with the Raspberry Pi I have received at Pycon 2013. On the way back from Santa Clara I stopped by Fry’s and bought the only USB sound card they had in store, a weird looking Creative and a powered USB hub.  I ordered also a case from Adafruit industries (not convinced of the case though).

    Raspberry Pi and USB sound card
    The output of lsusb:

    Bus 001 Device 006: ID 147a:e03d Formosa Industrial Computing, Inc.

    Hooked them all together, installed avahi-daemon on the Pi so I can ssh into it easily from any lan (ssh raspberrypi.local, although I should change its name to something more unique). Tested arecord locally first. It took me a while to figure out how to use arecord, it’s old stuff that I’m not very used to. You need to specify the hardware device. If you get this sort of error:

    arecord: main:682: audio open error: No such file or directory

    probably you haven’t specified that you want to record from the card that actually has an input device

    pi@raspberrypi ~ $ arecord -l
    **** List of CAPTURE Hardware Devices ****
    card 1: Audio [2 Channel USB Audio], device 0: USB Audio [USB Audio]
    Subdevices: 1/1
    Subdevice #0: subdevice #0

    I hooked my phone’s audio player to the mic input of the USB card so that there would be constantly audio coming in the Pi, then started recording

    pi@raspberrypi ~ $ arecord -D hw:1,0 -f s16_le -c 2 > test.wav

    I have specified the hardware device I want to use, the format and the number of channels. Playing back that file worked.

    pi@raspberrypi ~ $ aplay -D hw:1,0 test.wav

    Next step was to capture live audio from the line input of the USB card, transcode that to OGG Vorbis and ship the bits to the remote Icecast server I setup last week. I quickly gave up on ezstream and started using ices2, the Icecast client: it seems easier to manage as it takes care of the encoding. This is the input module I used for the Pi:

    <input>
    <module>alsa</module>
    <param name=”rate”>16000</param>
    <param name=”channels”>2</param>
    <param name=”device”>hw:1,0</param>
    <!– Read metadata (from stdin by default, or –>
    <!– filename defined below (if the latter, only on SIGUSR1) –>
    <param name=”metadata”>1</param>
    <param name=”metadatafilename”>liveaudio</param>
    </input>

    The USB soundcard I’m using sends 16000hz samples. I chose not to resample that, only to downmix stereo to mono to save bandwidth.

    <–  stereo->mono downmixing, enabled by setting this to 1 –>
    <downmix>1</downmix>

    And all seems to work: the Pi sends a clear signal up to the streaming server and it’s been doing that for a while. Big success so far. Next step for me will be to write a script that grabs data from the OpenStack Summit schedule for one room and adds that information as metadata for the streaming: this way the listeners will have an idea of who is speaking or what the session is about.

    Update: the stream was having a wide latency, around 20 seconds so I decided to play a little bit with the sampling rates. The latency went down to around 1 second using  <param name=”rate”>48000</param> in the input module and  <samplerate>48000</samplerate> in the encode module, with no resampling. Unfortunately the USB card dies every now and then when not connected through a powered USB hub. Too bad, because the USB hub looks ugly.

     
    • Ole N 11:58 pm on May 14, 2013 Permalink | Reply

      Could you please give som more information about that soundcard? Can’t find it at Creative.

    • stefano zorzanello 4:31 pm on May 15, 2013 Permalink | Reply

      Hi Stef,
      thank you for your great report about Pi audio streaming…..
      I’m completely new to this great world
      I would like to know if you think the Raspberry Pi would be the right shield for my project.

      I am a musician and sound designer, using Max/Msp, particularly interested on soundscape projects and researches, and this project is for an interactive sound installation in a real environment, with the sound produced by cicadas. As I’d prefer not to abandon a computer in a field, I assumed to use a microcontroller for this purpose.

      So Raspberry Pi should be involved in steps 1-2-4-5 of the following:

      1) sampling the sound locally produced by cicadas males during summer: mono signal is fine.
      2) sending a stream of samples through the web in real time: Raspberry Pi should be connected to the web via 3G (no ethernet cable).
      3) another computer placed in a studio should get this stream, making the audio treatments, re-sending it trough the web (splitted possibly into four independent synchronized channels-signals)
      4) downloading the 4 processed streams;
      5) distributing the sounds on a local multi speaker system, 4 channels basically.

      If you think that all this is feasible through a Raspberry Pi plus a proper internet networking shield, I would buy it as soon as possible. Could you also tell me in case it would be possible with only 2 channels (stereo) playing?

      I thank you very much for your attention, I stay waiting form an answer from you.

      Best regards

      stefano zorzanello

      • Stef 4:40 pm on May 15, 2013 Permalink | Reply

        Hi Stefano, your project sounds interesting. I think you can do step 2 with the Pi but you’ll need to find a USB GPRS modem that supports ARM Linux drivers. I have no idea about that though. Also, I found the soundcard I bought not to be very stable: at times the driver seems to crash and the streaming stops. Unfortunately I have very little time to debug this. I’m considering shopping for a board that has native audio input and similar cost.

    • stefano zorzanello 5:10 pm on May 15, 2013 Permalink | Reply

      thank you for your interest!
      yes I’ve to look for this USB GPRS modem that supports ARM Linux drivers……. maybe this will be the rock to climb…. I’, pretty sure you will find a more stable sound card…
      I was wandering for arduino plus audio codec shields… but it seems that arduino has not enough resources to support both 3g shield and audio codec at the same time……
      any way I’ll keep on studying the feasibility…

      in the while thank you very much..

      ciao

      stefano (so I have to avoid to sign myself “Stef” as I usually do!!)

    • Jeroen 8:29 am on July 4, 2013 Permalink | Reply

      Very interesting article! Did you already found a new sound-card for your project? Ad if so, why did you pick that one?

      Sincere greetings,

      Jeroen

      • Stef 10:48 am on July 16, 2013 Permalink | Reply

        I haven’t looked for another sound card, yet. This project has fallen a little behind in the todo list unfortunately. I picked that one because it looked cool and was readily available :)

    • Robert 10:56 am on September 6, 2014 Permalink | Reply

      My first idea to stream audio would be to use pulseaudio’s network features. Have you thought about this? I’m looking to stream music from my laptop to 2 PIs in different rooms with hopefully not negligible latency.

      • stefano 4:44 pm on September 8, 2014 Permalink | Reply

        I haven’t thought about pulseaudio since I was going to stream across the Internet I’ve assumed I needed something that took into account the latency. I may be wrong but I thought pulseaudio is designed more for LAN use than wider area network. Let me know how that experiment goes.

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