Two overall framings of hackers’ engagement with the political have dominated discussion: “hacktivists” or activists who leverage instrumental uses of online technologies for direct political action such as protest and disruption (Jordan and Taylor, 2004), and geographically distributed communities of practice where principles of openness enable forms of political action (Coleman, 2004). Gabriella Coleman (2012a) argues that pragmatism enables action on issues related to informational freedoms and reflects liberal democratic tenets such as freedom of speech. According to Coleman (2004), explicit involvement in “politics” in a formalized sense is distasteful to free and open-source hackers, as it is viewed as “buggy, mediated, and tainted action clouded by ideology” (p. 513). Civic hacking represents a third mode of participation among a group that often explicitly engages with political causes through designing, critiquing, and manipulating software and data to improve community life and infrastructures of governance. Civic hackers therefore have distinct histories, con-tours, and conflicts from other genres of hackers, even as they share a certain family resemblance (Wittgenstein, 1953).

Civic hacking can broadly be described as a form of alternative/activist media that “employ or modify the communication artifacts, practices, and social arrangements of new information and communication technologies to challenge or alter dominant, expected, or accepted ways of doing society, culture, and politics” (Lievrouw, 2011: 19). Ample research has considered how changes in technology and access have created “an environment for politics that is increasingly information-rich and communication-inten-sive” (Bimber, 2001). Earl and Kimport (2011) argue that such digital activism draws attention to modes of protest—“digital repertoires of contention” (p. 180)—more than formalized political movements

Organizations such as Code for America (CfA) rallied support by positioning civic hacking as a mode of direct partici-pation in improving structures of governance. However, critics objected to the involve-ment of corporations in civic hacking as well as their dubious political alignment and non-grassroots origins. Critical historian Evgeny Morozov (2013a) suggested that “civic hacker” is an apolitical category imposed by ideologies of “scientism” emanating from Silicon Valley. Tom Slee (2012) similarly described the open data movement as co-opted and neoliberalist.

Other definitions capture broader notions of civil society. A 2010 study backed by the Open Society Foundation described civic hackers as “deploying information technology tools to enrich civic life, or to solve particular problems of a civic nature, such as democratic engagement” (Hogge, 2010: 10).

I conclude civic hackers are utopian realists involved in the crafting of algorithmic power and discussing ethics of technology design.

Successive waves of activists saw the Internet as a tool for transparency. The framing of openness shifted in meaning from information to data, weakening of mechanisms for accountability even as it opened up new forms of political participation. Drawing on a year of interviews and participant observation, I suggest civic data hacking can be framed as a form of data activism and advocacy: requesting, digesting, contributing to, modeling, and contesting data

What might Raymond Williams make of our ordinary hacker? He might be relieved to see the continued importance of hands-on work and reciprocity among ordinary people in hackerspaces, even if he found them too close to a drinking-hole (they are far from a high society tea-house). For their part, members would find much in common with Williams’ progressive embrace of technology paired with disdain for formalized education.

The durability of hackerspaces is curious, given their relative fragility. Hodder grappled with the idea that over time we become progressively more entangled. Hacker and maker spaces as a particular model have survived ideological inversions, international deployment, and alternate cultural interpretations. The heterogeny of hackerspaces, far from being a limitation, lends a mutability and easy embedding in various communities and social contexts. Entanglementalso suggests dependences outside of the space itself.

Echoing an old observation in activism about the “tyranny of structurelessness” (Freeman, 1972), power became difficult to contest when you remove the mechanisms to contest action. New visitors who didn’t immediately resonate with the space were turned off from the cold vision of geeks silently co-working next to each other. Longstanding members became frustrated by frequent clashes between hotheaded personalities. Then there were issues about what went where. Who didn’t put the hand drill back in the bin? Technology was a source of drama, particularly when commitments were discussed on email lists or in passing and then forgotten. Who said they would get the laser cutter running? Although sufficiently meta and informal to be palatable to members, it was hardly a smooth way to run an organization.

Individual agency is the core of do-ocracy, fostered and filtered through projects, objects, and tools in the space itself.

n large part the desire for autonomy alongside warm community relationships can be seen as an extension of what Fred Turner (2008) termed “new communalism.” New communalists emerged alongside the new left and believed in a kind of hive mind while rejecting formalized politics and institutions. Hackerspaces, as a kind of “third space” (Oldenburg, 1997), provided a site for these ideas to expand. Democracy was seen as cumbersome and slow. Do-ocracy provided speed and the freedom to act without consultation.

Members strived to make the invisible, sinewy dependences in the space visible. Despite its utility, the set of target boards was eventually left behind a storage bin.

Projects, as an entanglement, are “open, partial and indeterminate” (Hodder, 2012, p. 159).They might be being showed off at the next open house, orentirely forgotten. Peter noted that his hard drive was filling up with “functionally dead” shelved projects that got boring or require expertise from outside the space. Yet, to Peter failure was an indication of project success. He believed, as scholars of innovation do, that embracing failure contributed to better ideas. Projects also carried an ethical charge. Michael, a quiet member and software professional, reflected at length on what he called the “philosophical” side of projects. He saw them an inroad to “participation in the fabrication process” that was empowering. In his words, projects were “manufacturing liberation.”

Counter to a high-minded association of “liberal projects,” projects in hackerspaces resisted a final form. The action in hackerspace is more bricolage(Lévi Strauss, 1962, p. 18)than engineering. Projects in Geekspace arose spontaneously. Their inertia drew people to the space, bringing their tools and ideas that would then supplement the ideas of others. This churn is captured by how projects were seen as a success of the new space even though very few projects were actually finished.

These more formalized gatherings were an attempt to get people working and collaborating in a space that had mainly turned into a spot for hanging out, drinking and foosball. The shift to the new space was seen as an opportunity to encourage members to use the space in a more productive way. The space needed members as much as members needed the tools. Members echoed a liberalist concern with increasing freedom of individuals to act, while retaining hobbyist cultures’ engagement with materialities. Often hackerspace members also described the need for a hackerspace as part of a shift in their city’s economy

projectors refer to “people who find a way out of their difficulties by coming up with novel ideas” (Novak, 2008, p. 3)

Members became entangled with ordinary things and people, developing dependences they found alternately pleasurable and frustrating. Tools came to the space to suit individual needs, including shaping of recreational interaction. The more taut the dependences they develop, the more closely members aligned themselves with the space, and the better for the group

Eventually she became more entangled with social relationships, which helped her work on technical projects that brought a comfort of similarity from previous work. Initially she didn’t identify with the term “hacker.” Only later did she came to understand herself as oriented around self-sufficiency and creative problem-solving. For her, the resonance with hacking as an identity came after participation and a deeper entanglement.

The hands-on nature of the work to her resonated with her family history, love of tactile assembly, and disdain of consumerism. Vicki, like many members, came to view hackerspaces as sites that rejected consumerism, even as they paradoxically engaged in consumer culture by purchasing kits and materials.

Hackerand maker spaces are meta-organizational assemblages. Entanglement – through the notion fo “do-ocracy” –stands in for typical organizational trappings of rules, hierarchies and roles. Hackerspaces morph and evolve to meet the desires of participants, draw on affordances of tools and materialities of the space itself.

Hodder suggests that entanglements attain fittingness, or a degree of phenomenological and emotional appropriateness for particular groups. Fittingness is attained through abstraction, resonance, and affordances of particular things.

