Teaching Open Source Planet is a Planet, a collection of personal blogs by Teaching Open Source community members working to bring the open source way into academia. We write about our inspirations and experiences in learning, teaching, and collaborating within free and open communities. In the spirit of freedom, we share and criticize in order to collectively improve. We hope you enjoy reading our thoughts; if you’re fascinated by what you see, consider adding your voice to the conversation.
This past week marked the end of Maker Party 2014. The results are well beyond what we expected and what we did last year — 2,2513 learning events in 86 countries. If you we’re one of the 5,000+ teachers, librarians, parents, Hivers, localizers, designers, engineers and marketing ninjas who contributed to Webmaker over the past few months, I want to say: Thank you! You did it! You really did it!
What did you do? You taught over 125,000 people how to make things on the web — which is the point of the program and an important end in itself. At the same time, you worked tirelessly to build out and expand Webmaker in meaningful ways. Some examples:
It’s important to say: these things add up to something. Something big. They add up to a better Webmaker — more curriculum, better tools, a larger network of contributors. These things are assets that we can build on as we move forward. And you made them.
You did one other thing this summer that I really want to call out — you demonstrated what the Mozilla community can be when it is at its best. So many of you took leadership and organized the people around you to do all the things I just listed above. I saw that online and as I traveled to meet with local communities this summer. And, as you did this, so many of you also reached out an mentored others new to this work.You did exactly what Mozilla needs to do more of: you demonstrated the kind of commitment, discipline and thoughtfulness that is needed to both grow and have impact at the same time. As I wrote in July, I believe we need simultaneously drive hard on both depth and scale if we want Webmaker to work. You showed that this was possible.
So, if you were one of the 5000+ people who contributed to Webmaker during Maker Party: pat yourself on the back. You did something great! Also, consider: what do you want to do next? Webmaker doesn’t stop at the end of Maker Party. We’re planning a fall campaign with key partners and networks. We’re also moving quickly to expand our program for mentors and leaders, including thinking through ideas like Webmaker Clubs. These are all things that we need your help with as we build on the great work of the past few months.
Last Monday I attended the first (hopefully of many!) AGM of The UK Community of Research Software Engineers. The group has been formed to champion the cause of software engineers producing software of research, be they developers who are embedded in research groups, or academics who have found themselves developing and maintaining software. Throughout the day, there were a number of issues debated by the group.
While the career path for academics hinges on them publishing papers, developers contributing to research through their work often find that they dont get the opportunity to publish. One of the problems that RSE seeks to address is finding an alternative way of universities giving recognition to the contribution of software engineers to research.
Should universities seek to support development of research software centrally, or is it better done in departments? At UCL, they’ve formed a central group of developers, partly from core funding and partly from project funding, who can provide development effort to research projects. While this provides a useful core of development expertise, a central service can’t provide the same level of domain-specific knowledge that some research groups will require, and some institutions simply don’t have the skills base in central IT to provide the development support that researchers would find valuable.
Another approach for central support for research software engineers is to provide training and tools to support good software engineering practice. Version control, continuous integration and other common tools can be instilled in researchers’ workflows through collaboration with experienced developers, or through training initiatives such as Software Carpentry. Provisioning systems like GitLab and Jenkins centrally provides easy access to infrastructure which supports these practices.
These issues and more were discussed in groups over the day, and will continue to be discussed by the RSE community. If you’re a research software engineer, or just want to help champion their cause, you can visit the website and join the discussion group.
Dipping into Julian Orr’s Talking about Machines, an ethnography of Xerox photocopier technicians, has set off some light bulbs for me.
First, there’s Orr’s story: Orr dropped out of college and got drafted, then worked as a technician in the military before returning to school. He paid the bills doing technical repair work, and found it convenient to do his dissertation on those doing photocopy repair.
Orr’s story reminds me of my grandfather and great-uncle, both of whom were technicians–radio operators–during WWII. Their civilian careers were as carpenters, building houses.
My own dissertation research is motivated by my work background as an open source engineer, and my own desire to maintain and improve my technical chops. I’d like to learn to be a data scientist; I’m also studying data scientists at work.
Further fascinating was Orr’s discussion of the Xerox technician’s identity as technicians as opposed to customers:
The distinction between technician and customer is a critical division of this population, but for technicians at work, all nontechnicians are in some category of other, including the corporation that employs the technicians, which is seen as alien, distant, and only sometimes an ally.
It’s interesting to read about this distinction between technicians and others in the context of Xerox photocopiers when I’ve been so affected lately by the distinction between tech folk and others and data scientists and others. This distinction between those who do technical work and those who they serve is a deep historical one that transcends the contemporary and over-computed world.
I recall my earlier work experience. I was a decent engineer and engineering project manager. I was a horrible account manager. My customer service skills were abysmal, because I did not empathize with the client. The open source context contributes to this attitude, because it makes a different set of demands on its users than consumer technology does. One gets assistance with consumer grade technology by hiring a technician who treats you as a customer. You get assistance with open source technology by joining the community of practice as a technician. Commercial open source software, according to the Pentaho beekeeper model, is about providing, at cost, that customer support.
I’ve been thinking about customer service lately and reflecting on my failures at it a lot lately. It keeps coming up. Mary Gray’s piece, When Science, Customer Service, and Human Subjects Research Collide explicitly makes the connection between commercial data science at Facebook and customer service. The ugly dispute between Gratipay (formerly Gittip) and Shanley Kane was, I realized after the fact, a similar crisis between the expectations of customers/customer service people and the expectations of open source communities. When “free” (gratis) web services display a similar disregard for their users as open source communities do, it’s harder to justify in the same way that FOSS does. But there are similar tensions, perhaps. It’s hard for technicians to empathize with non-technicians about their technical problems, because their lived experience is so different.
It’s alarming how much is being hinged on the professional distinction between technical worker and non-technical worker. The intra-technology industry debates are thick with confusions along these lines. What about marketing people in the tech context? Sales? Are the “tech folks” responsible for distributional justice today? Are they in the throws of an ideology? I was reading a paper the other day suggesting that software engineers should be held ethically accountable for the implicit moral implications of their algorithms. Specifically the engineers; for some reason not the designers or product managers or corporate shareholders, who were not mentioned. An interesting proposal.
Meanwhile, at the D-Lab, where I work, I’m in the process of navigating my relationship between two teams, the Technical Team, and the Services Team. I have been on the Technical team in the past. Our work has been to stay on top of and assist people with data science software and infrastructure. Early on, we abolished regular meetings as a waste of time. Naturally, there was a suspicion expressed to me at one point that we were unaccountable and didn’t do as much work as others on the Services team, which dealt directly with the people-facing component of the lab–scheduling workshops, managing the undergraduate work-study staff. Sitting in on Services meetings for the first time this semester, I’ve been struck by how much work the other team does. By and large, it’s information work: calendering, scheduling, entering into spreadsheets, documenting processes in case of turnover, sending emails out, responding to emails. All important work.
This is exactly the work that information technicians want to automate away. If there is a way to reduce the amount of calendering and entering into spreadsheets, programmers will find a way. The whole purpose of computer science is to automate tasks that would otherwise be tedious.
Eric S. Raymond’s classic (2001) essay How to Become a Hacker characterizes the Hacker Attitude, in five points:
There is no better articulation of the “ideology” of “tech folks” than this, in my opinion, yet Raymond is not used much as a source for understanding the idiosyncracies of the technical industry today. Of course, not all “hackers” are well characterized by Raymond (I’m reminded of Coleman’s injunction to speak of “cultures of hacking”) and not all software engineers are hackers (I’m sure my sister, a software engineer, is not a hacker. For example, based on my conversations with her, it’s clear that she does not see all the unsolved problems with the world to be intrinsically fascinating. Rather, she finds problems that pertain to some human interest, like children’s education, to be most motivating. I have no doubt that she is a much better software engineer than I am–she has worked full time at it for many years and now works for a top tech company. As somebody closer to the Raymond Hacker ethic, I recognize that my own attitude is no substitute for that competence, and hold my sister’s abilities in very high esteem.)
As usual, I appear to have forgotten where I was going with this.
Today Jisc announced the beta G4HE website. The site pulls data from the BIS-funded RCUK Gateway to Research API and provides an interface to allow searching and visualising data on research in the UK.
For example, you can see at a glance the councils funding research at the University of Oxford, as well as the key collaboration partners in joint research work
There are several interesting “open” angles to this project.
First, its ‘open’ in the sense that the site is opening up access to information about research spending.
Second, the site is using crowdsourcing to clean up the available data to make it more meaningful – for example by asking visitors to help identify duplicates and naming mistakes from the original data.
Chuck Severance recently published a post entitled How to Achieve Vendor Lock-in with a Legit Open Source License – Affero GPL where he criticises the use of AGPL licenses, particularly its use – or at least, intended use – by Kuali. Chuck’s post is well worth reading – especially if you have an interest in the Kuali education ERP system. What I’m going to discuss here are some of the details and implications of AGPL, in particular where there are differences between my take on things and the views that Chuck expresses in his post.
Copyleft licenses such as GPL and AGPL are more restrictive than the so-called permissive licenses such as the Apache Software License and MIT-style licenses. The intent behind the additional restrictions is, from the point of view of the Free Software movement, to ensure the continuation of Free Software. The GPL license requires any modifications of code it covers to also be GPL if distributed.
With the advent of the web and cloud services, the nature of software distribution has changed; GPL software can – and is – used to run web services. However, using a web service is not considered distributing the software, and so companies and organisations using GPL-licensed code to run their site are not required to distribute any modified source code.
Today, most cloud services operate what might be described as the “secret source” model. This uses a combination of Open Source, Free Software and proprietary code to deliver services. Sometimes the service provider will contribute back to the software projects they make use of, as this helps improve the quality of the software and helps build a sustainable community – but they are under no obligation to do so unless they actually choose to distribute code rather than use it to run a service.
The AGPL license, on the other hand, treats deployment of websites and services as “distribution”, and compels anyone using the software to run a service to also distribute the modified source code.
AGPL has been used by projects such as Diaspora, StatusNet (the software originally behind Identi.ca – it now uses pump.io), the CKAN public data portal software developed by the Open Knowledge Foundation, and MIT’s EdX software.
[UPDATE 20 September 2014: EdX has since relicensed its AGPL component under the Apache License]
We’ve also discussed before on this blog the proposition – made quite forcefully by Eben Moglen – that the cloud needs more copyleft. Moglen has also spoken in defence of the AGPL as one of the means whereby Free Software works with cloud services.
So where is the problem?
The problem is that the restrictions of AGPL, like GPL before it, can give rise to bad business practice as well as good practice.
In a talk at Open World Forum in 2012, Bradley Kuhn, one of the original authors of AGPL, reflected that, at that time, some of the most popular uses of AGPL were effectively “shakedown practices” (in his words). In a similar manner to how GPL is sometimes used in a “bait and switch” business model, AGPL can be used to discourage use of code by competitors.
For example, as a service provider you can release the code to your service as AGPL, knowing that no-one else can run a competing service without sharing their modifications with you. In this way you can ensure that all services based on the code have effectively the same level of capabilities. This makes sense when thinking about the distributed social networking projects I mentioned earlier, as there is greater benefit in having a consistent distributed social network than having feature differentiation among hosts.
However, in many other applications, differentiation in services is a good thing for users. For an ERP system like Kuali, there is little likelihood of anyone adopting such a system without needing to make modifications – and releasing them back under AGPL. It would certainly be difficult for another SaaS provider to offer something that competes with Kuali using their software based on extra features, as any improvements they could make would automatically need to be shared back with Kuali anyway. They would need to compete on other areas, such as price or support options.
But back to Chuck’s post – what do we make of the arguments he makes against AGPL?
If we look back at the four principles of open source that I used to start this article, we quickly can see how AGPL3 has allowed clever commercial companies to subvert the goals of Open Source to their own ends:
- Access to the source of any given work – By encouraging companies to only open source a subset of their overall software, AGPL3 ensures that we will never see the source of the part (b) of their work and that we will only see the part (a) code until the company sells itself or goes public.
- Free Remix and Redistribution of Any Given Work – This is true unless the remixing includes enhancing the AGPL work with proprietary value-add. But the owner of the AGPL-licensed software is completely free to mix in proprietary goodness – but no other company is allowed to do so.
- End to Predatory Vendor Lock-In – Properly used, AGPL3 is the perfect tool to enable predatory vendor lock-in. Clueless consumers think they are purchasing an “open source” product with an exit strategy – but they are not.
- Higher Degree of Cooperation – AGPL3 ensures that the copyright holder has complete and total control of how a cooperative community builds around software that they hold the copyright to. Those that contribute improvements to AGPL3-licensed software line the pockets of commercial company that owns the copyright on the software.
On the first point, access to source code, I don’t think there is anything special about AGPL. Companies like Twitter and Facebook already use this model, opening some parts of their code as Open Source, while keeping other parts proprietary. Making the open parts AGPL makes a difference in that competitors also need to release source code, so I think overall this isn’t a valid point.
On the second point, mixing in other code, Chuck is making the point that the copyright owner has more rights than third parties, which is unarguably true. Its also true of other licenses too. I think its certainly the case that, for a service provider, AGPL offers some competitive advantage.
Chuck’s third point, that AGPL enables predatory lock-in, is an interesting one. There is nothing to prevent anyone from forking an AGPL project – it just has to remain AGPL. However, the copyright owner is the only party that is able to create proprietary extensions to the code without releasing them, which can be used to give an advantage.
However, this is a two-edged sword, as we’ve seen already with MySQL and MariaDB; Oracle adding proprietary components to MySQL is one of the practices that led to the MariaDB fork. Likewise, if Kuali uses its code ownership prerogative to add proprietary components to its SaaS offering, that may precipitate a fork. Such a fork would not have the ability to add improvements without distributing source code, but would instead have to differentiate itself in other ways – such as customer trust.
Finally, Chuck argues that AGPL discourages cooperation. I don’t think AGPL does this any more than GPL already does for Linux or desktop applications; what is new is extending that model to web services. However, it certainly does offer less freedom to its developer community than MIT or ASL – which is the point.
In the end customers do make choices between proprietary, Open Source, and Free Software, and companies have a range of business models they can operate when it comes to using and distributing code as part of their service offerings.
As Chuck writes:
It never bothers me when corporations try to make money – that is their purpose and I am glad they do it. But it bothers me when someone plays a shell game to suppress or eliminate an open source community. But frankly – even with that – corporations will and should take advantage of every trick in the book – and AGPL3 is the “new trick”.
As we’ve seen before, there are models that companies can use that take advantage of the characteristics of copyleft licenses and use them in a very non-open fashion.
There are also other routes to take in managing a project to ensure that this doesn’t happen; for example, adopting a meritocratic governance model and using open development practices mitigates the risk of the copyright owners acting against the interests of the user and developer community. However, as a private company there is nothing holding Kuali to operate in a way that respects Free Software principles other than the terms of the license itself – which of course as copyright owner it is free to change.
In summary, there is nothing inherently anti-open in the AGPL license itself, but combined with a closed governance model it can support business practices that are antithetical to what we would normally consider “open”.
Choosing the AGPL doesn’t automatically mean that Kuali is about to engage in bad business practices, but it does mean that the governance structure the company chooses needs to be scrutinised carefully.
The last three months or so I’ve been in school (which is why I haven’t been posting as much lately). Not a real bricks-and-mortar school—I’ve been participating in the “Data Science Specialization” series of online courses created by faculty at the Johns Hopkins Bloomberg School of Public Health and offered by Coursera, a startup in the online education space. It’s been an interesting experience, and well worth a blog post.
The obvious first question is, why I am doing this? Mainly because I thought it would be fun. I was an applied mathematics (and physics) major in college, enjoyed the courses I had in probability, statistics, stochastic processes, etc., and wanted to revisit what I had learned and (for the most part) forgotten. It’s one of my hobbies—a (bit) more active one than watching TV or reading. Also, I’ve done some minor fiddling about with statistics on the blog (for example, looking at Howard County election data), am thinking about doing some more in the future, and wanted to have a better grounding in how best to do this. Finally, “data scientist” is one of the most hyped job categories in the last few years, and even though I probably won’t have much occasion to use this stuff in my current job it certainly can’t hurt to learn new skills in anticipation of future jobs.
The next question is, why an online course? Because I didn’t have the time (or the money) to commit to attending an in-person class, but I wanted the structure that a formal class provides. I’ve been (re)learning linear algebra out of a textbook for over four years now, and I still haven’t gotten past chapter 3. Part of the reason is that I’m doing every exercise and blogging about it, but mainly it’s that I don’t have an actual deadline to finish my studies. In the Coursera series there are nine courses, each lasting a month, with quizzes every week and course projects every 2-4 weeks depending on the course. I’ve been doing pretty well in the courses thus far and don’t want to spoil my record. For example, the first project in the current class was due Sunday but I was concerned about missing the deadline and so finished it last Friday night.
I like the way the series of courses is structured as well, not just as a class in statistics (only) but covering the whole range of skills needed to wrangle with data in its various forms, not least including the problems of getting datasets and cleaning them up. Each class thus far has only been a month long, so the time commitment is not that great and I know any work I do today will pay off in a completed course not too far down the road. It is a fairly serious commitment of time though, especially since the course video lectures cover only a fraction of what you need to know in order to do the course projects and correctly answer the more difficult quiz questions. I’ve probably spent almost 10 hours each week working on various aspects of the classes, including doing a copious amount of Internet searching to find out the additional information I need. But it’s been time well-spent: I feel like I’m getting a good understanding of how to do “data science” tasks—not that I know everything, but I have a much better picture of what I need to know, and what it would take to finish learning it.
The course I’m currently taking (“Exploratory Data Analysis”), like the others in the series, is what’s been referred to as a MOOC, or “massive open online course”, open at no charge to anyone in the world who wants to participate over the Internet. The instructors provide video lectures and create the quizzes and class projects but are not otherwise directly involved; the students provide help to each other in online discussion forums, assisted by “community TAs”, i.e., former students who volunteer as teaching assistants. MOOCs have recently been the subject of both hype and caution; now that I’ve been involved in them day-to-day I can provide a personal perspective on the controversy.
First, I think MOOCs are good for the sort of people who invented them in the first place: Internet-savvy folks with a technological bent who are motivated to learn something and have the necessary free time and background experience and knowledge to do so effectively. I’ve certainly appreciated having convenient no-charge access to a wide variety of classes, many of which (like the courses I’m taking now) have been put together by people who are leaders and innovators within their fields. I’d even consider paying for at least some of these courses (at $49 each) in order to get a more formal “verified certificate” (as opposed to a “statement of accomplishment”, and may do so for later courses within this series—potentially good news for Coursera, which in the end is a profit-making enterprise.
However for people who are not Internet-savvy, not all that motivated, and don’t have the necessary background then MOOCs aren’t a good choice. In fact, they’re about the worse choice there is. The dropout rates in MOOCs are extremely high (well above 90% in many cases), and the first serious test of MOOCs as a replacement for in-person college courses (at San Jose State University) was not a raging success. Which is not to say that online learning in general is doomed; in its more traditional forms (for example, University of Maryland University College) it’s doing quite fine.
MOOCs are simply the latest in a long line of attempts to move away from the traditional classroom model and “disrupt” the existing educational establishment. They’ll eventually find a place in the overall educational picture, most likely serving a variety of needs from “learning as hobby” (what I’m doing), high-end vocational education (what Coursera competitor Udacity seems to be morphing into), or as a supplement to traditional classes. But that’s for the future, and no real concern of mine; in the meantime I’m just trying to learn how to plot in R.
Summer is over, and it’s time to really get to work on my Sabbatical project.
I did do some work this summer – I’ve read 3 of the books on my Sabbatical Reading List (and added a few more to the list) and I’ve finally de-lurked on the OpenMRS developer mailing list and in some of the online meetings, and I’ve made a decision to convert all of my course materials to Markdown (the better to track changes on GitHub – see a future post). But, it’s all been pretty passive.
So, the Friday before the Labor Day Weekend, I decided it was time to get back to the “develop code in OpenMRS” part of the project.
Since it had been a couple of months since I had set up my development environment and tried to build the OpenMRS code, I decided that starting over from scratch (mostly) would not be a bad idea. Here is what I did:
cd openmrs-core maven clean install
cd webapp mvn jetty:run
Now that I have a working environment that builds and runs, the next step is to choose a ticket to work on.
As we’ve mentioned before, OSS Watch is involved in the VALS Semester of Code project, enabling university students to participate in open source projects as part of their degree course. There’s a week left for FOSS projects to sign up and submit their mentored projects for the pilot, before the students can sign up and submit their proposals. As reported on the Semester of Code website, there’s been a fantastic response so far:
Organisations that Semester of Code students will have the opportunity to work with include the NASA Jet Propulsion Laboratory, Moodle, OpenMandriva and Lime Survey. The project ideas submitted so far cover topics such as audio processing, HTML parsing, API design, web development and many more.
You can read the full announcement on the Semster of Code site.
I’m going to gradually share my dissertation proposal here as I migrate it to github and into LaTeX – I’d love reactions, comments, questions, etc! The title is “a poststructural perspective on engineering and technology faculty as learners,” which will hopefully make sense after the first 2 paragraphs.
Faculty are learners, too.
We often think of engineering and technology faculty as teachers. As facilitators of student learning, they hold certain philosophies about teaching and learning that shape their interactions in the classroom. However, faculty are also learners themselves, students of the practice of “teaching engineering and technology.” As engineering education researchers concerned with research-to-practice transfer, the ways we think about faculty-as-learners likewise shape the ways we try to impact their practice. Making this thinking more visible within the engineering/technology domain is of interest to engineering and technology faculty members, faculty development professionals, and adult learning researchers.
My dissertation draws on the traditions of cognitive apprenticeship and narrative within engineering education research to explore poststructuralism as one possible perspective on faculty-as-learners. Poststructuralism is a paradigm that constantly seeks a “making-strange” and unsettling of habitual narratives. A poststructural view challenges us to remain in the discomfort of liminal (in-between) spaces where everything is constantly troubled and nothing ever really settles. This study demonstrates a concrete method for engaging faculty members in that liminal space. Through it, I anticipate contributing to our ability to articulate and value faculty explorations in chaotic territories such as large-scale curriculum redesigns, new program formation, and other places where valuable growth occurs but is rarely put into words.
How can we think of faculty as learners?
I will briefly describe several qualities of faculty-as-learners, compare and contrast them to the qualities presented in existing literature, and explore why it may be valuable to make these qualities visible. Note that by comparing and contrasting my approach to other studies, I am not making statements about the relative quality or validity of their work. I am also not saying that these ways of viewing faculty-as-learners are not present in any existing literature. I am simply using differences and similarities to more clearly articulate certain assumptions about faculty-as-learners that are present in this project.
They are situated in the community of practice of teaching their discipline.
The first quality of faculty-as-learners is that they are situated in a community of practice (Wenger, 1999), that of teaching their discipline. By making sense of the activities of other practitioners around them, they develop the skill of reflection-in-action (Scho¨n, 1983) and use this metacognition and self-monitoring to improve their own practice. Existing engineering education change initiatives have used this cognitive apprenticeship (Collins, Brown, & Newman, 1987; Collins, Brown, & Holum, 1991) approach to build Faculty Learning Communities (Cox, 2004) and other communities of practice to encourage rigorous research in engineering education (Streveler, Smith, & Miller, 2005). Understanding faculty as situated and communal learners helps explain the limited success of an “information dissemination” approach (Siddiqui and Adams, 2013) to research-to-practice transfer. If faculty change their teaching practice primarily in response to direct interactions with colleagues (Fincher, Richards, Finlay, Sharp, & Falconer, 2012) and not print materials, it’s no surprise that journal papers continue to go unread (Borrego, Froyd, & Hall, 2010).
They are adult learners.
The second quality of faculty-as-learners is that they are adult learners. They have rich histories of experience to draw upon as well as expectations of agency (Vella, 1997). This quality allows us to portray faculty as narrators, highly capable and interdependent agents who both read and co-author the stories of “how things are done” within their culture. The Disciplinary Commons initiative (Tenenberg & Fincher, 2007), which scaffolds faculty through a dialogic process of creating teaching portfolios for their existing courses, is an exemplar of validating faculty as adult learners. Initiatives that treat faculty as mere empty “buckets” to be filled with “information about teaching,” such as information sessions dedicated to lecturing faculty about why they should not lecture, may have a limited impact because of this epistemological disjoint.
They learn by engaging in liminal experiences.
The third quality of faculty-as-learners is that they often learn by engaging in liminal experiences where their activities do not fall into a cleanly articulable structure, and can therefore be described as poststructural. In fact, the liminal experiences of faculty are often explicitly about dismantling old structures and remaking new ones, such as the founding of a new college (S. Kerns, Miller, & D. Kerns, 2005) or degree program (Katehi et. al., 2004), dramatic overhauls of an existing curriculum (Mentkowski, 2000), or the creation of experimental classes.
The trouble with liminal experiences is that they stand outside the realm of structure, including the structure of validation and reward. Our existing academic system rewards faculty for engaging in liminal spaces for their research, so long as they are able to publish papers about it afterwards. However, the examples listed all impact teaching, a form of scholarship that is underdeveloped and unrecognized (Shulman, 1998), with a correspondingly slow speed of change. Mann’s (1918) calls for engineering educators to improve student retention, make undergraduate workloads reasonable, and increase hands-on training still sound as relevant today as when he wrote his report nearly a century ago. Our calls for transforming engineering education (National Academy of Engineering, 2005; Institute of Medicine, National Academy of Sciences, & National Academy of Engineering, 2007; McKenna, 2011) will similarly go unheeded unless we find ways to understand and articulate the ways faculty learn and work in these liminal spaces.
By having engineering and technology faculty work with their stories of liminal experiences, this study addresses the following research question: How can the interacting narratives of engineering and technology faculty inform our understanding of faculty as learners?
For quite some time now at OSS Watch we’ve struggled with the model of “Community Source” promoted by some projects within the Higher Education sector. Originating with Sakai, and then continuing with Kuali, the term always seemed confusing, given that it simply meant a consortium-governed project that released code under an open-source license.
As a governance model, a consortium differs from both a meritocracy (as practised by the Apache Software Foundation) or a benevolent dictatorship, or a single-company driven model. It prioritises agreement amongst managers rather than developers, for example.
We produced several resources (Community Source vs. Open Source and The Community Source Development Model) to try to disambiguate both the term and the practices that go along with it, although these were never particularly popular, especially with some of the people involved in the projects themselves. If anything I believe we erred on the side of being too generous.
However, all this is about to become, well, academic. Sakai merged with JaSig to form the Apereo Foundation, which is taking a more meritocratic route, and the most high-profile project using the Community Source model – the education ERP project Kuali – has announced a move to a company-based governance model instead.
I think my colleague Wilbert Kraan summed up Community Source quite nicely in a tweet:
‘Community source’ probably reassured nervous suits when OSS was new to HE, but may not have had much purpose since
Michael Feldstein also provides a more in-depth analysis in his post Community Source Is Dead.
There’s good coverage elsewhere of the Kuali decision, so I won’t reiterate it here:
A few months ago we had a conversation with Jisc about its prospect to alumnus challenge, where the topic of Kuali came up. Back then we were concerned that its governance model made it difficult to assess the degree of influence that UK institutions or Jisc might exercise without making a significant financial contribution (rather than, as in a meritocracy, making a commitment to use and develop the software).
Its hard to say right now whether the move to a for-profit will make things easier or more difficult – as Michael points out in his post,
Shifting the main stakeholders in the project from consortium partners to company investors and board members does not require a change in … mindset
We’ll have to see how the changes pan out in Kuali. But for now we can at least stop talking about Community Source. I never liked the term anyway.
I’m taking my last (required) engineering course as a student this semester. It’s a course on visualization based taught by David Ebert and Abish Malik. Basically, I’ll get credit for using my computer to make pretty pictures based on giant datasets. Shiny! It’s also my first-ever engineering course with an interpreter (Laurie), and I’m sucking up new technical ASL vocabulary like a sponge; this semester is unexpectedly full of opportunities to practice my signing. Double-shiny.
I’ve got to start thinking of a term project, and so far I have a few main ideas — but others are welcome, along with brainstorms on how to flesh them out. If I can get a firm idea before Sep 30, I can prototype an entry for the NSF visualization challenge. Project requirements are here, and my ideas so far are:
A dashboard for Hacker Schoolers which would track metrics of interest based on what people consider relevant to their “becoming a better programmer.” Particularly interesting, I think, might be a visualization for Hacker School facilitators – what ways can we use already public data to give them an overview of what many people are doing at once, with the ability to zoom in, compare, etc. as they want? However, I don’t have a clear vision as to what this might look like, so feature ideas/requests are welcome.
Visual ways to navigate intertwined narrative text for my dissertation, which involves people telling stories in response to other people’s stories (and then the original storytellers tell new stories in response to those responses… so they’re intricately tangled up).
Complex symphonic music as experienced with hearing loss, hearing aids, and cochlear implants. My interest in this area is pretty obvious, but this now seems like the most boring project of the three — I could be wrong, though!
Help me brainstorm, intarbrainz!
In other news: today’s class was mainly adminstrivia and an overview of visualization, which is one of many ways to (literally) “make things visible” — converting numerical, abstract data into a graphical representation. For visual learners (like myself), this is effectively translating into our native mental file format. For practically everyone, visualization frees up much of the cognition involved in processing massive amounts of numerical data, allowing us to use higher-level brain functions to ask and analyze interesting questions (I’d heard this before), and making us more confident in our decisions (I hadn’t heard this before). Some fun viz examples include Chris Harrison’s visualization of Biblical cross-references and a map of the US colored by distance to the nearest McDonald’s.
And with that, I’m off to my next meeting. It’s amazing how much more energetic and happy and just plain kind I am when I don’t pretend I’m hearing — telling people I’m deaf, having accessibility in my classes… even my brother noticed it (“You’re less grumpy with your hearing aids,” said Jason in the minivan last month).
This is the first in a series of blog posts based on my Hacker School workshop series, “Learning Styles For Programmers,” which is in turn a software-focused adaptation of Rich Felder’s work on engineering learning styles. (As you read, it will become obvious this post started as a transcript of a workshop.)
Learning styles are like personality tests… for education. There are a few different spectrums — active/reflective, sensing/intuitive, visual/verbal, global/sequential — that are helpful for understanding how you operate as a programmer, both in a learning and a teaching role (we tend to teach the way we like to learn). We’ll go through them one at a time, starting with active/reflective.
(Note: if you are a global learner — that is to say, you like seeing the “big picture” first — you may benefit from reading this short blog post on learning styles first to get an overview before diving into the entire series.)
Spectrum #1: Active vs. Reflective
Every mature learner acts, and every good learner reflects… just not in the same order. “Active vs reflective” styles refers to which one you do first: active learners act, then reflect. Reflective learners reflect, then act. An active learner will frequently say things like, “How are you going to know unless we just try it and start messing around?” or “Just start typing. We don’t need to read any more, just go!” Active people tend to jump in, and then they reflect after they act. They do things, and then they look up and they go, “What the heck have I just done? What did I learn? I need to process this.” And then they process; the processing comes later.
A reflective learner, on the other hand, processes first. They are more likely to say, “Okay, hang on. Before we start this, let’s make sure that we have the pseudocode written. Have we read the language specification? And three textbooks? And maybe we should go talk with an expert, and…” (laughter from the room)
Ok, maybe that’s an extreme example. But reflective learners are at their best after they’ve had some processing time. That is one of the reasons I scheduled my Learning Styles workshop in the afternoon, after I gave a morning talk that briefly introduced the idea of learning styles (along with lots of other ideas).I wanted to give reflective learners a 2-hour break after my first presentation so they could digest the material before they came here. Reflective people don’t usually have questions right on the spot, but if I give them time to think about it, they come back with wonderfully thoughtful questions.
Reflective example: Stacey
A good example of a reflective learner is Stacey Sern, who is a Hacker School alumna. I talked with Stacey on a Monday once — early on Monday, talking about working together on a presentation. We chatted a little while, and then she said “Okay, that sounds great. I can think about that. Tomorrow.”
It wasn’t because Stacey was booked that day. Hacker Schoolers have extremely open schedules. But Stacey will need — honestly need — 24 hours to prepare herself to pair with you. It’s not a question of skills or confidence, because she has both; she just knows that she needs that time to get her mind in the right place. And once she shows up, she is so prepared. She has thought about the problem, scoped it out. But before that time, she will not be ready to pair.
Without knowing about active/reflective learners, it’s easy to stereotype Stacey as being a little slow, when in fact you would be missing out — she is a brilliant programmer. The code that she starts writing after 24 hours of pondering is clear, it’s crisp, elegant, it has lovely architecture, it’s way better than the stuff I start banging out on my keyboard immediately, because I’m an active learner, and so that’s what I naturally do.
Active example: Tom
Hacker School facilitator Tom Ballinger is also an active learner; show him some code, and he’ll immediately start pointing at it and thinking out loud. A lot of you (at Hacker School) have probably experienced Tom’s Instantaneous Code Reviews. Pretty incredible. But that also comes with the dynamic of “I have an idea, whee! Let’s try this path! Uh, okay, that didn’t work. Let’s try that one! Ok, that didn’t work. How about…” Tom shows you everything he’s thinking, including the dead-ends he’s running into, as he runs into them. In contrast, by the time Stacey gets to you, she’s already pruned the dead ends and figured out most of a pathway that will probably work.
Audience question: I can’t fit myself perfectly into this model. I do both active and reflective things. What am I?
That is a great point to bring up. These aren’t binaries, they’re spectrums. You can be 100% active, 100% reflective, and anywhere in between. So you could just be in between.
Also, this “learning styles” stuff is a framework — like all frameworks, it is not a perfect model of reality. (The only perfect model of reality is reality itself.) Rather, it is a tool that you can use for introspection. Do what’s helpful to you.
Audience question: But sometimes I act really active, and sometimes I act really reflective. Is that possible?
It is absolutely possible. If it’s helpful for you to understand yourself as switching back and forth between active/reflective — for instance noticing that you present as more active when you’re coding in language A and reflective in language B — then that’s what helpful to you.
Programming culture favors active learners
What might be happening — my guess, in fact — is that you are on one side of the spectrum, but you’ve learned to function on the other side. Our culture usually favors one side of a spectrum over the other. In the case of mainstream coding culture, the favored side is active learning. Think about programming interviews, where you’re given coding problems and asked to solve them on the spot. That’s incredibly biased towards active learners.
You can pretend to be a style you’re not, but it takes more energy
This means that many reflective programmers — especially the smart, successful ones — have forced themselves to act as if they’re active learners. It’s kind of like how introverts can pretend to be extroverted at parties — and then they go home and completely crash, because they’re drained. And active learners can learn how to act reflective — for instance, when they’re in school and get in trouble for not following instructions, or checking their work, or otherwise making careless mistakes because they skip things in their excitement.
Either way, it takes a lot more energy to operate outside your “native file format,” so to speak. But sometimes there are good reasons to do it. I personally find it helpful to acknowledge that it does take more effort to act like what you’re not, because then it’s a conscious choice you know the cost of, and you don’t end up feeling guilty that something easy for other people — raising your hand and speaking on the spot, for instance — seems so much harder for you.
Sometimes deliberately working outside your style is a useful learning experience
As a learning exercise, you can deliberately try working in a style that’s not your normal style. Again, it’ll take more energy — we all have our preferred modes — but sometimes you’ll learn something new.
For instance, Stacey, the reflective learner I mentioned earlier, found it valuable to pair with people who were very, very active, because she wanted to stretch herself towards more active ways of being. She knew that it would be hard, and that she would not be at her best. And maybe what she learns from that experience is that being more active is difficult, but useful. Or maybe what she learns is that trying to act more active makes her so frustrated that she just doesn’t learn anything, and she had better stick with being reflective. But then she knows something new about herself, and she can choose what she wants to do in the future.
It’s like… I learned the hard way that I’m unhappy when I code in assembly. I can do it, but it makes me a very sad Mel. So now I program exclusively in higher-level languages. Nothing below C or C++, unless I have a really, really good reason to do it. Before, in college, I thought, “There’s something wrong with me. I can’t code in assembly.” So I forced myself, masochistically, to code primarily in assembly for an entire semester and the summer after that, because I thought I should be able to, because I’m an electrical engineer. And I was miserable! (laughter) Now I think “I can program in assembly, but I’m happier when I don’t, and there is nothing wrong with choosing to be happy.”
That’s the point of all these learning styles things, for me. Learning about who you are, what your ideal environment is, how you’re happiest working, so you can find and choose that happiness.
Spanning the spectrum: what does that feel like when you pair?
When I talk about learning styles, I often ask workshop participants to plot themselves across the active/reflective spectrum. Every Hacker School batch I’ve asked to do this has ended up with somebody at every single possible point on the spectrum. This means that at some point during your learning experiences, you’ll probably pair with someone more active than you, and you’ll probably pair with someone more reflective than you.
In fact, I would encourage that. It feels very different to pair with someone who is on one side of you versus the other. Try pairing with someone that is on either side of you to see what that feels like and what kind of dynamic that creates. What’s it like to be the more active one? The more reflective one? See whether you like it, and whether that might be a dynamic that you might look to have — or avoid — in your future programming life.
Pairing active with reflective learners can be a blessing or a curse. If you have an active person and a reflective person pairing, they can either balance each other out — the active person’s diving in and trying out code, while the reflective person keeps an eye out for longer-term, big-picture things — or they can clash horribly. Active people can seem reckless and careless to reflective people, and reflective people can seem slow and resistant to change through an active person’s eyes.
I fall into that trap too. When I paired with Stacey, and she said, “I need time, I need until tomorrow to think,” my instinctive active-learner reaction was “but, but… we could work on it, together, RIGHT NOW!” I had to catch myself and go “wait, she’s reflective… and if I can wait a day, she’ll have this beautiful thing that I can then be super-enthusiastic and active-learnery about with her, instead of trying to drag her along with my half-baked ideas now.” And that’s what we did, and it was great — it was the first Test Driven Learning workshop.
Audience question: I understand the descriptions, but I’m still struggling to identify myself. Is there a test for whether you’re an active or reflective person?
There isn’t a perfect test, but here’s one: take two minutes in silence, right now, to think about a learning experience you’ve had, that helps you form a hypothesis for where on the active/reflective spectrum you are.
(No, really. Do it. Set a timer. In the live workshop, I paused everything and had everyone sit and think for two minutes while I watched a clock.)
(Are you back now? Good.)
Now: this isn’t an absolute test, but the 2-minute wait tends to be a pretty decent litmus test for active/reflective learners. If you felt very, very uncomfortable with this — bored, even — you are probably an active learner. After the first couple of seconds, active learners generally start shifting around, thinking, “Ah, okay. When can we start again? Can I ask you a question?” (In fact, one active learner stood up 30 seconds into the “silent time” and quietly started whispering questions to me. I had to try very hard to keep from laughing.)
Reflective learners, on the other hand, started to smile these blissful smiles. They physically relax. They exhale. Afterwards, they go “Oh, thank you. Thank you! You have stopped for a moment. I can process.” And it’s the reflective learners at my workshops who are always stunned — “wait, other people feel this way?” Because, like I said, our programming culture favors active learners… so we have all these reflective learners pretending to be active, walking around exhausted all the time, thinking they’re the only one and that something is wrong with them.
Audience question: are reflective people better at planning?
That is a pretty common way for it to manifest, but “active” and “bad at planning” are not quite the same thing — although I’m both active and ADHD, so that’s how it sometimes shows up for me! (laughter) Reflective does not mean the same thing as organized. I have meet reflective people who are not organized, as well as active people who are very organized.
However, active and reflective people do look different when they plan and organize. Active people will prepare to improvise — they’ll fill their pockets with the tools they need to parachute in and be reactive — whereas reflective people will tend to plan in the sense of thinking everything through before they do it.
Blogging at the end of a day, for instance, tends to work better for active people. Reflective people, if they blog, will blog at the beginning of the day to think about how they’re going to set it up. So they think about it and then they do it, and then they don’t have to really reflect on it anymore, because they did that beforehand. They know what they did because they’ve set that up, and they’re done, and they walk out the door and they go home.
Audience question: “Do time constraints make you behave more like an active learner?”
Great question. Time constraints can really bring some clarity to the situation and make both kinds of folks feel more stressed, but reflective people will get especially stressed out. They are not at their best when they’re asked to slam up things on whiteboards and type out code right on the spot in front of the interviewer, and they can feel that. It’s painful.
Dealing with active/reflective styles during a job interview
Now, if you’re an active learner and that’s your strength, then awesome. Play to it when you go interview. If you know you are reflective and that’s not how you’re going to function well, think about what you can do. Reflective people often have lovely products, portfolios, and polished deliverables. Think about ways that you can use those strengths to your advantage. How can you steer the conversation so it goes toward the portfolio you prepared? Can you talk with your interviewer and say, “Hey, this is the kind of programmer I am. This is the sort of environment that I excel in. You’re not seeing my best work in a rapid fire algorithm generation task, but let me show you what I can really do.”
That sort of insight is actually attractive and valuable, because it’s rare to see that in folks you’re trying to hire. If you think about it, your manager’s job is to figure out how to make you the most effective programmer you can be. If you tell them how you can be most effective, then you’ve done a lot of the job for them. If you know some the stuff about yourself and the implications that that has for your optimal work environment, tell them. It’s rare and impressive, especially for more entry-level programmers, to have that type of insight.
Learning strategies for active and reflective learners
Let’s talk for a moment about things that active learners and reflective learners can do. If you’re an active learner and you’re forced to sit through a lecture, you’re probably going to get really bored. So recognize that and give yourself permission to take really weird notes or mess around on your computer or to otherwise do something while you’re listening.
Similarly, reflective folks. If you need more processing time, you need more processing time, and you should take it. Be okay with not asking questions right at the end of a lecture or talk. Maybe have a strategy of asking for the speaker’s contact information: “That was a great talk, and I think my brain needs a little time to process it, because there were so many good ideas! May I email you with notes and questions once I write them up?” Also, tell your teammates! You can ask your teammates to pause and say, “Can we stop and think about this, take a coffee break, and come back in 15 minutes?” You’ll make other people function better because you’re forcing some of them to take breaks they don’t realize they need.
If you want more, Rich Felder has a funny case study and more tips for active and reflective learners, and my earlier blog post on learning styles had programming-specific tips.
Ironically, Rich’s says that it’s the reflective learners who have an advantage, because he’s a professor writing from within the context of school — where we are expected to sit still and think! So I think we have an interesting dynamic here in the programming world, because there are so many talented programmers who are very active. They did not do well in school because it was such a reflective-biased environment… so what do they do? While their reflective classmates got A’s and became CS professors, some of these active people dropped out of school and created a work environment that swings in exactly the opposite direction, and voila, we have an active-biased non-school programming culture. That’s a gross oversimplification, of course. But it’s interesting to think about it that way.
Teaching strategies for active and reflective learners
As I mentioned earlier, we tend to teach the way that we ourselves prefer to learn. The corollary to this is that we often find it easier to teach people with similar styles, and we tend to to be… less good, shall we say — at teaching people with styles different than our own, unless we pay attention to adapting to them.
I myself am an active learner. Hacker Schooler Bert Muthalaly is also an active learner, and during the workshop I called on him, unprepared, to give some anecdotes about his Hacker School experience. Active learners (if they’re not shy) tend to do better at this than reflective learners — improvisational audience participation keeps them on their toes. Active learners tend to be a lot more comfortable and good at saying things on the spot, asking questions right away.
As a teacher, my probes of active learners are designed to get them started. Sumana Harihareswara (also a Hacker School alumna) knows I’m super-active, so she will nudge me — “hey Mel, how’s the Hacker School book project going?” and BOOM! That’s the best way to get me working on that book again.
As a teacher, I also need to make sure my reflective students are learning. I would never, ever put a reflective person like Stacey on the spot like that. Instead, my probes of reflective learners are designed to encourage them to ship and share what they already have. “Hey, that’s a wonderful blog post. Could you summarize that in the middle of my talk tonight?” I also build thinking times into what I do, and make space for my reflective students to reflect. For instance, the 2-minute “think silently about a learning experience” litmus test from earlier in this post was an attempt to make some thinking time for reflective learners in the live workshop.
I’ll also frequently pose questions in my talks, then prompt people to think about them silently for 1-2 minutes. This is helpful for reflective learners, and awkward for speakers because it means you’re standing in front of everyone twiddling your thumbs for 120 seconds. But your audience is thinking, and they can’t think unless you shut up!
Sometimes I’ll do that silent thinking prompt for the reflective learners, then ask everyone to turn to their neighbor and share answers — that one’s for the active learners. And then sometimes I’ll ask if any pairs want to volunteer their answers for the whole group. This is a teaching technique called think-pair-share, and it’s a technique a lot of teachers learn, because when we’ve done education research, we’ve found that combination is effective. There’s something for everyone.
Another way I tried to get both styles into my workshop was the way I asked people to indicate where they were in the spectrum — there was a period of 5-10 minutes where I was not talking, because people were filing up and putting a sticker with their name on the wall to show where they were on the spectrum. The active people got to do something: write on a sticker, gather happily around the wall, help others put their stuff up, debate whether someone ought to be here or there — and the reflective people plopped their stickers on the wall and sat and pondered. Micro-breaks are good.
Pairing with active and reflective learners
This also applies to one-on-one things like pair programming, when you may not formally be teaching someone, but are mentoring or otherwise working with them. Give reflective learners the material to process beforehand — let them read your code in advance. If you’re reviewing their code, write notes on their code first, and send them those notes before you sit down to discuss it. Give them a list of questions to consider before you meet. Build in breaks and breathing spaces into your work time. Let them stop, go off by themselves, and read a book about your project until they’re ready to come back. And reflective learners, educate your partner to recognize and honor that you need these things.
In a way, it’s similar to extroverts learning to work with introverts. Your introverted friends love you, extroverts! They just need to recharge so they can be near you! Well… your reflective colleagues love you, active people! You just change direction so fast sometimes that they lose track of where you’re going, and how they can accompany you!
And when you’re working with active learners — let them run around! Give them things to respond to. Spit out answers fast, think out loud — they’ll often prefer something immediate and half-baked to something slow and totally baked, because they may not like the totally-baked thing you finish up, whereas if it’s half-baked they can jump in and help you shape it. It’s like the open source mantra of “release early and often.” Don’t worry about going down dead ends; they want to wander through that maze with you!
That was active/reflective. We’re going to go through the other learning styles a bit more swiftly. I’m taking more time to unpack this first spectrum so you get the idea of how to play with these ideas. The next post in this series will be about sensing/intuitive programmers.
This blog post series would not exist without the persuasion and gracious editing of Hacker Schooler (S’14) Maia McCormick, who convinced me to do better than “let’s just dump transcripts on the intarwebz!” Thanks, Maia — and everyone at Hacker School who exhorted me for the past year to record this talk! Further edits/questions/suggestions are very, very welcome; comment away!
This is a guest post from Hunter from Project Yamina, one of the student-led projects that won a place in the Jisc Student Innovation programme. Here at OSS Watch we’re supporting the programme over the summer and advising students on their projects.
Hi, my name is Hunter and I’m responsible for a new website called “Project Yamina”. This summer, I’m part of the JISC Student of Summer Innovation. JISC wanted new ideas – from students – that would show how technology can improve students’ life. Their hope is, with the assistance of funding, the twenty successful projects will create something worthwhile by November.
Project Yamina started as a first year university design project. Based on the workplace, we had to come up with something that would change the work environment for the better. Looking at research, I saw there was a large volume of careers that people viewed as being more suited for men; jobs that people imagined few women worked in. For example Free Software and Open Source communities - women are very under-represented. I thought that this was crazy, and came up with the idea of changing the workplace – and these attitudes – by finding a way to encourage more girls to enter some of these jobs.
The idea of Project Yamina is for it to be an online magazine. Something full of interesting profiles (on both women and careers), personal essays, helpful facts and tips, alongside news items. Then, I hope girls will look at the site, and discover a woman who is a (for example) scientist, coder, police officer or sniper. Perhaps she’ll think it sounds interesting, and it’s a career she would like to do too.
I’m looking for people to be featured as profiles – this means answering a handful of questions for me, or writing a short essay on any topic to do with your work and experiences. Don’t worry, it doesn’t have to be anything too formal – I want the website to be fun for everyone involved. Of course, you’re welcome to write an essay and be a profile too! I’m extremely keen to have people from all backgrounds involved, especially those who would like to talk about how they overcame adversity, even if you’d like to stay anonymous.
I can be contacted at: http://projectyamina.strikingly.com/#become-involved
As we’ve mentioned before, OSS Watch is working as part of the VALS Project to run a Semester of Code, engaging students with FOSS projects as part of their studies. This week, our Virtual Placement System went live, allowing projects to register and submit ideas for student projects.
Firstly, a member of your organisation to sign up as an Organisation Administrator and register your organisation;
You will now see your organisation’s details with 2 codes: One to allow your mentors to sign up, and one to allow additional administrators for your organisation to sign up.
Once registered, you and your mentors can submit ideas;
The project should take about 3 months to complete. Please bear in mind that it’s better to start with a smaller project that can be extended if your student proves to be capable rather than have an over-ambitious idea which can’t be completed in time.
If you have any questions or feedback about the Virtual Placement System or the Semester of Code programme, please get in touch on the mailing list.
We want millions of people learning about the web everyday with Mozilla. The ‘why’ is simple: web literacy is quickly becoming just as important as reading, writing and math. By 2024, there will be more than 5 billion people on the web. And, by then, the web will shape our everyday lives even more than it does today. Understanding how it works, how to build it and how to make it your own will be essential for nearly everyone.
The tougher question is ‘how’ — how do we teach the web with both the depth *and* scale that’s needed? Most people who tackle a big learning challenge pick one path of the other. For example, the educators in our Hive Learning Networks are focused on depth of learning. Everything the do is high touch, hands-on and focused on innovating so learning happens in a deep way. On the flip side, MOOCs have quickly shown what scale looks like, but they almost universally have high drop out rates and limited learning impact for all but the most motivated learners. We rarely see depth and scale go together. Yet, as the web grows, we need both. Urgently.
I’m actually quite hopeful. I’m hopeful because the Mozilla community is deeply focused on tackling this challenge head on, with people rolling up their sleeves to help people learn by making and organizing themselves in new ways that could massively grow the number of people teaching the web. We’re seeing the seeds of both depth and scale emerge.
This snapped into focus for me at MozFest East Africa in Kampala a few days ago. Borrowing from the MozFest London model, the event showcased a variety of open tech efforts by Mozilla and others: FirefoxOS app development; open data tools from a local org called Mountabatten; Mozilla localization; Firefox Desktop engineering; the work of the Ugandan National Information Technology Agency. It also included a huge Maker Party, with 200 young Ugandans showing up to learn and hack with Webmaker tools.
The Maker Party itself was impressive — pulled off well despite rain and limited connectivity. But what was more impressive was seeing how the Mozilla community is stepping up to plant the seeds of teaching the web at depth and scale, which I’d call out as:
Mentors: IMHO, a key to depth is humans connecting face to face to learn. We’ve set up a Webmaker Mentors program in the last year to encourage this kind of learning. The question has been: will people step up to do this kind of teaching and mentoring, and do it well? MozFest EA was promising start: 30 motivated mentors showed up prepared, enthusiastic and ready to help the 200 young people at the event learn the web.
Curriculum: one of the hard parts of scaling a volunteer-based mentor program is getting people to focus their teaching on the most important web literacy skills. We released a new collection of open source web literacy curriculum over the past couple of months designed to solve this problem. We weren’t sure how things would work out, I’d say MozFestEA is early evidence that curriculum can do a good job of helping people quickly understand what and how to teach. Here, each of the mentors was confidently and articulately teaching a piece of the web literacy framework using Webmaker tools.
Making as learning: another challenge is getting people to teach / learn deeply based on written curriculum. Mozilla focuses on ‘making by learning’ as a way past this — putting hands-on, project based learning at the heart of most of our Webmaker teaching kits. For example, the basic remix teaching kit gets learners quickly hacking and personalizing their favourite big brand web site, which almost always gets people excited and curious. More importantly: this ‘making as learning’ approach lets mentors adapt the experience to a learner’s interests and local context in real time. It was exciting to see the Ugandan mentors having students work on web pages focused on local school tasks and local music stars, which worked well in making the standard teaching kits come to life.
Clubs: mentors + curriculum + making can likely get us to our 2014 goal of 10,000 people around the world teaching web literacy with Mozilla. But the bigger question is how do we keep the depth while scaling to a much bigger level? One answer is to create more ’nodes’ in the Webmaker network and get them teaching all year round. At MozFest EA, there was a session on Webmaker Clubs — after school web literacy clubs run by students and teachers. This is an idea that floated up from the Mozilla community in Uganda and Canada. In Uganda, the clubs are starting to form. For me, this is exciting. Right now we have 30 contributors working on Webmaker in Uganda. If we opened up clubs in schools, we could imagine 100s or even 1000s. I think clubs like this is a key next step towards scale.
Community leadership: the thing that most impressed me at MozFestEA was the leadership from the community. San Emmanuel James and Lawrence Kisuuki have grown the Mozilla community in Uganda in a major way over the last couple of years. More importantly, they have invested in building more community leaders. As one example, they organized a Webmaker train the trainer event a few weeks before MozFestEA. The result was what I described above: confident mentors showing up ready to teach, including people other than San and Lawrence taking leadership within the Maker Party side of the event. I was impressed.This is key to both depth and scale: building more and better Mozilla community leaders around the world.
Of course, MozFestEA was just one event for one weekend. But, as I said, it gave me hope: it made be feel that the Mozilla community is taking the core building blocks of Webmaker shaping them into something that could have a big impact.
With Maker Party kicking off this week, I suspect we’ll see more of this in coming months. We’ll see more people rolling up their sleeves to help people learn by making. And more people organizing themselves in new ways that could massively grow the number of people teaching the web. If we can make happen this summer, much bigger things lay on the path ahead.
Since Black Duck bought the site back in 2010 there haven’t been any obvious changes.
Until now that is:
Dear Ohloh user,
Since 2010, we have supported the Ohloh community, now consisting of over 250,000 users, with a stream of new features and functions – all to remain freely available. The name change to Black Duck Open Hub reflects an increasing commitment on our part to the developer community, as well as anyone who wants to learn about the world of open source.
So, goodbye Ohloh, hello Black Duck Open Hub!
I have to admit it doesn’t exactly roll off the tongue that easily, and I’m not looking forward to correcting all the mentions of it in various OSS Watch publications either, but hey, things move on!
Do you remember how hard digital photography used to be? I do. When my first son was born, I was still shooting film, scanning things in and manually creating web pages to show off a few choice pictures. By the time my second son was walking I had my first good digital camera. Things were better, but I still had to drag pictures onto a hard drive, bring them into Photoshop, painstakingly process them and then upload to Flickr. And then, seemingly overnight, we took a leap. Phones got good cameras. Photo processing right on the camera got dead simple. And Instagram happened. We rarely think about it, but: digital photography went from hard and expensive to cheap and ubiquitous in a very short period of time.
I want to make the same thing happen with mobile apps. Today: making a mobile app — or a complex interactive web page — is slow, hard and only for the brave and talented few. I want to make making a mobile app as easy as posting to Instagram.
At Mozilla, we’ve been talking about this for while now. At Mobile World Congress 2013 we floated the idea of making easy to make apps. And we’ve been prototyping a tool for making mobile apps in a desktop browser since last fall. We’ve built some momentum, but we have yet to solve two key problems: crafting a vision of app making that’s valuable to everyday people and making app making easy on a phone.
We came one step closer to solving these problems last week win London. In partnership with the GSMA, we organized a design workshop that asked: What if anyone could make a mobile app? What would this unlock for people? And, more interestingly, what kind of opportunity and imagination would is create in places where large numbers (billions) of people are coming online for the first time using affordable smartphones? These are the right questions to be asking if we want to create an Instagram Effect for apps.
The London design workshop created some interesting case studies of why and how people would create and remix their own apps on their phones. A DJ in Rio who wanted to gain fans and distribute her music. A dabbawalla in Mumbai who wants to grow and manage the list of customers he delivers food to. A teacher in Durban who wants to use her Google doc full on student records to recruit parents to combat truancy. All of these case studies pointed to problems that non-technical people could more easily solve for themselves if they could easily make their own mobile apps.
Over the next few months, Mozilla will start building on-device authoring for mobile phones and interactive web pages. The case studies we developed in London — and others we’ll be pulling together over the coming weeks — will go a long way towards helping us figure out what features and app templates to build first. As we get to some first prototypes, we’re going get the Mozilla community around the world to test out our thinking via Maker Parties and other events.
At the same time, we’re going to be working on a broader piece of research on the role of locally generated content in creating opportunity for people in places whee smartphones are just starting to take at off. At the London workshop, we dug into this question with people from organizations like Equity Bank, Telefonica, USAID, EcoNet Wireless, Caribou Digital, Orange, Dalberg, Vodaphone. Working with GSMA, we plan to research this local content question and field test easy app making with partners like these over next six months. I’ll post more soon about this partnership.
Stacey asked me for a refresher on Test Driven Learning for Hacker School, so here we go.
Test Driven Learning is a software engineer’s articulation of Wiggin & McTighe’s Understanding by Design framework after being strongly influenced by Ruth Streveler’s ”Curriculum, Assessment, and Pedagogy” course at Purdue.
Many software engineers are familiar with the process of Test Driven Development (TDD).
Test Driven Learning (TDL) simply says “it’s the same thing… for your brainnnnn!”
That’s it. Really.
Step 2 is the part most people flub. With software tests, you have a compiler/interpreter forcing you to be precise. With learning assessments, you don’t — but you need exactly the same level of precision and external execution. If you asked a group of external people (with appropriate expertise) whether you’d passed the assessment you set for yourself, there should be no disagreement. If there’s disagreement, your assessment needs a redesign.
A good assessment is a goal that helps you stretch and reach it; sometimes it encourages you to do more. But sometimes it also gives you permission to stop doing stuff – you’ve written the code, you’ve delivered the talk, they met the criteria you set — and now you’re done. You can absolutely set a new goal up and keep on learning. However, you’re no longer allowed to say you Haven’t Learned X, because you’ve just proven that you have.
Here are some rough-draft quality TDL assessments you might start with, and a bit of how you might improve them.
I will learn Python. (What does that even mean? How will you know you’ve learned it?) I will complete and pass any 50 CodingBat exercises in Python. (But I could do that by solving 50 really easy problems.) Only 10 of those 50 problems can be warm-ups, and at least 20 of them must be Medium difficulty or greater. (Does it matter if you get help with the problems?) Nope, I can get as much help as I want from anyone, as long as I could explain the final solution to another programmer.
I will get better at testing. (What do you mean by “testing”?) I write a lot of code, but I’ve never written tests for any of it. I hear the nose framework is nice. (What do you mean by “better”?) Well, I’ve never written a test at all, so even going from 0 to 1 would be an improvement. I could use nose to write tests for 3 different pieces of working code I’ve already written. (Do these need to be big or exhaustive tests?) Nope, I’m just trying to learn what writing tests is like, not get full test coverage on my code… at least not yet. Even if I write a 3-line test that checks out one minor function, it counts as one of the 3 tests. (What does it mean for a test to be “done”?) When someone else can check out and successfully run my code and my test suite on their computer without needing to modify either bit of code, it’s done.
I will understand how databases work. (By “understand,” do you mean the mathematical theory behind their design? Or how to actually implement and use one?) Oh geez, the latter. I don’t care about the math so long as I know how to interface with a database. Any sort of database. (So you need to make a demo.) Yeah, but that’s not enough; I can blindly type in code from a tutorial, but that doesn’t mean I’d be able to field questions on it. (What could you do about that?) I will give a presentation to fellow Hacker Schoolers demonstrating a small database interaction in code I have written. That’s an easy binary to check; either I’ve given the presentation or I haven’t.
Thoughts, questions, ideas? Got your own example TDL assessment (at any stage of revision), or ways to improve the ones above? Holler in the comments.
Once again I have the (incredible) opportunity to be at Hacker School playing around with my “edupsych for hackers” material… I’ve never revised and re-delivered a talk so often, and it’s good to be forced to see how this material improves with age and experience.
Differences between this and the PyCon Toronto version include the cutting-out of Bloom’s Taxonomy (it’s cool, just not high-priority), the separation of nearly all the Felder-Silverman Engineering Learning Styles material to a separate workshop for tomorrow, and dropping the emphasis on (making fun of) academia’s complicated verbiage, because… that’s not the point.
The slidedeck is at http://bit.ly/hackerschool-f2013 and embedded below. Someday, I want to get this talk taped and transcribed.
These are rough, incomplete notes from my getting started in open source session at Hacker School, cribbed from chat notes taken by attendees (thanks, folks!)
We started with a replay of the 5 minute exercise wherein participants dump me in the middle of an open source project I’m clueless about, and watch me think-aloud as I desperately try to figure out what’s going on — basically, “how does an experienced hacker evaluate an open source community?” This time I had 10 minutes, so I got pretty far checking with out Ogre3D (which looks great).
Our first big goal for the session was lurking. You can find projects on a topic by searching the internet for “[topic] open source” (or “[topic] Free Software,” or so forth). When you have a few potentials, ask yourself:
Most projects have communication methods for code and not-code, and for asynchronous and synchronous work. Try to lurk all four. The table below may help.
|Synchronous Code: git commits (announced by a bot in chat, sent to a feed, etc)||Synchronous not-code: chat (typically IRC)|
|Asynchronous Code: issue/ticket/bug tracker||Asynchronous not-code: mailing lists or forum, AND wiki|
Our second big goal for the session was introducing yourself. This usually happens by sending an email introduction to the developers mailing list, then referencing that email (find the URL of your message in the mailing list archives) during initial chat conversations with people. Maggie brought up “submitting a pull request as your intro letter,” which is a great idea. What this means is that your introduction email should explain how you are:
This sounds intimidating until you realize “something useful to help” can be very, very small. For example, Rebecca emailed tent saying that she’d been working through their documentation and had ideas for how to improve the clarity of the particular docs at a certain URL (specific helpful task!) and was wondering where to submit her changes (help me do it!). Jade emailed GIMP offering to test patches (specific helpful task!) and asked which branch and patches would be most helpful to verify (help me do it!). None of these tasks involve deep knowledge of the code; that comes later. They involved “writing in English” (not a problem for most Hacker Schoolers) and “compiling C” (not an impossible thing to learn, especially when you’re surrounded by programmers eager to teach).
It’s helpful to pair with someone and peer-pressure (positively!) each other to ship your intro emails.