Update 12/31 1:30pm PT: WE DID IT!! Nearly 100 of you donated over $8,500.00 and another donor has offered the difference needed to match Sumana’s $15k. Thank you so much everyone! We’re looking forward to an amazing 2015.
Update 12/26 5pm: We’re at 25% of our goal! Not bad, but still a ways to go. Take a moment to pitch in a few bucks?
I moved to Portland from San Francisco in the Fall of 2007. I decided to move here after only two or three visits (all in the late Summer) on nothing more than a strong intuition that it was the place I needed to be. That intuition turned out to be right and Portland has ended up being the place where I put down roots, where I’ve grown up to be an adult, and where I feel most connected to and supported by others.
There are a lot of reasons why Portland ended up playing this role in my life, chief among them being the awesome local tech community.
I first got involved with the tech community by attending user groups. Because so many groups were hosted at Cubespace at that time, I was able to drop in on other groups and meet many folks. At some point I started volunteering, first for BarCamp, then Ignite (or was it the other way around?) Next I volunteered for a significant role at Open Source Bridge, which also provided my first conference speaking opportunity,
My career developed in lockstep with my involvement in the Portland tech community. I’ve grown as a programmer and technologist because through the community I’ve had access to skilled peers and mentors. Every job I have gotten since I moving here, including my current one at Mozilla, I’ve gotten because of someone I had a relationship with through the community. Being involved with the tech community has given me opportunities to practice and develop leadership skills, which continues to benefit both my professional and my personal life. I can honestly say I’m a better, more responsible person because of my involvement in Portland tech. Lastly, and most importantly, I’ve made my closest and dearest friends through the community and my work in it.
These are the personal reasons why I was motivated four years ago to co-found the Stumptown Syndicate with Reid Beels and Audrey Eschright. They are the reasons why I continue today to give so much of my free time as a Director of the Syndicate. I believe in Portland tech and its ability to support and empower individuals and make their lives better.
I’m proud of the work we’ve done over the last four years. Highlights include:
Bootstrapping a non-profit organization and successfully applying for 501(c)(3) status.
Hosting four successful Open Source Bridge events, three BarCamps, four WhereCamps, and a handful of IgnitePortland events. All of these events are free to attendees, or in the case of Open Source Bridge, have the option of volunteering in exchange for free attendance. The value of these events lies in the community connection they allow and the resulting personal and professional growth opportunities.
Creating the Citizen Code of Conduct and adopting it for all of our events. The CCoC has been adapted and adopted by many other events as well.
Increasing the speaker diversity of Open Source Bridge. In 2014, we accepted 50% woman speakers and 20% non-White speakers.
Hosting and guiding development on open source projects OpenConferenceWare and Calagator.
Stumptown Syndicate is almost entirely volunteer-run. None of the Board members, including myself, is paid and we all have full- or near-full-time jobs elsewhere. We don’t have an Executive Director or any other staff. We rely on the generosity and dedication of participants, volunteers and other community members in order to do our work.
That’s why our end-of-year fundraising campaign is so important. If we are able to fully match Sumana’s $15k contribution, we’ll start the year off with an additional $30k in the bank. This is huge for our tiny organization which operates on an average of $110k a year. $30k represents an additional 27% operating capital to us! With this money we can establish a travel fund so that we can bring more high-quality, diverse speakers to Open Source Bridge and other events. With this money we can start saving for our very own community space. With this money we could host a full BarCamp event at the Eliot Center again. With this money we can host more Calagator code sprints. With this money we can hire the resources needed to post audio and video from Open Source Bridge faster than 6 months after the conference. With this money we can provide childcare at more of our events. With this money we can add captioning and/or transcripts to Open Source Bridge talks.
All that’s needed for us to earn this $30k and have it be available to us is for you all to contribute half of it. $15k may sound like a lot, but it’s totally doable. Look at it this way, if everyone who’s ever attended one of our events gave $10, we’d blow right past the goal.
So, please, if you’ve been to one of our events and it’s meant something to you, donate.
If you want to see more awesome community-led, volunteer-run activities, donate.
Most of you reading this probably have $10 to spare. Some of you significantly more than that. If you can give 5 bucks, please do so. Those of you who can swing $100 please do so.
With every dollar you give you let us know that our work matters to you. It’s a vote of confidence as well as a resource we can use to do even more for you.
Stumptown Syndicate is a 501(c)(3) non-profit and so your donations are tax-deductible in the US.
Have you already given or are you about to? Many employers will match your donations to 501(c)(3) dollar-for-dollar. Make your donation count for three times as much by asking your employer if they offer this. (OPB has an extensive list of employers with matching programs.)
This week we celebrate another birthday: MozillaWiki turns 10 on Wednesday, 18 November!
I’m immensely proud of our wiki, its ten year history, and of all the work Mozillians do to make MozillaWiki a hub of collaboration and a living memory for the Mozilla Project.
To show our appreciation for your efforts over the last decade, the MozillaWiki team has created a 10th Birthday badge.
All you need to do to join in the celebration and claim the badge is log in to MozillaWiki. Once you’ve done that, you’ll see a link to claim the badge at the top of the page. Don’t have a MozillaWiki account? No worries! Create one during this Birthday celebration and you can claim the badge too.
A bit of MozillaWiki history
Before I talk about all the good work we’ve done, and what we have planned for the remainder of this year and beyond, let’s take a quick stroll through the last 10 years. Thank you Internet Archive for hosting these snapshots of the wiki!
The earliest snapshot I could find of the domain wiki.mozilla.org was from July 2004. It looks like we were hosting separate wiki installations, which may or may not have been Mediawiki.
According to WikiApiary, the current installation of MozillaWiki was created on 18 November 2004. The closest snapshot to this date in the Internet Archive is 11 December 2004:
By April 2005, the wiki had been upgraded, had a new theme (Cavendish), and had started using Apache rewrite rules to make the url pretty (e.g. no index.php).
Three years later, in April 2008, we were still rockin’ the Cavendish theme and the Main Page had some more content, including links to the weekly project call that continues to this day.
In May 2011, after 6 years of service, Cavendish was retired as the default skin and replaced with GMO.
A year later, July 2012, MozillaWiki looked much the same.
By July 2013, the Main Page was edited to include a few recent changes, but otherwise looked very similar.
By August 2014, the revitalization of the MozillaWiki was in full swing and we were preparing for a major update to both the skin (GMO to Vector) as well as the underlying software (Mediawiki 1.19 to 1.23). We also had made significant changes to the content of the Main Page based on results of our recent user survey.
Here’s what the wiki looks like today, 17 November, the day before it’s birthday. We’re running a slightly modified Vector skin and Mediawiki 1.23.x branch.
Pages, visitors and accounts
As of 16 November, MozillaWiki has 115,912 pages, all public, and nearly 10k uploaded files. About 630 people per month, on average, log in and make contributions to the wiki. These include both staff and volunteers. Want to track these stats yourself? Visit Special:Statistics.
The number of daily visitors ranges from 9k-30k, with an average likely around 13-14k. Who are these visitors? According our analytics software we get visitors from all over the world, with the greatest concentration being from the US, Canada and UK.
The wiki has over 330,000 registered user accounts. I estimate that about 300k of these are inactive spam accounts, so the real number for user accounts is probably closer to 30,000.
What kinda of content is hosted on MozillaWiki?
All kinds of project activity is coordinated and recorded on the wiki. This includes activity related to our products: Firefox, Firefox OS, WebMaker, etc. It also includes community activities such as Reps, Firefox Student Ambassadors, etc. Most project activities have some representation on MozillaWiki. People also use the wiki to track projects and goals on an individual level. In this regard, it served as a place for Mozillians’ profiles long before we had mozillians.org.
The MozillaWiki isn’t setup for localized content now, but this hasn’t stopped our localized community from translating content. Every day a significant portion of account requests come from volunteers from regional communities and are often in a language other than English. In 2015, depending on resources available, we plan to significantly improve support for localized content on MozillaWiki.
This year we’ve made significant progress towards revitalizing MozillaWiki.
Forming a team of dedicated volunteers to lead a revitalization effort.
Creating an About page for MozillaWiki that clarifies its scope and role in the project, including what is appropriate content and how to report issues.
Fixing years-old bugs that cause significant usability problems (table sorting, unavailability of Wikieditor, etc.).
Identifying a product owner for MozillaWiki and creating a Module for it, lead by a mix of staff and contributors.
Halting the creation of new spam and cleaning up significant amounts of spam content.
Upgrading Mediawiki from 1.19.x branch to 1.23.x branch AND changing the default theme without any significant downtime or disruptions to users.
If you’d like to help us organize those opportunities, or have other ideas for improving the wiki, join one of our MozillaWiki Team communication channels or one of our community meetings. These meetings are held twice a month on Tuesday at 8:30 PST / 15:30 UTC. Our next meeting is 16 December. All who are interested in contributing to the wiki are welcome.
In the meantime, log in to MozillaWiki and celebrate its birthday with us by claiming the birthday badge!
I’ve put this explanation together for those who want to understand the Heartbleed bug, how it fits into the bigger picture of secure internet browsing, and what you can do to mitigate its affects.
HTTPS vs HTTP (padlock vs no padlock)
When you are browsing a site securely, you use https and you see a padlock icon in the url bar. When you are browsing insecurely you use http and you do not see a padlock icon.
HTTPS relies on something called SSL/TLS.
SSL stands for Secure Sockets Layer and TLS stands for Transport Layer Security. TLS is the later version of the original, proprietary, SSL protocol developed by Netscape. Today, when people say SSL, they generally mean TLS, the current, standard version of the protocol.
Public and private keys
The TLS protocol relies heavily on public-key or asymmetric cryptography. In this kind of cryptography, two separate but paired keys are required: a public key and a private key. The public key is, as its name suggests, shared with the world and is used to encrypt plain-text data or to verify a digital signature. (A digital signature is a way to authenticate identity.) A matching private key, on the other hand, is used to decrypt data and to generate digital signatures. A private key should be safeguarded and never shared. Many private keys are protected by pass-phrases, but merely having access to the private key means you can likely use it.
Authentication and encryption
The purpose of SSL/TLS is to authenticate and encrypt web traffic.
Authenticate in this case means “verify that I am who I say I am.” This is very important because when you visit your bank’s website in your browser, you want to feel confident that you are visiting the web servers of — and thereby giving your information to — your actual bank and not another server claiming to be your bank. This authentication is achieved using something called certificates that are issued by Certificate Authorities (CA). Wikipedia explains thusly:
The digital certificate certifies the ownership of a public key by the named subject of the certificate. This allows others (relying parties) to rely upon signatures or assertions made by the private key that corresponds to the public key that is certified. In this model of trust relationships, a CA is a trusted third party that is trusted by both the subject (owner) of the certificate and the party relying upon the certificate.
In order to obtain a valid certificate from a CA, website owners must submit, at minimum, their server’s public key and demonstrate that they have access to the website (domain).
Encrypt in this case means “encode data such that only authorized parties may decode it.” Encrypting internet traffic is important for sensitive or otherwise private data because it is trivially easy eavesdrop on internet traffic. Information transmitted not using SSL is usually done so in plain-text and as such clearly readable by anyone. This might be acceptable for general internet broswing. After all, who cares who knows which NY Times article you are reading? But is not acceptable for a range of private data including user names, passwords and private messages.
Behind the scenes of an SSL/TLS connection
When you visit a website with HTTPs enabled, a multi-step process occurs so that a secure connection can be established. During this process, the sever and client (browser) send messages back and forth in order to a) authenticate the server’s (and sometimes the client’s) identity and, b) to negotiate what encryption scheme, including which cipher and which key, they will use for the session. Identities are authenticated using the digital certificates mentioned previously.
When all of that is complete, the secure connection is established and the server and client send traffic back and forth to each other.
All of this happens without you ever knowing about it. Once you see your bank’s login screen the process is complete, assuming you see the padlock icon in your browser’s url bar.
Keepalives and Heartbeats
Even though establishing an ssl connection happens almost imperceptibly to you, it does have an overhead in terms of computer and network resources. To minimize this overhead, network connections are often kept open and active until a given timeout threshold is exceed. When that happens, the connection is closed. If the client and server wish to communicate again, they need to re-negotiate the connection and re-incur the overhead of that negotiation.
One way to forestall a connection being closed is via keepalives. A keepalive message is used to tell a server “Hey, I know I haven’t used this connection in a little while, but I’m still here and I’m planning to use it again really soon.”
Keepalive functionality was added to the TLS protocol specification via the Heartbeat Extension. Instead of “Keepalives,” they’re called “Heartbeats,” but they do basically the same thing.
Specification vs Implementation
Let’s pause for a moment to talk about specifications vs implementations. A protocol is a defined way of doing something. In this case of TLS, that something is encrypted network communications. When a protocol is standardized, it means that a lot of people have agreed upon the exact way that protocol should work and this way is outlined in a specification.The specification for TLS is collaboratively developed, maintained and promoted by the standards body Internet Engineering Task Force (IETF). A specification in and of itself does not do anything. It is a set of documents, not a program. In order for a specifications to do something, they must be implemented by programmers.
OpenSSL implementation of TLS
OpenSSL is one implementation of the TLS protocol. There are others, including the open source GnuTLS as well as proprietary implementations. OpenSSL is a library, meaning that it is not a standalone software package, but one that is used by other software packages. These include the very popular webserver Apache.
The Heartbleed bug only applies to webservers with SSL/TLS enabled, and only those using specific versions of the open source OpenSSL library because the bug relates to an error in the code of that library, specifically the heartbeat extension code. It is not related to any errors in the TLS specification or and in any of the underlying ciper suites.
Usually this would be good news. However, because OpenSSL is so widely used, particularly the affected version, this simple bug has tremendously reach in terms of the number of servers and therefor the number of users it potentially affects.
What the heartbeat extension is supposed to do
The heartbeat extension is supposed to work as follows:
A client sends a heartbeat message to the server.
The message contains two pieces of data: a payload and the size of that payload. The payload can by anything up to 64kb.
When the server receives the heartbeat message, it is to add a bit of extra data to it (padding) and send it right back to the client.
Pretty simple, right? Heartbeat isn’t supposed to do anything other than let the server and client know they are each still there and accepting connections.
What the heartbeat code actually does
In the code for affected versions (1.0.1-1.0.1f) of the OpenSSL heartbeat extension, the programmer(s) made a simple but horrible mistake: They failed to verify the size of the received payload. Instead, they accepted what the client said was the size of the payload and returned this amount of data from memory, thinking it should be returning the same data it had received. Therefore, a client could send a payload of 1KB, say it was 64KB and receive that amount of data back, all from server memory.
If that’s confusing, try this analogy: Imagine you are my bank. I show up and make a deposit. I say the deposit is $64, but you don’t actually verify this amount. Moments later I request a withdrawal of the $64 I say I deposited. In fact, I really only deposited $1, but since you never checked, you have no choice but to give me $64, $63 of which doesn’t actually belong to me.
And, this is exactly how a someone could exploit this vulnerability. What comes back from memory doesn’t belong to the client that sent the heartbeat message, but it’s given a copy of it anyway. The data returned is random, but would be data that the OpenSSL library had been storing in memory. This should be pre-encryption (plain-text) data, including your user names and passwords. It could also technically be your server’s private key (because that is used in the securing process) and/or your server’s certificate (which is also not something you should share).
The ability to retrieve a server’s private key is very bad because that private key could be used to decrypt all past, present and future traffic to the sever. The ability to retreive a server’s certificate is also bad because it gives the ability to impersonate that server.
This, coupled with the widespread use of OpenSSL, is why this bug is so terribly bad. Oh, and it gets worse…
Taking advantage of this vulnerability leaves no trace
What’s worse is that logging isn’t part of the Heartbeat extension. Why would it be? Keepalives happen all the time and generally do not represent transmission of any significant data. There’s no reason to take up value time accessing the physical disk or taking up storage space to record that kind of information.
Because there is no logging, there is no trace left when someone takes advantage of this vulnerability.
The code that introduced this bug has been part of OpenSSl for 2+ years. This means that any data you’ve communicated to servers with this bug since then has the potential to be compromised, but there’s no way to determine definitively if it was.
This is why most of the internet is collectively freaking out.
What do server administrators need to do?
Server (website) administrators need to, if they haven’t already:
Determine whether or not their systems are affected by the bug. (test)
Patch and/or upgrade affected systems. (This will require a restart)
Revoke and reissue keys and certificates for affected systems.
Furthermore, I strongly recommend you enable Perfect forward secrecy to safeguard data in the event that a private key is compromised:
When an encrypted connection uses perfect forward secrecy, that means that the session keys the server generates are truly ephemeral, and even somebody with access to the secret key can’t later derive the relevant session key that would allow her to decrypt any particular HTTPS session. So intercepted encrypted data is protected from prying eyes long into the future, even if the website’s secret key is later compromised.
What do users (like me) need to do?
The most important thing regular users need to do is change your passwords on critical sites that were vulnerable (but only after they’ve been patched). Do you need to change all of your passwords everywhere? Probably not. Read You don’t need to change all your passwords for some good tips.
Additionally, if you’re not already using a password manager, I highly recommend LastPass, which is cross-platform and works on pretty much every device. Yesterday LastPass announced they are helping users to know which passwords they need to update and when it is safe to do so.
As a single employee of Mozilla, I am not sure I can definitively determine Brendan’s suitability. I can, however, give insight as to what I experience at Mozilla as a queer woman and how I feel about the appointment.
Mozilla is a very unique organization in that it operates in a strange hybrid space between tech company and non-profit. There simply aren’t a lot of models for what we do. Wikimedia Foundation is always the one that comes closest to mind for me, but remains a very different thing. As such, people with experience relevant Mozilla, relevant enough to lead Mozilla well, are in very short supply. An organization can always choose to make an external hire and hope the person comes to understand the culture, but that is a risky bet. Internal candidates who have demonstrated they get the culture, the big picture of where we need to go and have demonstrated they can effectively lead large business units, on the other hand, present as very strong options.
And, from my limited vantage point, that’s what I see in Brendan.
Like a lot of people, I was disappointed when I found out that Brendan had donated to the anti-marriage equality Prop. 8 campaign in California. It’s hard for me to think of a scenario where someone could donate to that campaign without feeling that queer folks are less deserving of basic rights. It frustrates me when people use their economic power to further enshrine and institutionalize discrimination. (If you haven’t seen it, here’s Brendan’s response to the issue.)
However, during the intervening years, I’ve spent a lot of time navigating communities like Mozilla and figuring out how to get things done. I’ve learned that it’s hard working with people but that you have to do it anyway. I’ve learned that it can be even harder to work with someone when you think you don’t share your fundamental beliefs, or when you think they hold opposing or contradictory beliefs, but you have to do that sometimes, too.
The key is to figure out when it’s important to walk away from interacting with a person or community because of a mis-alignment in beliefs and when you need to set aside the disagreement and commit to working together in service of the shared goal. Context is really important here. What is the purpose or mission of the community? Who is its audience? What are its guiding principles?
Mozilla’s mission is “to promote openness, innovation & opportunity on the Web.” Our audience is the global community of people connecting to the internet. Our guiding principles are numerous, but include protecting the internet as a public resource and upholding user privacy, security and choice.
At the same time, many Mozillians are themselves advocates for human rights, animal rights, prison abolition, marriage equality, racial equality, etc. As much as some of those causes might overlap with the cause of a free and open internet, they are separate causes and none of them are the focus of Mozilla the organization. Focus is important because we live in a world of limited resources. Mozilla needs to stay focused on the mission we have all come together to support and move forward.
Another factor to consider: What is their behavior within the community, where we have agreed to come together and work towards a specific mission? How much does a person’s behavior outside the scope of community affect the community itself? Does the external behavior conflict directly with the core mission of the organization?
To be clear, I’m personally disappointed about Brendan’s donation. However, aside from how it affected me emotionally, I have nothing to indicate that it’s materially hurt my work within the Mozilla community or as a Mozilla employee. Mozilla offers the best benefits I have ever had and goes out of its way to offer benefits to its employees in same-sex marriages or domestic partnerships on par with those in heterosexual marriages. Last year we finally got trans-inclusive healthcare. We didn’t have an explicit code of conduct when I started, but adopted the guidelines for participation within my first year. Progress might be slow, but it’s being made. And I don’t see Brendan standing in the way of that.
Certainly it would be problematic if Brendan’s behavior within Mozilla was explicitly discriminatory, or implicitly so in the form of repeated microagressions. I haven’t personally seen this (although to be clear, I was not part of Brendan’s reporting structure until today). To the contrary, over the years I have watched Brendan be an ally in many areas and bring clarity and leadership when needed. Furthermore, I trust the oversight Mozilla has in place in the form of our chairperson, Mitchell Baker, and our board of directors.
It’s true there might be a kind of collateral damage from Brendan’s actions in the form of some people withdrawing from participation in Mozilla or never joining in the first place. There’s a lot I could say about people’s responses to things that happen at Mozilla, but I’ll save those for another time.
For now, I’ll just say that if you’re queer and don’t feel comfortable at Mozilla, that saddens me and I’m sorry. I understand where you’re coming from, at least in part, because I had a rocky start at Mozilla and often questioned my fit in the community. That’s why I’m putting considerable effort into changing how we interact with and support contributors from marginal groups. If you want to join me, look at what we’re doing with the Education Working Group and then get in touch.
To conclude, what I offer to my fellow Mozillians, including Brendan, is this:
I respect that you have a private life, including interactions in other communities, that may not match my beliefs or may even conflict with them.
I recognize that despite possible differences in our personal beliefs, you are just as committed as I am to Mozilla’s mission and have a lot to offer the community.
I agree, and ask you to do the same, to set aside those differences to create a shared space in which we can work together on the Mozilla mission.
In that space, we’ll treat each other as human beings, following the participation guidelines, even if doing so will stretch our skills and make us slightly uncomfortable.
We agree to communicate with honesty and empathy and to find ways to support each other’s work in the project.
Update 28 March 2014 8:30 PDT:
Since Monday, Brendan and Mitchell have both published responses, which I’ve included below. I’ve also included posts from some colleagues.
There are many privileges I have working at Mozilla. One of them is a decent amount of time off, by American standards. This year Mozilla continued the tradition of closing offices and halting business for the last two weeks of the year. Originally I had thought about getting some volunteer work done during the time off, but ended up just spending time with Sherri and our friends, puttering around the house and playing a lot of Skyrim. It’s difficult for me to disengage from my various responsibilities and truly allow myself time to relax and rest. I felt guilty the first two-thirds of this time off. Despite that, I did manage to have some good rest and in taking a break, I was able to think clearly about what I want out of the next year or so.
What I realized is that I’m ready for a shift. I haven’t been able to make the kind of progress I’d like on a few projects that are actually very important to me. There are some good reasons for this lack of progress. The past 18-24 months have been extremely chaotic on a personal level. Sherri and I became deeply involved in caring for her ailing mother. We lost a dear friend. We bought a house and moved.
I’m happy to say that a lot of that is behind us now. Sherri’s Mom is settled into assisted living and others are responsible for her care now. We aren’t planning to buy a house, move or have any major construction done. We also seem to have found medication regimine that is keeping my asthma somewhat under control. As a result, I’m sleeping better at night and can engage is more physical activity than I have been able to in quite some time.
With things on the home and personal fronts feeling more settled, there’s one remaining barrier to going deeper into my most important projects: having too many projects.
In a lot of ways we falsely operate on a model of scarcity. Lots of things aren’t actually scarce when we think they are. Time, however, truly is available in limited amounts. If I’m involved in ten projects, each one of them is going to get less time, on average, than if I’m involved in five. It sounds like a simple, obvious, statement. But, like possessions, it’s easy for us to accumulate projects and difficult to let them go.
There are a lot of reasons we hold on to our projects: No clear succession path, not wanting to say goodbye to the project itself or to something it provides for us, not wanting to feel like you’ve failed or that you’re letting someone down, the uncertainly of knowing what will take its place, habit. All of these represent valid needs we have and it’s important to honor those needs and the feelings that arise when thinking about not continuing to be involved in something.
Over the years I’ve cultivated a set of questions I ask myself to help navigate the process of identifying whether or not it’s time to let go of a project. These include:
If I stopped doing this project, what are things I could do with that time instead?
What other things I’m excited about have I been saying no to because I’m involved in this project?
Am I still learning things or otherwise growing as a person as a result of being involved in this project?
Is the project still evolving as a result of my involvement, or has it stagnated?
Are there ways to deescalate but still maintain some involvement that would be satisfying to me?
If I can’t identify a clear succession path for the project, what’s the worst that can happen?
If I think the worst case is that no one continues it, does that mean that the project had reached its natural end?
What are the ultimate goals of my project? That I want to be around for?
What do I envision the end of the project to be? What does it looks like when my project has accomplished its mission, achieved all its goals?
Generally, we spend a lot of energy on starting, building and sustaining projects and very little energy on defining a project’s end. No wonder we have trouble ending projects! Often we rely on external factors to drive decisions about endings. Work life becomes untenable so we quit, or we accept an offer elsewhere. Or we disengage from a project abruptly when some other issue in our lives becomes a higher priority and gives us permission to do so. I wonder if there’s a benefit to bringing additional mindfulness and intention to how we approach ending projects. This doesn’t mean mapping out a complete plan at the beginning of a project and then rigorously and stubbornly abiding by it, regardless of changing circumstances. Rather, I think it’s a useful strategy to periodically inventory what we’re working on, ask the above questions of each.
In asking myself the above questions about all my projects at the end of this year, I was able to arrive at a clear picture about which projects I’m okay letting go of, or decreasing my involvement in, and which new projects I’d like to take on.
The plan for 2014 is something like:
Organize fewer events. The main event that I plan to maintain my involvement in this year is Open Source Bridge. All others I either won’t be involved in, or will only be involved in an advisory role. Stepping back my event-planning role means that I’ll be able to devote more attention to my role as President of Stumptown Syndicate.
Submit no conference proposals. I’m not planning to do any speaking at conference unless specifically invited to do so. This frees up time to work on our Event Planning Handbook and accompanying workshop.
Spend less time on social media. I have a bad habit of treating social media like a sweet or a cigarette. Stuck on something? Check Twitter. Stressed about something? Check Twitter. There’s nothing inherently wrong with this. Stress relievers are good — as long as they are serving their purpose. However, social media tends to become a distraction and one that generates more stress than it relieves. Spending less time on Twitter/Facebook means I will have more time to engage in deeper conversation and nurture one-one-one connections. I’ll still use social media, but with intention and in time-constrained amounts.
What about you? What are some ways you figure out how to continue or end projects? What things are you planning to do less and/or more of this year?
Like a lot of folks who grew up in chaotic home environments, memories of my younger years are fragmented and hazy. I can’t say with certainty what our first computer was, or when exactly it arrived in our home. I remember both an Apple II and an IBM PC with an 8088 processor making appearances in the mid- to late-eighties. Both were second-hand. The IBM machine stuck around longer and was the one that I did the most exploring on. I can still vividly recall many evenings spent during my sixth grade year in front of the blue Wordperfect screen and clackity-clack keyboard typing essays. I also recall spending a lot of time online that year as we somehow managed to have a modem and a subscription to Prodigy.
Aside from really liking Wordperfect macro and formatting codes, I knew nothing yet of programming. That changed when my father came home with a used TRS-80, which I was allowed to have in my room. The computer must have come with a book on BASIC programming, because within a short while of having it, I was making simple programs. This was around 1991, when I was 10 or 11 years old. My first program was designed to help my mother figure out what to make us for dinner.
That initial rush of programming activity didn’t resume until a long while later. Family life was especially chaotic then. We weren’t doing well financially and shortly we relocated under some duress from the SF Bay Area to Sacramento. I don’t think the TRS-80 followed us, or at least I didn’t have access to it again.
The summer of 1992 was my first in Sacramento. It was especially long since my parents pulled us out of school early in order to move. I spent a lot of time riding my bike and exploring the neighborhood, somehow unaffected by Sacramento’s blazing summer heat (much hotter than my native Alameda). I also spent a lot of time inside, on the computer. At some point I decided to read the entire DOS 3.2 manual, the one with the spartan cyan-colored cover. I wanted to know everything I could about how our 8088 worked and what I could do with it. The manual included a section on BATCH programming which I totally loved.
Summer ends and I begin 8th grade, transferring schools after the first quarter so that I can participate in our district’s accelerated program. I am now bussed across town for school. The curriculum there is more challenging and interesting to me, but does not include any computer science and there is little time or support for it at home. I start high school, at a school that is very good but not in our neighborhood. I spend my entire freshman year being late to everything because my father is largely in charge of transportation. Fortunately we move to a house about a mile away from my school the summer before my sophomore year and I gain the ability to take myself to school (with my own two feet!).
Three significant “nerd” things happened during my sophomore year. The first was that I got my own computer again. As with the machines before it, a second-hand PC appeared without much explanation. Sometimes I wonder if these things were stolen or otherwise acquired under dubious circumstances, as was my father’s habit. In any case, this machine had an 8086 processor and CGA display. It ran DOS, probably version 4.0 and came install with PoliceQuest. I think I stayed up all night the first day I had it. The second thing that happened was that a I took the required computer literacy course and did so well I ended up helping the teacher run the class and being allowed to work on my own projects. This lead to the third things, which was to connect with the other students of my ilk who had quickly exceeded the basic computer skills curriculum and were allowed to work on other things. I actually ended up marrying one of the boys I met that year in computer lab (it didn’t work out in the long term).
Around this time I got very into using BBS (bulletin board systems; remember this was per-internet) and in learning how to build and upgrade computers. Friends whose families were better situated financially than ours would always find ways to give me their old components and they upgraded theirs. I’ve never forget the pure joy I experienced the day I upgraded from my 2400 baud modem to 14.4k (my friend had just upgraded to 56k). Glorious. Having the ability to connect to others via BBSes was incredibly important to me. In fact, I think it may have saved my life. The summer between my junior and senior years was very, very dark. I was allowed virtually no social interaction outside of my immediate family. I was depressed and lonely and so being able to connect with others in a meaningful way via technology was a godsend. Even during the period that my father prohibited me from using it, as punishment for some now forgotten transgression, I managed to do so by waiting for him to fall asleep, quietly secreting the equipment back into my room, using it all night and then returning it in the morning before he woke up.
I mention that last story because not only were my interests in computing not supported, but my interests were actively used against me at times as a form of punishment. I know I’m not alone in this. I’ve talked to lots of people whose parents saw any computer use as a waste of time and actively discouraged it under any circumstances.
Sometime during early high school I took my first programming class, during the summer. It was C programming at the local community college and I totally bombed it. It was the first coursework I’d ever encountered that I couldn’t understand right away and I had no idea how to ask for help. I didn’t even know asking for help was within the realm of possibility. All I felt was deep shame that I wasn’t automatically understanding the material and making progress. It might sound silly now, but keep in mind that this was before the internet, before Google and Stackoverflow and Youtube, before all of these resources were readily available. I didn’t have a readily accessible connection with anyone else who programmed. At some point I just stopped going to class. This early failure haunted me for a long, long time.
Other computing events from my high school years that I recall vividly: I introduced a virus onto our home PC. I don’t recall which one, or the exact results, but I recall my father being very angry and it’s probably what lead our family to get a newer PC (a 386!). I did the DOS-equivalent of ‘rm -rf’ in C:/ trying to free up disk space. Opps. I wish I could say that’s the first and last time I ever made that kind of mistake. And I played a lot of Nethack and Civilization. I spent a lot of time working on an Asteroids-like game written in BASIC.
During my junior year, I started taking classes at Sacramento State university as part of a program that allowed low-cost concurrent enrollment to high-school students. I took a computer fundamentals course that gave me my first shell account and internet access. It was awesome. This was 1996 and we used the Lynx web browser and learned about searching the world wide web. We also learned PINE mail and gopher and telnet and irc. It was my first exposure to Unix/Linux and Open Source and I loved it. It was also my first exposure to really shitty computing/internet-related legislation, for that was the year that we started hearing about the DMCA. The following year, among other course, I took an introduction to programming, this one taught in visual basic, and did incredibly well. So well, in fact, that I was all set to apply to colleges for Computer Engineering… until I fell in love with physics. AP Physics amazed me. I was able to use something I loved, calculus, to solve real-world programs. I applied to UC Davis as a Physics major and was accepted and awarded with a full Regents scholarship.
My early university years did not go well for me. The summer before starting university was a rocky one. As it turns out, undiagnosed and untreated ADD and PTSD is a particularly unproductive combination and made the already difficult task of navigating university on my own completely unmanageable. When I think back on it, as with so many of my early years, I’m amazed I made it through alive and relatively in tact. I have some very good friends to thank for that. UC Davis kicked me out for poor academic performance twice, and in order to return and complete my degree I was required to switch majors to something in the humanities school. I chose English Lit. I’ve always enjoyed reading and had recently discovered that, much to my surprise, I was capable of writing decently well. Somehow I was able to create enough stability in my life that I graduated with a decent academic record and even earned an ‘Outstanding Graduating Senior’ commendation.
Despite my academic struggles, I did managed to have some very valuable computing experience in college. For a time I worked in our NOC as a student systems administrator. I learned about a huge range of systems: Unisys mainframe, VMS VAX, Unix and Solaris and I used Unix daily via the terminal as well as KDE desktop. Later on I worked for a climate change research group and my duties there include Windows NT as well as Unix administration and even a bit of ColdFusion programming.
2002 turned out not to be the best year for a new grad to enter the job market (though there would be worse years to come). My graduation also coincided with my fathering being arrested for solicitation of murder. I floundered for a bit. After quitting my job at UC Davis that had started as a student position, I canvassed for Sierra Club and CalPIRG, went to Burning Man for the first time, worked at WebEx giving demos, got married hastily and then worked at my husband’s company writing technical documentation and leading product training.
In 2003 I moved back to the Bay Area. I found a job as a print production manager with a small technology marketing publisher based in San Fransisco. In many ways it was a really great job for me. I had a lot of autonomy and I was able to use my diverse skills to streamline the company’s existing publishing process. It was fast-paced and deadline-driven, which kept me focused. I was able to hire and manage two staff members. Looking back, one of the most important things I was able to do was learn PHP/MySQL and bring the website programming and server administration completely in house. My experience at that small publisher allowed me to get a job at a more prestigious agency at which I was able to pivot completely from print production work to full-time IT/programming. In 2007 I stopped working at the marketing agency so I could freelance . Later that same year I moved to Portland and immediately got involved in our awesome tech community by attending a Code ‘n’ Splode meeting.
For a while I regularly attended PHP meetups and then started volunteering for events like BarCamp Portland. Meanwhile, freelancing was starting to get old and I returned to salaried employed at a local agency. I stayed there for about a year and then went to work for a local e-commerce startup in 2010. I continued to hone my programming skills and switched to using desktop Linux full-time (from OSX). In 2012 started at Mozilla, working first within Webdev on the Web Productions team and now on Tech Evangelism.
I don’t consider myself a superstar programmer, nor do I aspire to that designation. I’m a well-rounded technologist. What I’m most interested in these days is finding ways to use technology to drive social change, to empower citizenship and to build better communities and relationships.
Trigger warning: Domestic violence and the legal system.
I spend a lot of time thinking about how I can help create and maintain safe, healthy and productive spaces for all, but particularly for those most at risk of further trauma.
And so when it becomes apparent that one member of the community has been engaging in partner violence against another, I take that very seriously.
What’s been made clear in the last week, however, is that our community has a lot to learn about domestic violence, how violence operates within communities, and how we can best support each other in working through these difficult issues.
I don’t claim to have all the answers, but I do know quite a bit about domestic violence, having several decades of personal experience with it. With that, I’d like to address some specific misconceptions I saw propagated over the last week.
Addressing common misconceptions
Courts do not determine what is true or real. They determine legal outcomes. The distinction is important.
Most often, a criminal court never adjudicates whether a person is guilty or not guilty. Whether or not a person is prosecuted for criminal charges is at the discretion of the state or local prosecutor. Prosecutors make these decisions based on a number of factors, including their estimate of how likely they are to achieve a conviction, as well as their own prejudices. The fact that State declines to prosecute criminal charges does not, in and of itself, confer innocence. It most certainly does not confer “exoneration” which can occur only after a previous conviction. Lack of prosecution, by definition, simply confers an absence of legal judgment.
Civil suits are entirely different. Citizens (not the state) can file cases upon one another for violating civil statues and courts decide these matters under a different set of guidelines and then award restitution, or not, depending on their findings. Civil cases are often more successful for plaintiffs than criminal ones because the burden of proof is less stringent. Quite often when a defendant is found not guilty in a criminal case they will be found guilty in the corresponding civil trial, thus providing some measure of accountability. Relying on civil cases as a means to support domestic abuse survivors is problematic because the financial burden of pursuing litigation and of enforcing any judgments lies almost entirely with the plaintiff.
In our country, the courts must operate on the presumption of innocence. Legal guilt or innocence is determined based on very specific procedures which take into account a limited set of facts and circumstances. Individuals and communities, by contrast, have the latitude to make decisions and take action based on a greater range of available information.
Because remaining silent about abusive behavior perpetuates and propagates it, communities can work to reverse this pattern by judiciously sharing information about those who have engaged in abusive behavior. Communities do not need a conviction in a court of law in order to be confident that abuse has occurred. It is sufficient for communities to trust the person who has reported the abuse.
The phrase “public shaming” is quite often used to refer to these acts of sharing information for the benefit of the community. Sharing information in order to safeguard the overall well-being of the community and at-risk individuals within that community is not vengeance, mob violence, a witch hunt or any other form of abuse. The fact that individuals who have engaged in abusive behavior might feel shame or otherwise incur negative consequences as a result of this information sharing is not sufficient reason to remain silent. It is acceptable for a person or person to feel shame when their inappropriate behavior is revealed. Shame in this context represents the loss of social privilege and is an important, but not the only, strategy communities have when confronting partner violence.
Moving forward, together
Pivoting back to our own community. How do we move forward in a positive and healing way?
We need to work together. We need to remember that everyone involved, including the aggressor, is human, and not sacrifice that humanity for an easy or expedient solution.
It’s a difficult task, certainly, but not insurmountable.
I, and others, are actively working on this issue. If you want to help or have questions, I’m here for you, so please get in touch. If you want to learn more about violence in communities, a good place to start is Revolution Starts at Home (pdf).
While I’ve never had all of my internet-eggs in Google’s basket, so to speak, I’ve appreciated many of their services and have become quite dependent on some.
I opened my first Gmail account in 2004. I switched from Bloglines to Reader sometime before the former was sold in 2005. My sanity, and probably my wife’s as well, depends on the appointments we track in Calendar. All of my correspondence has found its way to Google docs. All of my non-IRC chatting is done through gTalk with an xmpp client.
It’s never felt particularly good or prudent to be so reliant on one company, an advertising company, for some of my most important online needs. But when I would think of leaving Google, a sense of dread and panic would arise. I would think about how dependent on was on email, calendar and other services and how good alternatives seemed non-existent. Not surprisingly, I would come to the conclusion that I couldn’t live without Google, and that they weren’t that bad, after all. And then I’d move on to fretting about the next thing.
But the idea continued to percolate and re-surface in my mind. Each time Google made a decision to close a beloved product, take yet another step away from web standards, made a move that wasn’t outright evil, but wasn’t good either, I re-evaluated my reliance on their services. More and more I felt like I was the product first and the customer second, if at all. The final straw for me was in fact two: the end of full support for xmpp in Google talk and PRISM.
And thus, I’ve started the process of reducing my usage and reliance on Google services. I’ll document this process in a series of blog posts, roughly in order of priority:
Email and calendar
Mailing-lists (for the groups I manage)
Document editing and sharing
A few services I don’t intend to find near-future replacements for include Google voice and Hangouts. Google Plus isn’t on either list simply because I hardly use it. Nor have I ever used Picasa (I’ve always preferred Flickr). I have no immediate plans to delete my Google account. Doing so effectively means you can’t interact with any of Google’s services, which would severely limit my ability to interact with many individuals and groups for which it is necessary that I do so.
My goal isn’t to purge my life entirely of Google, but rather to reduce my reliance on its services and to decentralize my online activity.