Hodder pushes us to consider how dependence relationships emerge over time and result in people getting “trapped” in particular routines and ways of acting.

to explore how webs of dependences balance participation and organization in the context of hackerspaces. Ian Hodder (2012) defined “entanglement” as dependences between humans and things, which are “stuck together” in a web. He defined things as entities that are “contained and identifiable” (p. 7) by a particular person or group, which gives them a presence and longevity. Dependences refer to enabling and constraining relationships that are created partly from how people recognize and perceive the material and immaterial qualities of things, and partly from the interlocking nature of things with other things.

this case study hopefully reveals how hackerspaces might be considered as a particular genre of organization that defies traditional organizational practices.

the ordinary hacker emerged from the entanglement ofhackerspaces. Writing on hacking has a rich subtext of intertwined human and non-human agencies. Tim Jordancompelling argued that the essence of hacking deeply involves reciprocalinteractions between individuals and things (Jordan, 2008). Hackers are often thought to be exceptional masters of technology. According this narrative, they leverage expertise with hands-on work to reveal what’s inside “black boxes.” This chapter explores an intriguing counter-argument: things make the hacker. This process deeply involves affect, a sense of community, and identification with a personal narrative.

hackerspace members’ relationship with materialities. In response, this chapter advances an idea about how interactions between individuals and things (Hodder, 2012) can shape collective action. Hackerspaces’ horizontalist mode of organizing is oriented around material forms of participation and communication.

As critics have noted, hackerspaces have only a thin veneer of democracy, made thinner still by a reliance on meritocracy. Members described the dominant ofrm of regulation in the space as “do-ocracy,”

Interactions through things, and perceptions about their potential, were ways to negotiate between seemingly conflicting imperatives of the individualism and communalism (A. L. Toombs, Bardzell, & Bardzell). Members would deliberately design activities that were incomplete to encourage a playful material improvisation. In these ways, the “material sensibilities” of members were particularly important. Similarly, reading a history of craft into software hacking, Lingel and Regan (2014) found that software hackers identified their work with craft as process, embodiment, and community. These sensitive readings of interactions with stuff seemed to more accurately capture the genre of hackerspaces, more so than action was guided by culture.

This work perceptively suggested that people often don’t arrive at hackerspaces with an identity fully-formed. Tools and projects, as socio-material assemblages, shepherded new arrivals in and helped them understand

economic vision didn’t seem to hold water, while a cultural perspective seemed insufficient to explain hacker and maker spaces as a particular genre of participatory organization. Recent ethnographic inquiry on hackerspaces grounded in social and material interactions provides a way forward. While hackerspaces may be inspired by online peer production, the transfer of this ethic to offline space is often imperfect due to the nature of physical things

economic vision didn’t seem to hold water, while a cultural perspective seemed insufficient to explain hacker and maker spaces as a particular genre of participatory organization.

Most members of western hackerspaces I encountered were fairly well-off and had day jobs. The last thing they wanted to do at the end of the day was come to a second workplace with deadlines and responsibilities

Challenges have been mounted to those who view hackerspaces through simple economic and political lenses. One comes from viewing hackerspaces as a whole with a coherent ideology.

Maxigas (2012) used political ideologies to claim a differences between overtly politicized lineage of European hack labs and only partly political hackerspaces. By his reading, hackerspaces either came from a lineage of activism or had activist potential that had yet to be fully activated. Others have taken a middle-ground, using cultural approaches to hackerspaces

As I will discuss shortly, hackerspaces pull people in, and it is often only through shared engagement that they understand themselves as hackers and makers. Unpacking emic terms members use to describe this entanglement — project and do-ocracy — is the focus of this chapter.

My more explicit framing of hackers as ordinary — approachable, common, and attainable — lets us consider how collectives and identities are forged among everyday people in unremarkable spaces and material contexts.

That hackers are created, not born, is hardly a new claim. In Coding Freedom Gabriella Coleman described how an open-source hackers’ identity emerged from a fervent brew of digital connectivity, technological concepts, and shared work (Coleman, 2012). Political awareness was connected to liberalism through open-source and code over time. Put simply, being a hacker is a trajectory with multiple points of origin and destinations. Neither is suggesting that hackers are ordinary meant to discard a concern with exceptional hackers. We should be concerned with the Chelsea Mannings and Edward Snowdens of the world, and the causes they have championed.

Worrying that hacking might be “gentrified,” as Scott does, brings up a further irony. Hacking’s expansion beyond circles of tech-savvy, affluent white males demonstrates diversity, not homogeny. Seeking an essence of hacking misses this diversification. There are also risks in separating the exceptional and everyday hacker. A wall creates artificial distinctions between “haves” (intelligence, political awareness, skills) and “have nots.” The more productive perspective to gentrification might be hybrid forms of hacker pluralism.

We may simply misunderstand what motivates them to do what they do as new groups adopt the identity. We presume they follow in a certain mold of hackers, or are Trojan horses for Silicon Valley.

A similar wall now exists between the exceptional and ordinary hacker. Journalistic and academic writing defines hackers as resistant geeks capable of bringing about changes in governments and corporations. The hacker is the powerful underdog, plotted against by the powers that be. Their anti-hero status is even more salient when viewing the trope of the hacker in popular media. We cheer for the exceptional hacker, as well we should. But in many readings hacking’s subversive nature is assumed to be diluted by its mainstreaming. Disappointment is rampant when hackers are found not to be sufficiently resistant. Brett Scott echoes this perspective when he writes about how the “wild and anarchic” hacker ethos was gentrified by “yuppies” (2015). Evgeny Morozov (January 13, 2014) interpreted makers as no more than commodified hackers lacking a radical edge. Hackers simply lost their mojo. It is only with a shrug and a sigh they are revealed to be dupes of a fraudulent ideology. At most dystopian, David Golumbia’s cyberlibertarian thesis, coming from critical studies, proposes that hackers’ espouse a technological solutionism that is responsible for the collapse of the political left (Golumbia, 2013).

Members often toutthat “anyone can be a hacker.”While this claim is dubious– participation is limited by technical inclinations, skills, and comfort hanging around rowdy spaces –hackerspaces certainly helpproduce an “ordinary hacker.” Theyare sites where we can observe hacking’s movement from subculture to mainstream, and from an edgy to popular identity.

Hackerspaces’ messy, heterogeneous interactions between people and things reflect an odd bundle of concepts. They are competitive andneoliberalist. Simultaneously, they are injected with feelings of community and liberal freedoms.To understand the logic that undergirds this confluence of concepts and where it leadsI argue we must return to Williams’ notion of ordinary.

Ordinariness– the everyday, unexceptional, and mundane – is a useful hermeneutic to view collective action and identity in hacker and maker spaces (or simply “hackerspaces”) (Schrock, 2014). This framing is a response toassumptions about hackers as exceptional. Two types of exceptionality have emerged. Critical scholars praiseactivism in hackerspaces(Maxigas, 2012)orotherwise bemoan the invisible hand of “cyberlibertarian” ideology(Golumbia, 2013). Then there are writers who look tohackerspaces as the key toeconomic profitability(Anderson, 2012). Thedefinitional disputebetween activism and corporatization bears more than a whiff of similarity toa previous such dispute; Pekka Himanen’s “hacker ethic”(Himanen, 2001) idealized hackers as labor for modernity, while McKenzie Warkpositioned hackers as a resistant class (Wark, 2004).

