Team blogs
This presentation was the first run of a consolidated slide show about the oVirt project. (ODP, PDF) Wow, it was a lot of dense content to cover, with a range of topics. What is KVM, what is OVA (Open Virtualization Alliance), how KVM works in general, why it’s superior and desirable in the enterprise, history of the oVirt project, what the components of oVirt are, how the community works, how to get involved, and lots of other material in between.
Where it comes to talking about all the technologies involved, I admittedly fell a bit short. I haven’t been keeping up on every TLA in the related technical spaces around oVirt and KVM, and I didn’t get through a full research on all the topics before the presentation. One of my strategies, though, is to just run this presentation to learn what is and isn’t appropriate for a presentation. So I told the audience it was a new presentation, thanked them for being beta testers, and acknowledged that some in the audience certainly know more on the topic than I do and I appreciate chiming in with answers.
Which happened a few times, thank ye gods and goddesses.
In addition, I chopped up the original 21 slide presentation in to 91 slides, with each slide covering one topic. This is similar to one paragraph for an idea when writing. The decision to do this came from a late-Saturday-night discussion with Josh Berkus, who has some fame and skill in presenting. (Once I learned that a slide of mine from a State of Fedora Lightning Talk had made it in to Josh’s deck-of-shame – slide 5 in this PDF - I figured it was worth a rethink-of-approach. Hey, we all make mistakes.;-D ) The 91-slide version was not optimal, but it was better than the 21-slide version.
Now, to help this slide show be more useful, I will do my part in filling out the notes sections where I actually know what I’m talking about. Jason Brooks is working on a consolidated deck that improves on this one, and I’ll get my notes in to that one as the canonical.
[ianweller@hovercraft fedora-business-cards]$ git diff --stat 0afed4e HEAD
INSTALL | 4 +-
MANIFEST.in | 2 +-
README | 15 +-
config.ini | 4 -
fedora-business-cards.spec | 28 +--
fedora_business_cards/__init__.py | 13 +-
fedora_business_cards/common.py | 104 ++++++++++
fedora_business_cards/config.py | 66 ------
fedora_business_cards/exceptions.py | 37 ----
fedora_business_cards/export.py | 144 ++++++++-----
fedora_business_cards/frontend/__init__.py | 26 +++
fedora_business_cards/frontend/cmdline.py | 236 +++++++++++------------
fedora_business_cards/generate.py | 60 ------
fedora_business_cards/generators/__init__.py | 61 ++++++
fedora_business_cards/generators/fedora.py | 278 ++++++++++++++++++++++++++
fedora_business_cards/information.py | 64 ------
pavement.py | 45 +----
templates/back-europe.svg | 76 -------
templates/back-northamerica.svg | 75 -------
templates/back-overnightprints.svg | 76 -------
templates/front-europe.svg | 160 ---------------
templates/front-northamerica.svg | 152 --------------
templates/front-overnightprints.svg | 152 --------------
templates/templates.ini | 17 --
24 files changed, 694 insertions(+), 1201 deletions(-)
What changed?
- Removed the Fedora Talk number (long overdue).
- Removed fill-in-the-blank templates and added code to generate the SVG dynamically in Python. (This now lets us support any given business card size, with any given margin for professional printing.)
- Changed the fonts to Cantarell and Comfortaa.
- Made the business card generation modular so that you can create a non-Fedora business card with the same code that makes dynamic sizes and conversion to CMYK and PDF somewhat easier than doing it from scratch. (Feature request by Mel Chua, who told me she will write a Beefy Miracle module to test the new modularization support.)
- Made palette-based RGB to CMYK conversion actually sane.
- Various fixes.
Okay, so 1 visible change. I lied :)
What’s next?
- Potentially moving things around on the Fedora card layout
- Possibly renaming fedora-business-cards to something more generic due to its modularization
- Actually making a new release so that people stop accidentally printing Fedora Talk information on their cards
Here are the slides from my Friday talk at SCALE10x in the FOSS Mentoring track, “How to start an open source project of any scope and size“: ODP and PDF. These slides are (as usual) under a Creative Commons CC BY SA 3.0.
Although a brand-new presentation, I think this one went over pretty well. All of the material I know by heart and can speak on extemporaneously (i.e., for many hours on end). For this reason, my notes section is unusually (for me) empty. I’m going to work on filling out those notes – that makes it more useful for others to reuse, thus adding more fuel to the Creative Commons licensing – and I’ll make a generic version available in TheOpenSourceWay.org presentations directory.
This was a good enough talk that I think it can be useful again in other locations – it really does a good job of distilling a huge amount of the information you need to start, sustain, and grow an open source project. I’ll be submitting it other places, hopefully more people agree with Gareth and put me on somewhere!
I'll be heading to SCALE early tomorrow morning. I had previously been accepted as a speaker last year but couldn't make it due to travel constraints. So I'm even more looking forward to attending the conference. In fact, I'll be talking Saturday afternoon about the experiences we've been having with our POSSE workshop that introduces faculty to open source projects (Saturday, 4:30pm, Bel Air room, details here).
Similarly, I will be giving a short but intense introduction to the workshop itself on Sunday. If you've been trying to get involved in an open source project of your choice but haven't found the right path yet, we'll be there to help. In particular, we'll try to bridge cultural norms that can differ from project to project. If you're interested, swing by (Sunday, 11:30am, Bel Air room, details here).
I'm also very much looking forward to SCALE on a personal level. A lot of my friends and former colleagues are apparently going, so it's going to be good to catch up. That being said, the schedule also looks fabulous and I'll try to make it to some sessions (watch out for #scale10x on Twitter). See you there!
Permalink
| Leave a comment »
Earlier, word spread quickly that Wikipedia was going to go dark today (January 18), leaving millions of students without access to their favorite research resource. Soon thereafter, rumours surfaced describing ways to "circumvent" the blackout which a variety of websites simulate as part of the ongoing protest against the SOPA and PIPA bills. At opensource.com, Ruth Suehle has been actively capturing website that express their opposition to said bills. So head over there, check out the currently (at the time of writing) 66 screenshots and let us know if there are any other sites you came across: http://opensource.com/life/12/1/january-18-captured-sopa-blackout-gallery
Permalink
| Leave a comment »
After having to sadly cancel last year for SCALE 9X, my family and I are looking forward (nervously) to SCALE 10X this coming weekend. You’ll see us at:
So my Friday talk at 3 pm is,”How to start and sustain an open source project of any size“. I’ll be going through the start/sustain bits, and trying to do some actual work with the audience. I’m hoping some of the audience will be interested in starting a project, or already working on it, and we can do some work for their efforts as a group.
Also on Friday I’ll be attending the Fedora Activity Day (FAD) that starts at 10 am – I’ll be there to help and learn.
My daughters are joining their friend to give “Ultimate Boredom 2.0” at 11:30 am on Saturday as part of the SCALE: The Next Generation youth conference. I think the talk title is an allusion to how much they think they will bore you (ultimately), which must be greater than the two other times they have given a similar talk (2.0). In addition to talking about how they’ve participated in open source projects, they’ll cover some of their favorite free/open source software – last I saw the presentation covered GIMP, OpenShot, TuxPaint, and Hydrogen.
Finally, on Sunday morning at 11:30 am I’ll be giving, “oVirt – Infrastructure and management platform for the data center“. This is a general what-is-oVirt, how-did-it-come-to-be, where-might-it-be-going presentation, similar to the one Carl Trieloff gave at the start of the oVirt workshop in November 2011.
See you in LA!
If you have troubles with wikitables, especally with the insane ones on the FUDCon Blacksburg wiki page, please do not hesitate to contact me for help. :)
I’ll be driving this evening and flying tomorrow morning but you can easily catch me in between. If I’m not on IRC as ianweller, send me an email at phone@ianweller.org.
Hi folks,
If you’ve got a spare 15 minutes or so today, please do the following:
Please especially look for:
- Misspelled words
- Broken links
- Incorrect page numbers or references to page numbers
- Incorrect information
- Use of straight quotes instead of curly quotes
- Ian finally losing it and filling an entire page with nothing but the word “shit”
Thanks! You’re all life savers, whether you know it or not!
I've recently had the pleasure of watching Senna, The Company Men and Beginners, in less than 48 hours. All of them are good movies, but two of them were particularly well done. Here's why.
Senna
I started out with Senna the night before my flight back home. It's a documentary that portrays, well, Ayrton Senna. The movie maps archive video material from his races and family tapes with audio commentary from his friends, competitors, colleagues and relatives. In the beginning, I was a little sceptica, as I felt the movie was starting a little slow: it introduced Senna as a driver, referred back to his go-karting experience and his Brazilian origin. However, that feeling went away soon enough. Looking back, I'd argue that it's the focus on Senna, the person as a whole, that made the movie appear so very appealing to me. After all, his passion was racing. I didn't find any obvious unnecessary speculations or overstatements in it -- the movie simply told his story. But it did so in a way, that permitted the audience to become emotionally closer to the happenings on the screen. Certainly, there no surprises. The story had been told many times before. But for somebody, like myself, who had been interested in Formula One racing at younger ages (in the times of Michael Schumacher and Mika Häkkinen) but never followed up beyond watching a race every now and then, it was intriguing. The movie provided interesting background knowledge that I was previously unaware of; yet, it also introduced the people I had come across and heard about. Roger Ebert reviewed the movie, giving it a mixed rating. He writes: "Senna is a documentary that does the job it sets out to do. I wish it had tried for more." Yes, maybe it only achieves what it set out to do; but there's only so much to say. The rest is history. And it tells it in the most powerful way I've seen over the past year.
The Company Men
When considered going to the movies over the summer, I was looking at The Company Men. To be very clear: I'm glad I didn't. It's not a bad movie. It's just not a great one. Maybe it was the fact that I watched it in an airport terminal when my Swiss Air Lines flight had been delayed, but I simply wasn't impressed. There've been a couple of movies on the recent recession and its impacts on society (very much in a way Brothers tackles the Iraq War), but The Company Men is certainly the one that convers the topic right head on. Ben Affleck, Chris Cooper and Tommy Lee Jones all work for the fictional company GTX, when the risk of a takeover leads to closure of multiple business lines that affect all three of them. In short, they are layed off one after another. When I watched the trailer, I felt that it wasn't clear that all three of them worked for the same company. I went into the movie expecting a set of episodes of people dealing with suddenly becoming unemployed. And to some extent, that's what the movie does. Yet, it spends too much time on it. Bobby Walker, played by Affleck, is the first to go. And boy, it takes him a long time to accept his new situation. In one of the stronger parts of the movie, he tells his son that he can't drive him. His son leaves obviously disappointed; and so Bobby follows him, encouraging to play Xbox instead. That's when his wife, played by a very strong Rosemarie DeWitt who returns from another major performance in Rachel Getting Married, tells him that his son had returned the Xbox. He didn't feel like they could afford it anymore. And so the movie keeps on going. There are surprisingly few surprises. And the few of them that are, didn't leave me feeling that I cared. The people themselves are somewhat likable, but it's probably that directory Wells didn't spend a whole lot of time introducing me to them; that is, except for letting me watch them deal with their situation. For example, I wish that he took more time to effectively show the conflict between Tommy Lee Jones and his boss, Craig T. Nelson. There's another strong scene in there, when the HR department is going through a list of people to lay off and Gene, represented by Jones, points out that apparently he had falsely assumed that the company was shooting for higher standards than just the question "is it legal?". Again, it's a good movie. And I have to commend it for dealing with a complicated topic. But in this case, I think Roger Ebert's comment on Senna fits much rather: "I wish it had tried for more."
Beginners
Finally, I had the opportunity of watching Beginners on my flight to Zurich. Since it was a red-eye, I was originally planning on sleeping, but I had wanted to watch Beginners for a while, and so I went for it. Beginners tells the story of Oliver, played by Ewan McGregor, who is reflecting on his relationship with his parents (in particular, his dad, who is brilliantly delivered by Christopher Plummer), as well as his girlfriends and his dog. Simply put, it's a film that makes its points so very subtly, making it magnificient. On multiple occasions, I didn't start laughing out loudly. I smiled silently. And it didn't even take much: the simple use of a piece of piano music got me to smile. Think 500 Days of Summer, yet much less hectic, almost in a Woody Allen style. Then again, like aforementioned movie, Beginners isn't a love story. It's so much more. I was amazed by its simplicity. I suggest you check it out.
Permalink
| Leave a comment »
My last final is tomorrow morning at 7:30 a.m., and I’ll be damned if I don’t find a way to procrastinate. This is my way of procrastinating.
Apart from my day-to-day stuff at Red Hat (making sure servers don’t catch fire, cleaning out spam traps, the like), I’m going to be working on a couple of projects over winter break.
FUDCon Blacksburg Booklet
Here’s the booklet pages from Tempe last year. We’re doing the same thing this year. It’s pretty much that simple.
What needs to be done:
- Map needs rendered. I’m going to try to use mapnik instead of osmarender this year because mapnik looks a gazillion times better.
- Recreate the schedule pages, possibly expanding the section to three pages (and moving the map into 1 page since we just don’t have that many things to label).
- Find a bunch of local vendors close to campus, their contact information and when they’re open.
- Figure out deets on a hack room and some other details that should go in the booklet.
The more things above that get done by volunteers, the less I have to do, and the more likely this booklet will be awesome. So please help if you’re bored! :)
fonts.fedoraproject.org
I have a new pet project, and hopefully something will come out of it this time.
There are a lot of freely-usable fonts in Fedora that you can install with yum/PackageKit. But the problem is, it’s very difficult to figure out what the fonts look like without installing them all and trying them out. You can’t easily tell what fonts have serifs, have support for the language you’re trying to write in, or actually looks good.
fonts.fedoraproject.org is a proposed website that does the following:
- Searches the yum repositories for a list of packages that provide
font(*).
- From that list, determine which packages have TTF or OTF files.
- For each package, if the package is not cached, download the package and extract the fonts.
- Write web frontend to put it all together, using
@font-face technologies. The frontend would be static HTML that is rendered once nightly if there are updates.
I’ve discussed the idea above with a few folks in Infrastructure and it seems to have fallen on good ears, so I’ll be continuing on with this project when I’ve got some spare time over winter break. If you’ve got questions or just want to discuss fonts.fp.o, shoot me a message on IRC, since I’d love to get new ideas or figure things out that I haven’t quite figured out yet :)
Oh, and also:
Yesterday, I went to visit Michael Jonas and Mihaela Sabin, both POSSE alumni, at UNH in Manchester. They are working on getting a seminar series with speakers from a variety of backgrounds going and so I was the first one talking on getting involved in open source communities (see publications).
I find it fascinating to see the differences, both in the student body and the culture at the different schools I've been visiting. UNH was clearly on the smaller side of schools, but it had a very interesting feel to it.
Joanie Diggs was also at the event -- Michael had introduced us when I previously went out for a lunch conversation. After my talk, both of us were given the tour of the school and ended up talking more about different ways of immersing students in open source projects as part of their classroom experience in Michael's office. Watch the TOS list for more!
Permalink
| Leave a comment »
So this is it. AHSE 2199 assignment number 8. Why my blog post starts with such cryptical numbers? Well, this is a special assignment in the way that I get to choose (to some extent) the deliverable for my Teaching & Learning class. But let's start at the beginning: this semester, I'm taking a class that focuses on undergraduate STEM education as part of my arts, humanities and social studies requirement at Olin. And for this class, I'll even have to create a teaching portfolio as our final deliverable! Aside from that, we've worked on our teaching philosophy statements, exercised a deep-dive into the field of cognition and analyzed several different teaching techniques. And now here we are, looking at student experiences. As you probably figured, these differ from student to student and from class to class.
Now there has been some research conducted on why that is. For example, Linda Nilson portrayed in 1997 in a chapter of her book Teaching at Its Best a number of different frameworks to look at students' learning styles. (Nilson, 1997) One of these frameworks is Kolb's "model of the learning cycle and learning styles", in which he derives a set of styles, called the "accommodator" who relies on concrete experience, the personally and emotionally involved "diverger", the conceptualization-preferring "converger", and the "assimilator" who excels at organization and synthesis. (Kolb, 1984) I won't go into too much more detail explaining each of these, since you can read the paper yourself. However, there shall be one exception: our professor challenged us to identify our preferred learning style -- "preferred" since there are so many factors influencing this and it can be quite hard to narrow it down.
So let's talk about myself for a little bit and put the cards on the table. The description of an assimilator describes that type of learner as somebody who "combine[s] abstract conceptualization and reflective observation into a style that excels at organization and synthesis" as well as the fact that they "specialize in integrating large quantities of data into a concise, logical framework, from [which] they extrapolate theories and generalizations". (Nilson, 1997) So far, so good. But does that really sound like me? Well, I've been doing release engineering since I was 16. Wikipedia describes release engineering as "a sub-discipline in software engineering concerned with the compilation, assembly, and delivery of source code into finished products or other software components". (Wikipedia, 2011) Wow, that's a lot of stuff. And to be honest, I do like it. I enjoy being able to pull several complex moving systems together, keep track of their schedule and integrate them all together into a final product. For example, that's what I was doing as the release engineer of Sugar on a Stick that concluded components from Fedora (the operating system layer), Sugar (the desktop environment) and various Activities (the applications that run on top of the learning environment). And guess what? -- Their respective developers weren't necessarily talking to each other!
But that's only one part of my case. Prepare yourself for a shocking revelation! For some inexplicable reason, I also enjoy researching highly-complex travel bookings that require me to pull multiple sets of data together and explore various possible options to hit the cheapest price-tag. While that might sound less exciting compared to release engineering to the average reader, it's something I hadn't noticed before. In a similar, albeit separate vein, assimilators apparently also appreciate "instructor demonstrations and modeling of problem-solving methods" (Nilson, 1997). This comes to no surprise: I personally find well-prepared lectures in which the instructor provides a walk-through for a certain problem just as exciting as project-based team-work approaches. That being said (and to add a grain of salt here), I wouldn't describe myself as a full "assimilator". Nevertheless, It appears to be the style that I can identify with the most, which is why I've decided to not modify that choice following the conversation in class. In the next paragraphs, I'll add a grain of salt, as well as describe my choice of deliverable.
In particular, there are indications that I appreciate problem-solving and particularly cognitive apprenticeship models that enable and support direct interactions with mentors and instructors (who can but don't necessarily have to be the same person). This last point has been especially shaped by some of the readings from my Teaching & Learning class. In my initial teaching philosophy statement, I wrote: "I work towards enabling my students to bridge the classroom and the real world." (Dziallas, 2011) I fostered this belief through personal experiences in the world of software development communities, where strong mentors proved to be an invaluable and incredibly supportive resource to me. One of them later wrote that he had originally assumed that I was a teacher: "he was passionately involved in solving a problem that was important to him". (LinuxQuestions, 2009) This passion is what I believe I need to facilitate for my students. Granted, not everyone is intrinsically motivated, but there are ways of increasing that chance. One of the papers I found tremendously helpful was John Seely Brown's situated cognition and cognitive apprenticeship (Brown, 1989). Taking "Just Plain Folks" (because that's what we all are) and turning them into actual practitioners -- through apprenticeship models -- is something I strongly believe in.
And this brings me to the form of my deliverable: internet access for the masses has enabled the formation of communities that have proven to be incredibly powerful. Clay Shirky argues in his book Cognitive Surplus that we're now learning how to use our free time in more meaningful ways, by communicating and collaborating in an open environment where the simple click on a button labeled "publish" can be enough to make a contribution. (Shirky, 2010) This goes hand in hand with Etienne Wenger's framework of communities of practice that are all around us, in which people share a certain passion or concern and interact on the basis of this belief. (Wenger, 1996) One of the things that enable these communities is the ability to communicate freely, both in public and private channels. And as previously mentioned, this is something that I experienced myself and that shaped my way of learning thoroughly, through my time in the different open source communities. And that's why I'm writing this assignment as a blog post, opening it for the community out there, to take it and comment away!
But before I diverge too much, let's talk about my own classroom experience in college, here at Olin. It's funny; one of the classes I enjoyed the most is Modeling & Simulation in my first semester. The class revolves around mathematical and physical problems, but introduces the student how to abstract unnecessary information away and create a model for a given phenomenon, which can then be converted into an actual simulation using, for example, MATLAB. Do you notice something? It includes conceptualizing complex real-world systems, analyzing them and using the logical framework of computer science to create a deliverable in form of graphs or even papers supporting a certain claim. If you go back a couple of paragraphs, you'll notice that most of these aspects meet the assimilator's learning style. On the other hand, another one of my classes, Design Nature, left me desiring change after the first few weeks. I had a particularly hard time in this class, since there wasn't a lot of scaffolding being provided through my instructor and it dealt with topics I either hadn't seen before or knew I wasn't great at, inducing a sort of anxiety. This was a very open-ended class, walking students through a full design-process -- first individually, then in teams. Later on (especially after the first half of the semester), I learned to appreciate the class though and I do believe that I learned a lot of lessons, both on the design and teamwork side of things.
Elaine Seymour authored an article called "the learning experience in SME majors" in 1997 that provides interesting insights in the perspective college students are taking on their curriculum. For example, a student writes: "In my first engineering class, we were required to do 18 programs and three different languages over the semester. We were given algorithms to use for each program and just one week to complete each of them. [...] We were just expected to know so much that, if someone wasn't willing to explain it to you, then you couldn't do the programs." (Seymour, 1997) This perspective seems to be much more than a single voice -- rather, it represents a pattern of students calling out on so-called weed-out classes that don't necessarily relate to just about anything. Introducing three different programming languages can very well be useful, for example in a course on programming languages that details the differences between each of them. But why would it be, in an entry-level engineering course? Luckily, I didn't have any comparable experiences, but I feel it's very much worth highlighting that a lot of students do. Unnecessarily so.
Another paper by Carroll Seron provides an overview of different student voices at Olin and Smith College, as well as MIT. An Olin student wrote: "The fact that the faculty respects and trusts us is also a big plus. [...] We can work better in groups and learn team work skills this way, which helps when team projects are assigned." (Seron, 2008) This position is obviously contrary to the previous point made. It's something that I appreciate and value as part of the Olin experience, even back when I described it for the first time. (Dziallas, 2009) Being able to interact with faculty and students alike on a level that supports every single member of the community is a strong part in fostering collaboration. When asked to comment on a blog post for the admissions blog at Olin, I wrote: "Yes, go and meet people. They are amazing (it's generally a safe assumption that most people at Olin are amazing [for one reason or another])." (Rowley, 2011) I stand by this statement; however, I realize that it's not always possible at all schools to create an atmosphere similar to the very unique one we have at Olin. But especially in those cases where it's not possible at a school-level, I feel that it's part of the instructors task to provide a framework that students can leverage to create a safe learning environment for each other. Again, this isn't always easy -- particularly when even single courses have the size of Olin's entire student population (we're looking at a number around 350 here). But it's at least worth considering, since every single step can go a long way in making one more student comfortable in the classroom.
This way of improving the academic experience for students is unique, but it's not related to different learning styles. This doesn't mean that they don't need to be considered -- rather the opposite: faculty need to carefully consider their choices of pedagogical techniques and if possible provide alternative frameworks (for example, explicitly pointing out textbooks related to the course, even if purchasing them isn't a requirement). In a similar vein, I believe that interacting with students as often as possible can prevent disappointing experiences. Even if an instructor doesn't meet all learning styles at the same time (which they rarely, if ever, will), showing students that their feedback, opinions and thoughts are valued and considered and that they are taken seriously can help create a satisfying learning experience for all involved parties. And that's probably the one advice I'd give.
Links
References
- Nilson, Linda. "Teaching to Different Styles." In Teaching at Its Best, Bolton: Anker Publishing Company, 1997, 79-86.
- Kolb, A. and Kolb, D. "Learning Styles and Learning Spaces." In Academy of Management Learning & Education, 2005, Vol. 4, No. 2, 193- 212.
- Brown, A. S., Collins, A., and Duguid, P. "Situated Cognition and the Culture of Learning." In Educational Researcher, 1989, 18, No. 1, 32-41.
- Shirky, Clay. "Cognitive Surplus: Creativity and Generosity in a Connected Age" New York: Penguin Press, 2010.
- Wenger, E. et al. "Communities of Practice: Learning, Meaning and Identity." Cambridge: Cambridge University Press, 1998.
- Seymour, E. and Hewitt, N. "The Learning Experience in S.M.E. Majors." In Talking about Leaving: Why Undergraduates Leave the Sciences, Boulder: Westview Press, 1997, 88-177.
- Seron, C. and Silbey, S. "A Day in the Life: Inventing Engineers." Seron and Silbey, American Sociological Association, 2005.
Permalink
| Leave a comment »
The first oVirt workshop starts up at 8:30 am on Tuesday 1 November at Cisco Building O in Milpitas, CA.
This event is the open sourcing of the code behind the Red Hat Enterprise Virtualization (RHEV) management console. These assets have been rewritten in Java from the original implementation by the team that was originally from Qumranet before their acquisition by Red Hat.
As with the rest of the open source virtualization stack (Linux kernel, KVM, etc.), we all benefit the most from a strong, sustainable open upstream. Having that upstream dominated by one vendor will greatly restrict the innovation possible by the project. For this reason, Red Hat went out to a number of interested parties, offering a seat on the initial board (which is later filled meritocratically) for any organization willing to put 10 resources to work on the project. For the initial board, that list is Canonical, Cisco, IBM, Intel, NetApp, Red Hat, and SUSE.
I got involved in this because the project’s technical director, Carl Trieloff, called on our Community Architecture and Leadership team to help with community scaffolding for the launch and beyond. Since then I’ve been building the ovirt.org website, setting up the communications, creating and filling the wiki, helping with the source repository, starting an open services infrastructure team so all community members can help, and organizing this workshop with Robyn Bergeron.
So this is what I’ve been up to, which I really should have been writing about, but … ah, life.
When I spent some time going around North Carolina over the past couple of days visiting POSSE professors, I had a realization: we encourage professors to be productively lost (see here), to go out and feel immersed in a community, admit that they can't solve all of the problems themselves and act more as a facilitator in the classroom that helps identify to ask the right questions in the right place online.
This is admittedly a big step. But there's more to it: it's not just sufficient to be interested in open source in general. There needs to be some tangible goal. Participating in open source communities, as Greg puts it, needs to be rewarding. And here's the interesting part: I have come to believe that this applies to the students ("participating in open source communities means that your work will be publicly available, so you can point future employers to it") as well as to the instructor.
Think about Heidi Ellis and Matt Jadud. Heidi has been working on the HFOSS -- the H stands for humanitarian. Her students have been successfully contributing to Caribou, the GNOME onscreen keyboard and are now on-track looking at Cheese and others. Matt spent time introducing students to a variety of parts of the Fedora project. For his interface design class, he called out for projects in a blog post, which was picked up by Mo just a day later.
We have seen many successful contributions through classrooms to open source projects like these. But one thing the instructors had in common was that they were excited about the prospect of having students contribute to this or that project. Mel made an interesting analogy just now: "you don't see you're interested in 'learning languages' -- you're learning one specific language".
So, I'm curious: what are the projects you've been looking at -- and why? Is there something we can do to help? Let us know!
Permalink
| Leave a comment »
Through my visits to POSSE professors over the past couple of days I realized that one thing that is undeniably helpful is a variety of suggestions for open source related assignments. Lucky, that we worked on creating precisely something like that at an NSF-sponsored workshop at Western New England University in Springfield back in May. Clif Kussmaul suggested a project along the lines of 50 Ways to be a FOSSer. So if you're for some inspiration on how to put your students to work in open source communities, check it out: http://xcitegroup.org/softhum/doku.php?id=f:50ways
And make sure to send suggestions to the TOS mailing list!
Permalink
| Leave a comment »
In a similar vein as my previous post, this one relates to the second half of my trip to North Carolina, where I visited POSSE cohort members Richard Ilson and Rajeev Agrawal. So I'm writing this from the Red Hat office in Raleigh, where I'll be working from for the rest of the day after a notoriously early wake-up to return my rental car.
Anyway. Yesterday, I spent the morning chatting with Greg and then drove off in the afternoon to Greensboro to visit Rajeev's class at NCAT and teach a little workshop. To my surprise, they had already looked at open source communities and done a little dive-in as part of their homework assignments which was actually based on some of the Teaching Open Source materials! I decided to challenge them to think about projects they actually cared about getting involved in more and gave some examples why that could be useful, even outside the classroom.
Later that day, Rajeev and I talked about infrastructure. He's having his students blog regularly, and so he's interested in using a planet for his class. I can vaguely remember that there are different versions of planets in Fedora, but the one I recall is planetplanet. Is that a good enough choice to run with? Does anybody have straight-forward installation & setup instructions that we could pass on to his IT department?
Permalink
| Leave a comment »
This is the first part of a series of posts recounting experiences from visiting faculty throughout the semester. Right now, I'm sitting in Peet's coffee shop in the library of UNC Charlotte. I took a 5am flight this morning from Boston down here and made it almost perfectly in time for Richard Ilson's software engineering class, where I proceeded to talk about my experiences as a release engineer in open source communities. Put differently, I gave a talk that resembled the one that I previously gave at LinuxCon 2010 (slides) and spend the rest of the class doing Q & A. Some of the students had even heard of OLPC and Sugar on a Stick! I tried to articulate steps to get involved in open source communities and will give a similar presentation in about an hour for the second section of Richard's class. Afterwards, we'll spend some time chatting about possibilities and ways to immerse his (somewhat large class; overall his two sections have about 80 students) in open source projects. That's it for now, more tomorrow.
Permalink
| Leave a comment »
Now that we're almost half-way into the semester, I think it's time for some oberservations. But first, where are we now? As I previously said, we worked on packaging io and got it in fact to compile. I sent my students off asking them to finish packaging; not without a warning that the process of getting everything into shape can be quite time-consuming.
However, I found an email to the class mailing list saying that they were done. I was impressed. Today, we had the first meeting since, where we talked about a questions they had with regard to the .spec file.
Well, the obvious next step is to submit the package for review in Fedora. And while I'll be at FIE next week, it's their task to work through the review process and identify a community they would be interested in getting involved in themselves. So consider this a little call for reviewers (actually, sponsors) on my part.
Lastly, I said there were going to be observations, right? Well, I find it really interesting how to work with people of different knowledge levels. And surprisingly, this is not only the case in large classes, but also in very small ones. As previously mentioned, I have three students who all come with different preconceptions and previous experiences. I'd like them to work together locally, as well as interact with the community.
Hence, I didn't want them to be working by themselves. But I was also trying to find a way of putting everyone on fair standing when it came to contributing to an assignment. So for packaging io, I decided they would start out in class and finish after class (they met in person for that). But the most important part was that they would start pondering the spec file in etherpad, which enabled them to work on the same goal while addressing different parts that would still be visible to everybody.
Permalink
| Leave a comment »
Well hello there. Funny how the time passes, eh? I blogged a while ago about the release engineering indepedent study I'm teaching at Olin College. Well, it's been two weeks since. I assigned a number of readings for last week and we talked about concepts that characterize open source commuinties, like the following:
- scratch your own itch
- radical transparency
- with enough eyeballs, all bugs are shallow (also known as Linus' Law)
- release early and release often
I won't go into details, but we talked about was how scratch your own itch works with the other things we learn at Olin -- like user-oriented collaborative design. Later in that session, we looked into communication methods communities employ, and my students found planets, mailing lists, IRC channels and all the other jazz.
Right this very moment, we're trying to get them on a planet. I initially chose Planet Fedora and had them create a Fedora account, since we were going to have them do some packaging. Well, as it turns out, they need to be part of another group in FAS2, which they current not are. So since I'd like them to be on a planet so that the communities can overhear what's going on, they'll just end up on the teachingopensource.org planet for now. Watch out for more posts to come in over the next week!
This week, we wrapped up the previous conversation and launched into a much longer session & topic: packaging. We talked about the relationship between yum & rpm and the work the package manager does when somebody types, for example, yum install firefox. From there on, we went into a conversation on how we end up with an .rpm file and looked at several example .spec files of varying complexity.
I also got them started using IRC, so we might start having meetings in #teachingopensource soon. Funnily enough, I learned that it's good to put slack into the class schedule. We were going to package the io language together using etherpad. Kudos to Allen for suggesting that from the 7 Languages in 7 Weeks book. Anyway, we ran overtime (which is alright, since we meet in the evenings and had run under on previous sessions), but I had scheduled some slack in the schedule for next week, so we simply moved the packaging part to the next session and spent the rest of today getting everybody set up on the planet.
I'm curious how the next couple of weeks will go.
Permalink
| Leave a comment »
Well hello there. As some of you may know, I'm currently a sophomore at Olin College in MA. One of the things I'm doing this semester is running a student-taught class as an independent study on release engineering applications & lessons. What that means is that I will receive credit for immersing my (currently) three students in open source communities and introduce them to many of the concepts we're employing here, because sometimes open source communities don't realize that these concepts might be foreign to newcomers.
We meet every Thursday for two hours, and starting next week, we're also going to have weekly IRC meetings on Mondays in attempt to introduce my fellow students to software communities. Our first meeting was a brief one, mostly consisting of organizational things, but also a conversation on the current conceptions around release engineering: what is it that I mean when I call it out? I tend to define it fairly broadly as "the process of implementing and ensuring cultural, social and technical processes towards the creation and release of a [software] product". This course is going to demonstrate them at the example of a large-scale online software development community, like Fedora. When I asked how people work together today to assemble big software projects, we seperated ideas between the processes large companies use and small and innovative startups that simply run fast and don't necessarily utilize aforementioned processes.
Now for those of us in the Fedora world, that's a funny thing. Red Hat and its Enterprise Linux do clearly fall into the "large company with product and customer support" area. On the other hand, there's Fedora, which is highly innovative and drives the integration of new components forward. How do these two fit together? I believe it's a fascinating question that we'll explore more throughout the course.
I thought I'd also share the assignments for next week with the community (aside from creating a Fedora account and starting to blog). There are a few readings that we'll use to introduce concepts such as "release early, release often" and others.
That's it for now. More coming up later this week. Oh, and feel free to comment here if you've got any thoughts!
Permalink
| Leave a comment »