if stopped in their development and reified too early, are potential sources of hacks in the derogatory sense. The latter is, according to their stories, exactly what happened when, 40 years ago, the prototypes left the labs too soon, and entered the world of Apple, IBM, and Microsoft, producing the accumulation of bad decisions that led to a world where people stare at smartphones.

To prevent misunderstanding: neither I, nor the engineers I research, think that the actual future can be hacked together singlehandedly by a bunch of engineers in Palo Alto or Oakland. But I do think that radical engineers such as Engelbart’s, Kay’s, or maybe Victor’s research groups, in their specific, highly privileged positions, add something crucial to the complex assemblage of forces that move us in the direction of futures.

If you are lucky, you have the conditions and abilities to work all this through in a long, non-linear process also known as bootstrapping, where you go through many iterations of hacking apart and hacking together, all the while creating fundamentally different ideas about what technologies should do, and could do, matched by a succession of devices and practices that help shape these ideas, and “demo” to yourself and others that some utopias might not be out of reach. This is what radical engineers do.

The black boxes will most likely also contain ideas about the roles of the different types of engineers, programmers, designers, managers, and so on. If you take all this apart, you might look at the elements, throw away a lot of them, twist others, add stuff from elsewhere, and grow some on your own. You will look into different, often historical, technological paradigms, other ideas about what will become technologically possible (and when), different ideas of social order, the good life and problems that need addressing, other books to be read, alternative uses of the forces of media, and different ideas about the kind of people and the nature of their professions or non-professions, who should take charge of all this.

That future is not given, but depends on the medium the group is imagining. It thus depends on the properties of the medium that the group is exploring, selecting, and practicing. On the one hand, technology enables a new medium, which is imagined as shaping the future, on the other hand the future is imagined as shaping the new medium, which then should drive technology.

Computing is to take the role of an infrastructure: much as books need light, but are not modeled after the light’s logic, the medium might draw, where necessary, on the computing possibilities provided by the OS in the background, but it should not be driven by them. Instead, the dynamic spatial medium should be driven by properties of the medium itself, and as such, it should drive technology.

The lab as a whole—its walls, desks, whiteboards, roofs, machines, and the people inhabiting it—functions as a first demo for an alternative medium.

As such, bootstrapping can assume different scopes and directions. While Engelbart’s and English’s project might sound ambitious, they still believed, at least in the 1960s, that bootstrapping inside a research group would achieve the desired results. Alan Kay’s Learning Research Group extended this setting in the 1970s through pedagogy and McLuhanite media theory. By bringing children in, they aimed to achieve recursive effects beyond the lab, with the long-term goal of involving the whole world in a process akin to bootstrapping. Bret Victor and his research group’s form of bootstrapping resembles a multi-layered onion. The kind of people who should be part of it, and at what moments, can lead to intense internal discussion.

Simply building prototypes with prototypes would not be a smart recipe for radical engineering: once in use, prototypes tend to break; thus, a toolset of prototypes would not be a very useful toolset for developing further prototypes. Bootstrapping as a process can thus only work if we assume that it is a larger process in which “tools and techniques” are developing with social structures and local knowledge over longer periods of time. The processes are recursive, much like the “recursive publics” that Chris Kelty (2008:30) describes for the free software development community: in both cases developers create sociotechnical infrastructures with which they can communicate and cooperate, which then spread to other parts of life. Kelty shows how such recursive effects are not simply the magical result of self-enforcing positive feedback. Recursive processes are based on politics. And resources. And qualified personnel. And care. And steering. In short, they need to be continually produced.

in a continuous process of “augmenting human intellect.” According to Engelbart, the latter can be achieved through the process of “bootstrapping.” This is a term that can mean many things in the Silicon Valley, from initiating systems to kicking off startups, but in the context of Engelbart’s work, bootstrapping is the “…interesting (recursive) assignment of developing tools and techniques to make it more effective at carrying out its assignment. Its tangible product is a developing augmentation system to provide increased capability for developing and studying augmentation systems” (Engelbart and English 2003:234). Just as Moore’s so-called law, this is a dream of exponential progress emerging out of nonlinear, self-enforcing feedback. How much more Californian can you be?

☛ Risk: The Wikimedia global movement does not improve in cultural, geographic, or demographic diversity, leading to less relevant and lower-quality content for a global audience.

Each repository database has a table holding the username, privileges, and login credentials for users authorized to interact with that particular database.

Neither Apple nor Microsoft really captured the essence of what made the Smalltalk system powerful. They used it as a model to make computers more accessible, but they left out the aspect of letting people bend the system to their will, to customize it to be just what they want. Their systems were really an object-oriented facade over a traditional, non-object-oriented system. They lacked a consistent metaphore of everything being an object. The web has been even more stultifying in this regard (I mean the web interface), though Firefox has helped some, so I hear, with the concept of browser extensions.

Elaborating on what I said earlier, RoR has an appeal to web developers because, given the skills they have, it provides an "instant gratification" that's very real for them, in the same way that Squeak does for graphics and text. In that way it's approachable. That approachability makes it "worth the trip" to learn about more of it.

Smalltalk is simply data manipulating programs that are themselves data–it’s the inverse of the Lisp philosophy, but the end result is the same.

Furthermore, the results could focus on drawing the user into the virtual app space (immersive) or could use the portable nature of tablet to extend the experience into the physical space inhabited by the user (something I have called ’emersive’). Generative (emersive) Books that project coloured ambient light and/or audio into a darkened space Generative (immersive) Books that display abstracted video/audio from cameras/microphone, collaged or augmented with pre-designed content Books that contain location specific content from the internet combined with pre-authored/designed content

Jessica Helfand in her essay The Dematerialism of Screen Space (2001) critiques the phenomenon of design practise being led by developments in software engineering. She argues that designers should take the initiative: “design must submit to a series of commands and regulations as rigourous as those that once defined Swiss typography. Aesthetic innovation, if it indeed exists at all, occurs within ridiculously preordained parameters: a new plug-in, a modified code, the capacity to make picture and words ‘flash’ with a mouse in a non-sensical little dance. We are all little filmmakers, directing on a pathetically small screen – yet broadcasting to a potentially infinite audience. This in itself is conflicting (not to mention corrupting), but more importantly, what are we making? What are we inventing? What are we saying that has not been said before?” Helfand here is referring to the web, but her argument applies equally well to designing tablet publications. Designers of book and magazine apps should be asking themselves those last three questions. Since tablet publishing conventions are in the process of being formed (like child invention), we have a unique opportunity right now to influence their direction.

Some key themes arise from the two NNG reports on iPad usability: App designers should ensure perceived affordances / discoverability There is a lack of consistency between apps, lots of ‘wacky’ interaction methods. Designers should draw upon existing conventions (either OS or web) or users won’t know what to do. These are practical interaction design observations, but from a particular perspective, that of perceptual psychology. These conclusions are arrived at through a linear, rather than lateral process. By giving weight to building upon existing convention, because they are familiar to the user, there is a danger that genuinely new ideas (and the kind of ambition called for by Victor Bret) within tablet design will be suppressed. Kay’s vision of the Dynabook came from lateral thinking, and thinking about how children learn. Shouldn’t the items that we design for this device be generated in the same way?

The document argues that the use of illusionary surfaces and objects will lead to a more intuitive and pleasurable experience for the user. It also, yet again, looks to prior conventions for solutions rather than starting afresh.

A first list of projects are available here but more can be found by interacting with mentors from the Pharo community. Join dedicated channels, #gsoc-students for general interactions with students on Pharo slack. In order to get an invitation for pharoproject.slack.com visit the here Discuss with mentors about the complexity and skills required for the different projects. Please help fix bugs, open relevant issues, suggest changes, additional features, help build a roadmap, and interact with mentors on mailing list and/or slack to get a better insight into projects. Better the contributions, Better are the chances of selection. Before applying: Knowledge about OOP Basic idea about Pharo & Smalltalk syntax and ongoing projects Past experience with Pharo & Smalltalk Interaction with organisation You can start with the Pharo MOOC: http://files.pharo.org/mooc/

Each whale is a perceptive messenger of the state of its species, the state of the cetaceans, the state of the oceans as a whole, as close and determined observation by Mayo and many others has shown. Now each piece of baleen is making those animals into messengers from the past, as we are expanding our own range of perception to understand.

but scientists have found that biochemical traces of some of its experiences persist in its body, even long after death. Just as geologists decode the history of the Earth from rocky strata, or dendrochronologists interpret past climactic conditions from tree rings, so biologists are now learning to read a whale’s life history as inscribed in its baleen. This anatomical oddity, part of a class of animal tissues that are emerging as tenacious biological recordkeepers, could reveal a monthly, even weekly, historical record of a whale’s life events stretching back as long as two decades. Just how much it will tell us remains to be seen.

I’ve collected the following list of needs based on what I’ve noticed across projects. I’ve tried to roughly organize it from critical (bottom of Maslow’s pyramid) to legacy (higher on the pyramid).

So as long as a project meets the first criteria (i.e. is popular), we ought to move beyond questioning whether it deserves to exist, and instead focus on what we can do to ensure it is healthy and supported.

From far away, successful Bazaars look like moneyless anarchic systems, but up close, the bulk of responsibility falls on a couple of people, who are usually being paid to do the work.

Open source projects don’t start as communitiesMany would agree that open source projects don’t start out as Bazaars, but just in case, I’ll emphasize the point. Raymond himself wrote:It’s fairly clear that one cannot code from the ground up in bazaar style. One can test, debug and improve in bazaar style, but it would be very hard to originate a project in bazaar mode. Linus didn’t try it. I didn’t either.Somebody has to be chiefly responsible for an open source project’s initial development. In Linux’s case, it was Linus. Somebody has to live and breathe the problem all day. Once that project is in a stable position, the community helps support it.

The whole github ‘no licence’ thing when they started was unbelievably naive and has contributed to a world where there is piles of software that purports to be available but it actually ‘all rights reserved’ to the author, because that’s what international law defaults to. I’ve had to explain this numerous times to people (and companies that really should know better!) who’s code I want to use who have no understanding of why it matters. This is a sad, and rather unnecessary, state of affairs (somewhat improved since github stopped that idiotic practice, but there are still people below saying ‘but I put it online so it must be OK for you to use’).

Interesting to see what some people think ‘open source’ is these days. Back when the OSI was created with the movement that wanted to call it ‘open source’ instead of ‘free software’, people said ‘don’t do that — it devalues the fundamental point’. And here we are 20 years later, with OSS being hugely well-used, but many of the contributors insisting that licences are irrelevant or just having available source is all that’s needed, or it’s all about the community. Well I guess those of us who though that the ‘Open Source’ naming was a bad plan are proved right about the downside. But of course we’ll never know if it would have been so successful if it had remained as ‘Free Software’ (I don’t see why not, because it’s the process and efficiency that has made it popular).

The public sector should definitely prioritize Open Source, as a fair ground for companies and individuals to compete for their business. This should drive cost down (and therefore taxes), while making local developers happy.

Open source is about emphasizing community over self. But today’s open source doesn’t really operate that way — at least not in the long tail of smaller, homegrown projects. Whether this is a symptom of “new developers” who need to be properly socialized, as some would suggest, or truly an evolution of open source culture, is still up for debate. I’ll leave that to you.

In open source, you can only have “my” in the associative sense. There is no possessive “my” in open source.”

I don’t want the culture of open source to be organized around a legal definition. I want to zoom out and look at the broader ecosystem (of which the legal definition is one, essential node). A friendlier, more accessible term would make it easier to discuss topics like sustainability, collaboration, and people involved. Those aspects don’t need to be included in the official definition, but they still matter.I still like the term “public software” because it allows more people (including those new to, or unfamiliar with, open source, even if they use or benefit from it) to quickly understand what open source software is and how it should be protected. It doesn’t change the legal definition at all; if anything, it enforces it better, because we would want to define and protect public software exactly as we would any other public resource.

Early open source was about the idea that code is ownerless, enforceable by license, which theoretically leads to resilient software.Modern open source is about 1) building and 2) collaborating in public.The conversation has shifted from protecting the rights of a user to adopt the software as they wish (now the norm) to protecting the rights of the author or community that stewards the code (still TBD).

I’m interested in figuring out a term that feels inclusive, easy to grok, and free of political baggage.

In my last post, I said that we couldn’t charge for Python any more than we could charge for English. The difference between English and Python is that one requires dedicated maintenance and upkeep so that it doesn’t break. It has millions of dollars, and even lives, riding on it.

By not charging for open source infrastructure, we protect the right of anybody with an Internet connection to teach themselves how to code and build. This is good for startups, and for you.

Those in positions of power have always craved a mechanism with which to expose the inner beings of citizens, to reveal ‘the fragment of darkness that we each carry within us’, as Foucault described it. There are, or seem to be, rather dangerous and wild expanses within each individual. If we are to be controlled, that must be made known, and tamed. There is no better way to divide and subdue a people, and seduce them into self-regulation, than to expose their perversions but promise absolution.

People unburden themselves to their followers in the hope that their needs will be validated, their opinions affirmed, their quirks delightfully accepted. The result is a growing conformity within camps, as well as a narrowing of the shared space for understanding and dialogue between them.

Later, according to Foucault, the institution of confession shifted from religion to a host of secular traditions, such as confessional literature, medical examinations and psychoanalysis. But they all operated on the same principle, which was to patrol the boundary between what was normal and acceptable, and what was shameful and deviant. ‘The obligation to confess is now relayed through so many different points, is so deeply ingrained in us, that we no longer perceive it as the effect of a power that constrains us,’ Foucault wrote. ‘On the contrary, it seems to us that truth, lodged in our most secret nature, demands only to surface.’

A man without shame, Plato says, is a slave to desire – for material goods, power, fame, respect. Such desire is tyrannical because, by its nature, it cannot be satisfied.

Having a smartphone and access to the internet does not automatically equip us with the tools necessary for effective and respectful collaboration, negotiation and speech, such as democracy requires.

the act of watching is itself a devastating exercise of power. It has the capacity to influence behaviour and compel conformity and complicity, without our fully realising it.

The American theorist Bernard Harcourt points out in Exposed: Desire and Disobedience in the Digital Age (2015) that ‘surveillance state’ hardly fits the bill any more. He prefers to talk of a ‘tentacular oligarchy’, to include corporations now spying on us from numerous vantage points. To this we must add our audience followers, from colleagues and acquaintances to the public at large.

In the presence of ever-watchful witnesses, he said, physical coercion is no longer necessary. People police themselves. They do not know what the observers are registering at any given moment, what they are looking for, exactly, or what the punishments are for disobedience. But the imagination keeps them pliant. In these circumstances, Foucault claimed, the architecture of surveillances become perniciously subtle and seamless, so ‘light’ as to be scarcely noticeable.

That’s not to say that social media curbs our self-awareness, or that our internet selves aren’t highly artificial and curated. Nor that people living in oppressive regimes, or as minorities in societies where they know they will be targeted, aren’t justifiably anxious about what they say online. But the point remains that digital media have radically transformed our conceptions of intimacy and shame, and they’ve done so in ways that are unpredictable and paradoxical.

In the future, scholars who lean on digital helpmates are likely to dominate the rest, enriching our literary culture and changing the kinds of questions that can be explored. Those who resist the temptation to unleash the capabilities of machines will have to content themselves with the pleasures afforded by smaller-scale, and fewer, discoveries. While critics and book reviewers may continue to be an essential part of public cultural life, literary theorists who do not embrace AI will be at risk of becoming an exotic species – like the librarians who once used index cards to search for information.

Like many other AI practitioners, I’m a philosophical functionalist: I believe that a cognitive state, such as one derived from reading, should not be defined by what it is made of in terms of hardware or biology, but instead by how it functions, in relation to inputs, outputs and other cognitive states. (Opponents of functionalism include behaviourists – who insist that mental states are nothing other than dispositions to behave in certain ways – and mind-brain identity theorists – who argue that mental states are identical with particular neural states, and are tied to specific biological ‘hardware’.)

AI criticism is also limited by the accuracy of human labellers, who must carry out a close reading of the ‘training’ texts before the AI can kick in. Experiments show that readers tend to take longer to process events that are distant in time or separated by a time shift (such as ‘a day later’).

Even though AI annotation schemes are versatile and expressive, they’re not foolproof. Longer, book-length texts are prohibitively expensive to annotate, so the power of the algorithms is restricted by the quantity of data available for training them.

In most cases, this analysis involves what’s known as ‘supervised’ machine learning, in which algorithms train themselves from collections of texts that a human has laboriously labelled.

Consider the opening sentence of Gabriel García Márquez’s One Hundred Years of Solitude (1967): ‘Many years later, as he faced the firing squad, Colonel Aureliano Buendía was to remember that distant afternoon when his father took him to discover ice.’ The complex way in which Márquez represents the passage of time is a staple of modern fiction. The time corresponding to ‘Many years later’ includes the fateful time of ‘facing’ the firing squad, which in turn is simultaneous with that final ‘remember’-ing, which is years after ‘that distant afternoon’. In a single sentence, Márquez paints a picture of events in the fleeting present, memories of the past and visions for the future.

The so-called ‘cultural’ turn in literary studies since the 1970s, with its debt to postmodern understandings of the relationship between power and narrative, has pushed the field away from such systematic, semi-mechanistic ways of analysing texts. AI remains concerned with formal patterns, but can nonetheless illuminate key aspects of narrative, including time, space, characters and plot.

The ‘structuralist’ strand of literary theory tends to deploy close – sometimes microscopic – readings of a text to see how it functions, almost like a closed system. This is broadly known as a ‘formal’ mode of literary interpretation, in contrast to more historical or contextual ways of reading.

Bazaars are rhetoric, not reality

As in any contract, there’s a balance of power. If the architecture of today’s web is any indication, that balance is skewed toward the designers. Unless we want to keep pinging around like Skinner’s pigeons (or like poor Michael S), it’s worth paying a little more attention to those whom our attention pays.

‘In the past, if you were an alcohol distiller, you could throw up your hands and say, look, I don’t know who’s an alcoholic,’ he said. ‘Today, Facebook knows how much you’re checking Facebook. Twitter knows how much you’re checking Twitter. Gaming companies know how much you’re using their free-to-play games. If these companies wanted to do something, they could.’

sites such as Facebook and Twitter automatically and continuously refresh the page; it’s impossible to get to the bottom of the feed.

At first, if you want to make money, you sell whatever is in the room. Maybe it’s excellent journalism. Maybe it’s a game or a recipe. Maybe it’s an item that will get shipped to someone’s house. In this model, the internet offers a straightforward transactional experience in digital space.Over time, instead of making money from whatever is in each room, companies begin to monetise the doors. They equip them with sensors. Each time you go through one, someone gets paid. Immediately, some people will start adding a lot of new doors. Other people will build rooms that are largely empty, but that function as waystations, designed to get as many people as possible to enter and leave.

But she argues that, when it comes to machine design, it’s not exactly about giving people what they do or do not want. What matters, Schüll says, is ‘the accentuating, accelerating and elaborating that happens between the wanting and the giving’.

Fact-based journalism now competes with false information for our attention while our cities and citizens become both more connected by technology and more divided by ideology and income. The values reflected in lines of code, whether it be at the ATM, when we search on internet or drive a car, are already affecting what we think, what we do and what information we share with those around us.

Video games need to discover what’s special and different about their own medium to break out of their cultural ghetto.

Smalltalk doesn’t have to be pragmatic, because it’s better than its imitators and the things that make it different are also the things that give it an advantage.

Self contained. All of the source code is accessible inside the image. One can change any of it at any time. Every tool is written in Smalltalk. If one doesn't like how something works, one can change it. If one wants to add a feature, one is empowered to. Since everything is open, one can even change how the language works. It's programming without constraints. The original refactoring tools were written in Smalltalk.

Members can be added to the TC at any time. Any committer can nominate another committer to the TC and the TC uses its standard consensus seeking process to evaluate whether or not to add this new member. Members who do not participate consistently at the level of a majority of the other members are expected to resign.The TC just uses the same consensus seeking process for adding new members as it uses for everything else.It’s a good idea to encourage committers to nominate people to the TC and not just wait around for TC members to notice the impact some people are having. Listening to the broader committers about who they see as having a big impact keeps the TC’s perspective inline with the rest of the project.As a project grows it’s important to add people from a variety of skill sets. If people are doing a lot of docs work, or test work, treat the investment they are making as equally valuable as the hard technical stuff.

Avoid creating big decision hierarchies. Instead, invest in a broad, growing and empowered contributorship that can make progress without intervention. We need to view a constant need for intervention by a few people to make any and every tough decision as the biggest obstacle to healthy Open Source.

In pure consensus everyone essentially has a veto. So, if I don’t want something to happen I’m in a strong position of power over everyone that wants something to happen. They have to convince me and I don’t have to convince anyone else of anything.To avoid this we use a system called “consensus seeking” which has a long history outside of open source. It’s quite simple, just attempt to reach a consensus, if a consensus can’t be reached then call for a majority wins vote.Just the fact that a vote is a possibility means that people can’t be obstructionists, whether someone favor a change or not, they have to convince their peers and if they aren’t willing to put in the work to convince their peers then they probably don’t involve themselves in that decision at all.

Not every committer has the rights to release or make high level decisions, so we can be much more liberal about giving out commit rights. That increases the committer base for code review and bug triage. As a wider range of expertise in the committer pool smaller changes are reviewed and adjusted without the intervention of the more technical contributors, who can spend their time on reviews only they can do.

A key part of the liberal contribution policies we’ve been building is an inversion of the typical code review process. Rather than the default mode for a change to be rejected until enough people sign off, we make the default for every change to land. This puts the onus on reviewers to note exactly what adjustments need to be made in order for it to land.

Sure, we get bad bugs, but we have a ton of contributors who can immediately work with people who log them to educate them on better practices and treat it as an opportunity to educate. This is why we have documentation on writing good bugs, in order to educate contributors, not as a barrier to entry.Creating barriers to entry just reduces the number of people there’s a chance to identify, educate and potentially grow into greater contributors.

We know what happens to unhealthy projects over a long enough time period, more maintainers leave, contributions eventually fall, and if we’re lucky users leave it. When we aren’t so lucky adoption continues and years later we’re plagued with security and stability issues in widely adopt software that can’t be effectively maintained.The number of users a project has is a poor indicator of the health of the project, often it is the most used software that suffers the biggest contribution crisis.

This is what a healthy project should look like. As the demands on the project from increased users rise, so do the contributors, and as contributors increase more are converted into committers. As the committer base grows, more of them rise to the level of expertise where they should be involved in higher level decision making.If these groups don’t grow in proportion to each other they can’t carry the load imposed on them by outward growth. A project’s ability to convert people from each of these groups is the only way it can stay healthy if its user base is growing.

Vocabulary* A Contributor is any individual creating or commenting on an issue or pull request. * A Committer is a subset of contributors who have been given write access to the repository. * A TC (Technical Committee) is a group of committers representing the required technical expertise to resolve rare disputes.

“Funding infrastructure” means more than funding maintainers. This is partially why I think crowdfunding platforms and donation campaigns, while helpful, can only go so far.Instead, we need to take a holistic approach to sustainability: fixing systems, not just throwing money at the same old problems and forcing developers to figure it all out themselves.

Should open source projects look like companies? Of course not. For one thing, a company is a business, and an open source project is a community, with very different goals and needs.

There is little support for functions that directly help code, like documentation or test automation. There is even less support for functions that indirectly help code, like community or evangelism.

In 2012, AKQA’s chief creative officer Rei Inamoto debuted a new wisdom at SXSW: “To run an efficient team, you only need three people: a Hipster, a Hacker, and a Hustler.” The startup trifecta was born.

When we think of open source’s influence on software, we tend to think about the legal implications. Open source made it acceptable to share, use and modify software freely.But open source changed how software companies build proprietary products, too. That open source principles are being used to develop closed source software speaks volumes about its cultural legacy.

Last year, O’Reilly Media went so far as to coin the term InnerSource to characterize this phenomenon:Inspired by the spread of open source software throughout the areas of operating systems, cloud computing, JavaScript frameworks, and elsewhere, a number of companies are mimicking the practices of the powerful open source movement to create an internal company collaboration under the rubric InnerSource.

Git, the version control system released in 2005, made those processes even easier.

The rise of agile coincided with the rise of startups using open source projects. At first, startups just incorporated those projects into their own software. But like any cultural exchange, open source began to affect how startups built products, too.

Corporate practices can be directly hostile to individuals with exceptional skills and initiative in technical matters. I consider such management of technical people cruel and wasteful. Kierkegaard was a strong proponent for the individual against “the crowd” and has some serious discussion of the importance of aesthetics and ethical behavior. I couldn’t point to a specific language feature and say, “See, there’s the influence of the nineteenth-century philosopher,” but he is one of the roots of my reluctance to eliminate “expert level” features, to abolish “misuses,” and to limit features to support only uses that I know to be useful. I’m not particularly fond of Kierkegaard’s religious philosophy, though.

TR: How do you account for the fact that C++ is both widely criticized and resented by many programmers but at the same time very broadly used? Why is it so successful?BS: The glib answer is, There are just two kinds of languages: the ones everybody complains about and the ones nobody uses.There are more useful systems developed in languages deemed awful than in languages praised for being beautiful–many more. The purpose of a programming language is to help build good systems, where “good” can be defined in many ways. My brief definition is, correct, maintainable, and adequately fast. Aesthetics matter, but first and foremost a language must be useful; it must allow real-world programmers to express real-world ideas succinctly and affordably.

TR: In retrospect, in designing C++, wasn’t your decision to trade off programmer efficiency, security, and software reliability for run time performance a fundamental mistake?BS: Well, I don’t think I made such a trade-off. I want elegant and efficient code. Sometimes I get it. These dichotomies (between efficiency versus correctness, efficiency versus programmer time, efficiency versus high-level, et cetera.) are bogus.What I did do was to design C++ as first of all a systems programming language: I wanted to be able to write device drivers, embedded systems, and other code that needed to use hardware directly. Next, I wanted C++ to be a good language for designing tools. That required flexibility and performance, but also the ability to express elegant interfaces.

And without real changes in user behavior, software suppliers are unlikely to change.

People reward developers who deliver software that is cheap, buggy, and first. That’s because people want fancy new gadgets now.

Software developers have become adept at the difficult art of building reasonably reliable systems out of unreliable parts. The snag is that often we do not know exactly how we did it: a system just “sort of evolved” into something minimally acceptable. Personally, I prefer to know when a system will work, and why it will.

You couldn’t charge people to use Python, for example, any more than you could charge someone to speak English.

What did it mean for a project not to be venture backable? Likely, it met one of the following criteria:There was no business model (ex. no customers to charge, or no advertising model)The project was not structured as a C corpThe project could not conceivably return an investment at venture scale

YCombinator funds nonprofits and now, research. OATV launched indie.vc last year. Peter Thiel created Breakout Labs. Elon Musk created Open AI.

serveStatic: '/static' from: '/var/www/htdocs'

GET: '/divide/<a>/<b>' -> [ :req | (req at: #a) / (req at: #b)];

My hope is that the book I’ve written gives people the courage to realize that this isn’t really about math at all, it’s about power.

n a study cited by the Swiss group last month, researchers found Twitter data alone a more reliable predictor of heart disease than all standard health and socioeconomic measures combined.

Empirically, I trace how civic hackathons in Los Angeles evolved in 2013 - 2015 from engineering exercises to spectacles where civic futures of technology were performed through communication, before turning to particular lessons drawn from civic hackathons. Civic hackathons’ emergence from technical cultures means they often produce conservative civic visions. I pay close attention to moments of failure – moments when possible technologies reproduced existing cultural divisions. Still, I resist describing them as completely co-opted and useless, as I found surprising moments of civic learning and exploration.

This bold claim has led design and critical scholars to hotly debate if participants have a technological ideology imposed on them, or if thinking with technologies enable new civic perspectives.

Winners were praised by sponsors and rewarded with invitations to be part of an accelerator or incubator. Stories from the day generated ample traffic on social media and articles in local newspapers.

Cooperation without coordination can propel democracy to the next level, but it will be met with so much resistance by those currently in power.

EA principles can work in areas outside of global poverty. He was growing the movement the way it ought to be grown, in a way that can attract activists with different core principles rather than alienating them.

Effective altruism is not a replacement for movements through which marginalized peoples seek their own liberationAnd you have to do meta-charity well — and the more EA grows obsessed with AI, the harder it is to do that. The movement has a very real demographic problem, which contributes to very real intellectual blinders of the kind that give rise to the AI obsession. And it's hard to imagine that yoking EA to one of the whitest and most male fields (tech) and academic subjects (computer science) will do much to bring more people from diverse backgrounds into the fold.

But ultimately you have to stop being meta. As Jeff Kaufman — a developer in Cambridge who's famous among effective altruists for, along with his wife Julia Wise, donating half their household's income to effective charities — argued in a talk about why global poverty should be a major focus, if you take meta-charity too far, you get a movement that's really good at expanding itself but not necessarily good at actually helping people.

The other problem is that the AI crowd seems to be assuming that people who might exist in the future should be counted equally to people who definitely exist today. That's by no means an obvious position, and tons of philosophers dispute it. Among other things, it implies what's known as the Repugnant Conclusion: the idea that the world should keep increasing its population until the absolutely maximum number of humans are alive, living lives that are just barely worth living. But if you say that people who only might exist count less than people who really do or really will exist, you avoid that conclusion, and the case for caring only about the far future becomes considerably weaker

The problem is that you could use this logic to defend just about anything. Imagine that a wizard showed up and said, "Humans are about to go extinct unless you give me $10 to cast a magical spell." Even if you only think there's a, say, 0.00000000000000001 percent chance that he's right, you should still, under this reasoning, give him the $10, because the expected value is that you're saving 10^32 lives.

At one point, Russell set about rebutting AI researcher Andrew Ng's comment that worrying about AI risk is like "worrying about overpopulation on Mars," countering, "Imagine if the world's governments and universities and corporations were spending billions on a plan to populate Mars." Musk looked up bashfully, put his hand on his chin, and smirked, as if to ask, "Who says I'm not?"

The second reason for avoiding the GPL is that it does not work well in the context of systems which embed their own code in documents. Programs such as GCC avoid this by having specific exemptions for the embedded code, but it is not possible for us to add this exemption to code taken from elsewhere. This is a problem, since a document in an object-oriented environment is a collection of objects, and objects are a combination of code and data. This could lead to the documents becoming accidentally GPL'd.

But despair is not useful. Despair is paralysis, and there’s work to be done. I feel that this is an essential psychological problem to be solved, and one that I’ve never seen mentioned: How do we create the conditions under which scientists and engineers can do great creative work without succumbing to despair? And how can new people be encouraged to take up the problem, when their instinct is to turn away and work on something that lets them sleep at night?

“It’s more complicated than that.” No kidding. You could nail a list of caveats to any sentence in this essay. But the complexity of these problems is no excuse for inaction. It’s an invitation to read more, learn more, come to understand the situation, figure out what you can build, and go build it. That’s why this essay has 400 hyperlinks. It’s meant as a jumping-off point. Jump off it. There’s one overarching caveat. This essay employed the rhetoric of “problem-solving” throughout. I was trained as an engineer; engineers solve problems. But, at least for the next century, the “problem” of climate change will not be “solved” — it can only be “managed”. This is a long game. One more reason to be thinking about tools, infrastructure, and foundations. The next generation has some hard work ahead of them.

If we must be gods, we should at least be cautious and well-informed gods, with the best possible tools for seeing, understanding, and debating our interventions, and the best possible meta-tools for improving those tools.

A commitment to sourcing every fact is laudible, of course. What’s missing is an understanding of citing and publishing models, not just the data derived from those models. This is a new problem — older media couldn’t generate data on their own. Authors will need to figure out journalistic standards around model citation, and readers will need to become literate in how to “read” a model and understand its limitations.

Imagine an authoring tool designed for arguing from evidence. I don’t mean merely juxtaposing a document and reference material, but literally “autocompleting” sourced facts directly into the document. Perhaps the tool would have built-in connections to fact databases and model repositories, not unlike the built-in spelling dictionary. What if it were as easy to insert facts, data, and models as it is to insert emoji and cat photos?

The importance of models may need to be underscored in this age of “big data” and “data mining”. Data, no matter how big, can only tell you what happened in the past. Unless you’re a historian, you actually care about the future — what will happen, what could happen, what would happen if you did this or that. Exploring these questions will always require models. Let’s get over “big data” — it’s time for “big modeling”.

Readers are thus encouraged to examine and critique the model. If they disagree, they can modify it into a competing model with their own preferred assumptions, and use it to argue for their position. Model-driven material can be used as grounds for an informed debate about assumptions and tradeoffs. Modeling leads naturally from the particular to the general. Instead of seeing an individual proposal as “right or wrong”, “bad or good”, people can see it as one point in a large space of possibilities. By exploring the model, they come to understand the landscape of that space, and are in a position to invent better ideas for all the proposals to come. Model-driven material can serve as a kind of enhanced imagination.

The success of Arduino has had the perhaps retrograde effect of convincing an entire generation that the way to sense and actuate the physical world is through imperative method calls in C++, shuffling bits and writing to ports, instead of in an environment designed around signal processing, control theory, and rapid and visible exploration. As a result, software engineers find a fluid, responsive programming experience on the screen, and a crude and clumsy programming experience in the world.

But the idea that you might implement a control system in an environment designed for designing control systems — it hasn’t been part of the thinking. This leads to long feedback loops, inflexible designs, and guesswork engineering. But most critically, it denies engineers the sort of exploratory environment that fosters novel ideas.

This pejorative reflects a peculiar geocentrism of the programming language community, whose “general-purpose languages” such as Java and Python are in fact very much domain-specific — specific to the domain of software development.

The Gamma: Programming tools for data journalism

I say this despite the fact that my own work has been in much the opposite direction as Julia. Julia inherits the textual interaction of classic Matlab, SciPy and other children of the teletype — source code and command lines.

If efficiency incentives and tools have been effective for utilities, manufacturers, and designers, what about for end users? One concern I’ve always had is that most people have no idea where their energy goes, so any attempt to conserve is like optimizing a program without a profiler.

It’s TCP/IP for energy. Think of these algorithms as hybrids of distributed networking protocols and financial trading algorithms — they are routing energy as well as participating in a market.

The catalyst for such a scale-up will necessarily be political. But even with political will, it can’t happen without technology that’s capable of scaling, and economically viable at scale. As technologists, that’s where we come in.

This is aimed at people in the tech industry, and is more about what you can do with your career than at a hackathon. I’m not going to discuss policy and regulation, although they’re no less important than technological innovation. A good way to think about it, via Saul Griffith, is that it’s the role of technologists to create options for policy-makers.

Any gentrification process inevitably presents two options. Do you abandon the form, leave it to the yuppies and head to the next wild frontier? Or do you attempt to break the cycle, deface the estate-agent signs, and picket outside the wine bar with placards reading ‘Yuppies Go Home’?

I thought was anonymised, but, two or three months later, I was able to de-anonymise it. 

This happened with crowdflow.net, a project about the consolidated.db, the database that records all of your movements on iPhones, that was backed-up unencrypted on PCs and Macs.

Also, the more complex a software project becomes, the more work you have to put into and it grows exponentially. So, keep it simple and make it fast. It's much easier to write software, throw it away and start over again quickly, than having this huge generic system that tries to do everything. It doesn't make sense. It's just too much work. You'd get this huge software system with thousand dependencies and, in the end, it's really hard to innovate, get new stuff in there, or, the worst case, to change the concept. Almost every software that we have published is not generic but is used only for one case. So, keep it simple and get a prototype in under three days.

What type of team do you need to create these visualisations? 
OpenDataCity has a special team of really high-level nerds. Experts on hardware, servers, software development, web design, user experience and so on. I contribute the more mathematical view on the data. But usually a project is done by just one person, who is chief and developer, and the others help him or her. So, it's not like a group project. Usually, it's a single person and a lot of help. That makes it definitely faster, than having a big team and a lot of meetings.

Can you avoid metadata? No, not at all. Sorry, not at all, anymore. I think you can even generate more metadata from existing data. Just think about living near a sightseeing building or something like that, how many tourists took holiday pictures and published them on Facebook. How many of these pictures contains your face? Then, one day, somebody will create a facial recognition algorithm and gather even more metadata about you.

In Pharo, how you meta-click depends on your operating system: either you must hold Shift-Ctrl or Shift-Alt (on Windows or Linux)

Every graphic element of Pharo that you click on...  - With Cmd+Shift+Option,  - you'll get a little menu around the graphic element.

Gemma Hersh, Policy Director at Elsevier explained that “pricing correlates to impact factor." When asked why costs were so high, Hersh stressed that “publishers do not operate a cost based system, [...] we operate a value-based system which reflects the value that we provide."

The essay competition will run until June 15th and will be judged by a committee of scientists, librarians, members of industry, and students based on the following criteria. 

One last piece of advice before beginning your journey: do no try to build any complex visualization in Roassal without first reading the builder infrastructure. Builders may ease your life!

RTLabelled

path := '/Users/alexandrebergel/Documents'. allFilesUnderPath := path asFileReference allChildren. b := RTMondrian new. b shape circle color: Color gray trans; if: [ :aFile | aFile path basename endsWith: '.pdf' ] color: Color red trans. b nodes: allFilesUnderPath. b edges connectFrom: #parent. b normalizer normalizeSize: #size min: 10 max: 150 using: #sqrt. b layout cluster. b

Research stage 1. Case selections and contextualisation of probes by country-leads will be reviewed jointly. Following a state-of-the-art country overview that will gather key insights for the selected case-study and its macro-context, country level workshops will be convened to firm up data-collection plans.

2. broader civil society changes such as emergence of new democratic movements, new citizen-led collaborations.

engagement platform/space, its communications and data architecture (including algorithms) using web-analytics and qualitative methods

A case study methodology has been selected as it is the most appropriate for abstracting broad theoretical insights from specific contextual experiences12. Across eight countries in Asia, Africa, South America and Europe, one case study per country in the area of ICT-mediated citizen engagement will be investigated in depth.

covering dimensions of voice and participation, transparency and accountability, rule of law, equity and inclusion and gender equality to create a tentative index, to be tested by the findings of this study.

The analytical framework will map the shifts along these two categories both from the 'government-end' and 'citizen-end', distilling citizen engagement in emergent meanings, norms and powers. It will also probe tensions – between voice, which may translate as noise on ICT channels, and deliberation that can, without the corresponding right to be heard, end up as discourse dissipation.

Statement of Research Building from empirical specifics of eight case studies from various countries, which will be chosen keeping in mind contextual diversity and institutional maturity, this study will use an analytical framework to address the following questions;RQ1: How do processes of signification, legitimation and domination in ICT-mediated citizen engagement give rise to new governance regimes?RQ2: Under what conditions can ICT mediated citizen engagement support and promote democratic governance?In addition, the study will attempt to develop an index on Transformative Citizen Engagement to evaluate the impact of citizen engagement on democratic governance, testing its efficacy. It will attempt to explain changes to governance systems and develop a layered index (tentatively, Transformative Citizen Engagement Index) that will be tested to evaluate the impact of citizen engagement on democratic governance.

If we do not scrutinise these questions we risk being left with, for example, data without users or analysis without action. Information about tax evasion is toothless without having institutions who are adequately resourced to tackle it. If civil society groups are to stand a chance of effectively counter-balancing corporate influence on political decision-making, they must be equipped with the capacities and legal mechanisms - not just the information - which will enable them to do so.

The paradox, of course, is that Google’s intense data collection and number crunching have led it to the same conclusions that good managers have always known. In the best teams, members listen to one another and show sensitivity to feelings and needs.

However, establishing psychological safety is, by its very nature, somewhat messy and difficult to implement. You can tell people to take turns during a conversation and to listen to one another more. You can instruct employees to be sensitive to how their colleagues feel and to notice when someone seems upset. But the kinds of people who work at Google are often the ones who became software engineers because they wanted to avoid talking about feelings in the first place.

Within psychology, researchers sometimes colloquially refer to traits like ‘‘conversational turn-taking’’ and ‘‘average social sensitivity’’ as aspects of what’s known as psychological safety — a group culture that the Harvard Business School professor Amy Edmondson defines as a ‘‘shared belief held by members of a team that the team is safe for interpersonal risk-taking.’’ Psychological safety is ‘‘a sense of confidence that the team will not embarrass, reject or punish someone for speaking up,’’ Edmondson wrote in a study published in 1999. ‘‘It describes a team climate characterized by interpersonal trust and mutual respect in which people are comfortable being themselves.’’

the good teams all had high ‘‘average social sensitivity’’ — a fancy way of saying they were skilled at intuiting how others felt based on their tone of voice, their expressions and other nonverbal cues. One of the easiest ways to gauge social sensitivity is to show someone photos of people’s eyes and ask him or her to describe what the people are thinking or feeling — an exam known as the Reading the Mind in the Eyes test. People on the more successful teams in Woolley’s experiment scored above average on the Reading the Mind in the Eyes test. They seemed to know when someone was feeling upset or left out. People on the ineffective teams, in contrast, scored below average. They seemed, as a group, to have less sensitivity toward their colleagues.

First, on the good teams, members spoke in roughly the same proportion, a phenomenon the researchers referred to as ‘‘equality in distribution of conversational turn-taking.’’ On some teams, everyone spoke during each task; on others, leadership shifted among teammates from assignment to assignment. But in each case, by the end of the day, everyone had spoken roughly the same amount. ‘‘As long as everyone got a chance to talk, the team did well,’’ Woolley said. ‘‘But if only one person or a small group spoke all the time, the collective intelligence declined.’’

The researchers eventually concluded that what distinguished the ‘‘good’’ teams from the dysfunctional groups was how teammates treated one another. The right norms, in other words, could raise a group’s collective intelligence, whereas the wrong norms could hobble a team, even if, individually, all the members were exceptionally bright.

When pursuing the Early Adopters, don't spend time putting in features that only the Conservatives care about.

So you have to treat them like they are very special.  Give them everything they want, almost as if they were ordering a custom application.  You may have to implement special features just for them.  You may have to give them substantial discounts.  You should visit their site and meet them in person.  You may have to install your product for them. 

But mature languages can't change easily if at all. This situation is described in theory of frozen evolution. Basically the evolution of language is similar of the evolution of a new specie. Evolution happens in short burst when the new language(specie) is created. In this period language design is plastic, there are few if any users, little amount of code and libraries and the community consists of enthusiasts. This short period of plasticity is fallowed by a long period of stability. The evolution of the language is frozen. There are few tweaks here and there but nothing radical. And nobody , not even the original creator could change that.

Clojure has no chance to dislodge Java as premier language for writing enterprise applications, but it could win as the language for writing concurrent applications. That is Clojure platform.

In order to successfully cross the chasm you need a pragmatist in pain.

Lisp isn’t a language, it’s a building material. Alan Kay

In my professional career I’ve noticed that doing “The Right Thing” is not always the best path. That phenomenon is called The Rise of “Worse is Better” and it can be observed in many things including C, Unix, Windows, JavaScript… Seems like New Jersey approach wins out more than it looses in a real world. (Be a virus, spread and than the pressure will rise to better the game).

And then Git happened. Git is so amazingly simple to use that APress, a single publisher, needs to have three different books on how to use it. It’s so simple that Atlassian and GitHub both felt a need to write their own online tutorials to try to clarify the main Git tutorial on the actual Git website. It’s so transparent that developers routinely tell me that the easiest way to learn Git is to start with its file formats and work up to the commands.