In the 10+ years since its founding, Wikipedia has become an indispensable source of quality information for Internet users everywhere. Here at the Wikimedia Foundation, we’re very proud to support such a project. Yet, despite being a household name, there remain some issues with our user experience that are deeply troubling.

This is especially true for the smaller contingent of people who are the regular contributors to the encyclopedia. Wikipedia’s user interface has failed to keep pace with the the encyclopedia’s growth and the lack of a modernized editor experience has contributed to both a decline in the recruitment and retention of editors (a trend that started around 2007).

The Editor Engagement Experiments team tries to reverse this trend by defining, measuring and fixing these important editing workflows, and improving the experience of Wikipedia volunteers who create content. In this post, we’ll show you one of these editing workflows and invite developers to try their hand at implementing a solution.

An example problem

Imagine you want to create an article for English Wikipedia. You begin by searching for the article on Wikipedia and find that there isn’t one on the topic yet.  This is the screen you get.  Can you figure out how to create the article?

The answer is to click on the red link — that’s intuitive, right?

Even if you figure this out, you’re going to have problems. If you don’t have an account (like most readers), you’ll encounter another hurdle: the site will simply tell you that you don’t have permission to create the page. The solution is to create an account, but it doesn’t say that on the page.

Let’s say you register for an account (or log in if you have one) and then get back to the task at hand. Great. But not so much if you’re new to Wikipedia, because all we do is dump a blank text box on you and hope you know what you’re doing. There’s no warning that articles not meeting Wikipedia quality standards will be swiftly deleted. You could start by getting your feet wet by trying out one of the several workflows that are safer for starting a page, but none of these alternatives is presented as an option.

Thousands of people are subjected to this experience every month and all they’re trying to do add to the world’s collective knowledge. If all of this makes you a bit angry, keep reading.

(more…)

This year, the MediaWiki community again participated in Google Summer of Code, in which we selected nine students to work on new features or specific improvements to the software. They were sponsored by Google and mentored by experienced developers, who helped them become part of the development community and guided their code development.

Congratulations to the eight students who have made it through the summer of 2012 (our seventh year participating in GSoC)! They all accomplished a great deal, and many of them are working to improve their projects to benefit the Wikimedia community even more.

• Ankur Anand worked on integrating Flickr upload and geolocation into UploadWizard. WMF engineer Ryan Kaldari mentored Ankur as they made it easier for Wikimedia contributors to contribute media files and metadata. Read his wrapup and anticipate the merge of his code into the main UploadWizard codebase.
• Harry Burt worked on TranslateSvg (“Bringing the translation revolution to Wikimedia Commons”). When his work is complete and deployed, we will more easily able to use a single picture or animation in different language wikis. See this image of the anatomy of a human kidney, for example; it has a description in eight languages, so it benefits multiple language Wikipedias (e.g., Spanish and Russian). Harry aims to allow contributors to localize the text embedded within vector files (SVGs), and you can watch a demo video, try out the test site, or just read Harry’s wrapup post. WMF engineer Max Semenik mentored this project.
• Akshay Chugh worked on a convention/conference extension for MediaWiki. Wikimedia conferences like Wikimania often use MediaWiki to help organize their conferences, but it takes a lot of custom programming. Under the mentorship of volunteer developer Jure Kajzer, Akshay created the beta of an extension that a webmaster could install to provide conference-related features automatically. See his wrapup post.
• 

  Ashish is working on the architecture that will support real-time collaboration.

  Ashish Dubey worked on realtime collaboration in the upcoming Visual Editor (you may have seen “real-time collaborative editing” in tools like Etherpad and Google Docs). Ashish (with WMF engineer Trevor Parscal as mentor) has implemented a collaboration server and other features (see his wrapup post) and has achieved real-time “spectation,” in which readers can see an editor’s changes in realtime. Wikimedia Foundation engineers plan to integrate Ashish’s work into VisualEditor around April to June 2013.

• Nischay Nahata optimized the performance of the Semantic MediaWiki extension. In wikis with unusually large amounts of content, Semantic MediaWiki experiences performance degradation. With the mentorship of head Semantic MediaWiki developer Markus Krötzsch (a volunteer) and Wikidata developer Jeroen De Dauw, Nischay found and fixed many of these issues.  This also reduces SMW’s energy consumption, making it greener. Nischay’s work will be in Semantic MediaWiki 1.8.0, which is currently in beta and due to be released soon. Wikimedia Labs uses Semantic MediaWiki and will benefit from the performance improvements.
• 

  Arun Ganesh illustrated the watchlist redesign proposal with this mockup.

  Aaron Pramana worked on watchlist grouping and workflow improvements. Aaron wants to make it easier for wiki editors and readers to use watchlists, and to create and use groups of watched items to focus on or share. Aaron worked with volunteer developer Alex Emsenhuber. The back end of the system is done, but Aaron wants your input about the user interface. Folks on the English Wikipedia’s Village Pump have started discussing it.

• Robin Pepermans worked on Incubator improvements and language support, mentored by WMF engineer Niklas Laxström. If you’ve ever thought of using Wikimedia’s Incubator for new projects, it’s now easier to get started. Read Robin’s wrapup post for more.
• Platonides worked on a desktop application for mass-uploading files to Wikimedia Commons. The application will eventually make it much easier for participants in upload campaigns like Wiki Loves Monuments to upload their photos (and it’ll work on Windows, Linux, and Mac OS). I mentored Platonides, who delivered a beta version.

As further progress happens, we’ll update our page about past GSoC students. Congratulations again to the students and their mentors. And thanks to volunteer Greg Varnum, who helped me administer this year’s GSoC, and to all the staffers and volunteers who helped students learn our ways.

Sumana Harihareswara, Engineering Community Manager

We received 63 proposals for this year’s Google Summer of Code, and several mentors put many hours into evaluating project ideas, discussing them with applicants and making the tough decisions. We’re happy to announce our final choices, the Google Summer of Code students for 2012:

• Ankur Anand, working on integrating Flickr upload and geolocation into UploadWizard. WMF engineer Ryan Kaldari is mentoring Ankur as they make it easier for Wikimedia contributors to contribute media files and metadata.
• Harry Burt, working on TranslateSvg (“Bringing the translation revolution to Wikimedia Commons”). All readers and editors benefit when we can use a single picture or animation in different language wikis (example, use). Harry aims to allow contributors to localize the text embedded within vector files (SVGs). WMF engineer Max Semenik is mentoring this project.
• Akshay Chugh, working on a convention/conference extension for MediaWiki. Wikimedia conferences like Wikimania often use MediaWiki to help organize their conferences, but it takes a lot of custom programming. Under the mentorship of volunteer developer Jure Kajzer, Akshay aims to create an extension that a webmaster could install to provide conference-related features automatically.
• Ashish Dubey, working on realtime collaboration in the upcoming visual editor.  You may have seen “real-time collaborative editing” in tools like Etherpad and Google Docs.  Ashish (with WMF engineer Trevor Parscal as mentor) will work to bring this functionality to MediaWiki.
• Suhas HS, working on improvements to the OpenStackManager extension. We use OpenStack in our new Wikimedia Labs infrastructure. Suhas, with the mentorship of WMF engineer Ryan Lane, aims to improve MediaWiki’s ability to support the new Openstack API, which provides an interface to manage the virtualized environments.
• Nischay Nahata, working on optimizing the performance of the Semantic MediaWiki extension. In wikis with unusually large amounts of content, Semantic MediaWiki experiences performance degradation. With the mentorship of volunteer developer Markus Krötzsch and Wikidata developer Jeroen De Dauw, Nischay aims to find and fix these issues; this will also reduce SMW’s energy consumption, making it greener.
• Aaron Pramana, working on watchlist grouping and workflow improvements. Aaron aims to make it easier for wiki editors and readers to use watchlists, and to create and use groups of watched items to focus on or share.  Aaron will be working with volunteer developer Alex Emsenhuber.
• Robin Pepermans, working on Incubator improvements and language support. This project aims to improve the usability, performance, and coverage of Wikimedia’s Incubator. WMF engineer Niklas Laxström will mentor Robin.
• Platonides, working on a desktop application for mass-uploading files to Wikimedia Commons.  The application will make it much easier for participants in upload campaigns like Wiki Loves Monuments to upload their photos (and it’ll work on Windows, Linux, and Mac OS). I, Sumana Harihareswara, will be mentoring Platonides.

Congratulations to this year’s students, and thanks to all the applicants, as well as MediaWiki’s many mentors, developers who evaluated applications, and Google’s Open Source Programs Office. The accepted students now have a month to ramp up on MediaWiki’s processes and get to know their mentors (the Community Bonding Period) and will start coding their summer projects on or before May 21st. As the organizational administrator for MediaWiki’s GSoC participation, I’ll be keeping an eye on all nine students and helping them out.

Good luck!

Sumana Harihareswara, Volunteer Development Coordinator

Hello, MediaWiki developers and users! You may already be aware of this: our community is embarking on a journey to leave Subversion behind and migrate to Git for our source code repositories, starting on March 3rd (update as of February 29th: moved to March 21st). This is not an easy task. Here I’ll outline our rationale for this move, as well as our planned process.

What is Git?

Git is a distributed version control system originally developed by Linus Torvalds and others to manage the Linux kernel. In the past couple of years, it has taken off as a very robust and well-supported code repository. “Distributed” means that there is no central copy of the repository. With Subversion, Wikimedia’s servers host the repository and users commit their changes to it. In contrast, with Git, once you’ve cloned the repository, you have a fully functioning copy of the source code, with all the branches and tagged releases at your disposal.

Why switch?

Three major reasons:

To encourage participation: Since Git is distributed, it allows people to contribute with a much lower barrier to entry. Anyone will be able to clone the repository and make their own changes to keep track of them. And if you’ve got an account in our code review tool (Gerrit), you’ll be able to push changes for the wider community to review.

To fix our technical process: Subversion has technical flaws that make life difficult for developers. Notably, the implementation of branching is not very easy to use, and makes it hard to use “feature branches”. Our community is very distributed, with many parallel efforts and needs to integrate many different feature efforts, so we’d like to use feature branches more. Git branches are very easy to work with and merge between, which should make things easier for our development community.  (Several other large projects, such as Drupal and PostgreSQL, have made the same switch for similar reasons, and we’ve done our best to learn from their experiences.)

Some quotes from our community:

“I love git just because it allows me to commit locally (and offline).” – Guillaume Paumier

“[Y]ou can create commits locally and push them to the server later (great for working without wifi), you can tell it ‘save my work so I can go do something else now’ in one command, and it’ll allow us to review changes before they go into “trunk” (master)…. without human intervention in merging things into trunk. Gerrit automates this process.” – Roan Kattouw

And finally, to get improvements to users faster: with better branching and a more granular code review workflow that suits our needs better, plus our ongoing improvements to our automated testing infrastructure, we won’t have to wait months before deploying already-written features and bugfixes to Wikimedia sites.

We had years of discussion before we finally decided to switch, but now we can look forward to more flexibility and power in our engineering processes.

What are we doing?

We’ve now done almost all the back-end work of preparing our repository for the move and are in the final steps of preparation (details). We’ve also written explanations of the new workflow, the migration schedule, issues yet to be addressed, and other related topics. Right now, we’re asking people to stop creating any new extensions in Subversion right now, and to watch the wikitech-l mailing list for more updates.

What are the next steps?

Over the next two and a half weeks, the Git repository that contains MediaWiki core and extensions will be brought in step with Subversion, and at first it will be read-only (no one will be able to push changes). This will allow developers to start cloning it to their local machines and getting used to things.

For MediaWiki core and for extensions that the Wikimedia Foundation deploys on its wikis, the switchover is pencilled in for the weekend of March 3rd (Update as of February 29th: the new migration date is Wednesday, March 21st). We’ll do core first, and then extensions after, but hopefully all in the same weekend. After the successful migration, the Subversion repository (for the directories that have moved to Git, such as /trunk/phase3/) will be made read-only.

See the full schedule.

I develop for a Wikimedia project. Do I have to switch to Git?

Only two projects are affected immediately: the core of MediaWiki and the extensions that get deployed on Wikimedia Foundation projects.

So, if you work on an extension that the Wikimedia Foundation does not use, or on a non-MediaWiki project hosted at svn.wikimedia.org, you have more time to decide. Talk it over with your community and decide whether you would like to move to Git immediately, move to Git sometime over the next several months, or move to another hosting provider sometime before mid-2013. We would like to gradually migrate all projects currently on Wikimedia’s Subversion repository so that we can make all of svn.wikimedia.org read-only by the middle of 2013, and thus only have to support one source control infrastructure.

More details.

Will training and documentation be available? When?

Yes, we will provide training and documentation to help you use the new workflow. Check our Git page and its links now, and watch that space! There will be more documentation as well as some interactive training sessions before the big switchover in early March.

If you have any questions, please ask in #mediawiki on Freenode or on wikitech-l.  Thank you!

Chad Horohoe
Git migration lead
Platform Engineering department
Wikimedia Foundation

Sumana Harihareswara
Volunteer Development Coordinator
Platform Engineering department
Wikimedia Foundation

In January, 92 participants gathered in San Francisco to learn about Wikimedia technology and to build things in our first Bay Area hackathon.

After a kickoff speech by Foundation VP of Engineering Erik Möller (video), we led tutorials on the MediaWiki web API, customizing wikis with JavaScript user scripts and Gadgets, and building the Wikipedia Android app.  (We recorded each training; click those links for how-to guides and videos.)  We asked the participants to self-organize into teams and work on projects.  After their demonstration showcase, judges awarded a few prizes to the best demos.

(more…)

Earlier this month, about thirty MediaWiki developers and interested technologists gathered in New Orleans to learn and to work on Wikimedia’s technical infrastructure.  We made broad progress on the infrastructure of innovation at Wikimedia (notes).  Specifically:

• We are now much closer to officially opening the doors to Wikimedia Labs and giving far more people the ability to contribute to MediaWiki without having to set up and maintain their own development environments at home.  Wikimedia Labs will provide hosted, virtualized test and development sandboxes for new and experienced programmers and systems administrators.  Many developers got beta Labs accounts, we tested at a larger scale, and we fixed several bugs.
• Developers agreed to create a file backend abstraction layer to enable large-scale MediaWiki installations to use one of several storage systems to contain big collections of big media files.  (Wikimedia plans on using Swift, which is open source.) Microsoft’s Ben Lobaugh and SAIC’s DJ Bauch collaborated towards improving MediaWiki’s performance on Microsoft technologies as well.  Developers made architectural decisions, refactored some existing code, and improved documentation and tests for the SwiftMedia extension to MediaWiki.
• 

  Chad Horohoe teaching developers unit testing

  We now have a continuous integration server up and running.  This will continuously run tests checking on the latest new features and bugfixes that developers write, resulting in fewer bugs and faster development. Developers will need to write tests to reap the benefits, so Chad Horohoe taught a test-writing workshop.

• Max Semenik finished and demonstrated the first version of his API Query Sandbox.  This allows software developers anywhere to experiment with ways to automatically get data from Wikipedia or other sites that run MediaWiki, thus enabling wider and deeper reuse of Wikimedia content.
• Operations folks continued the Puppetization of our infrastructure: they completely reworked Varnish management in Puppet, and worked on Puppet configurations for SwiftMedia testing. This configuration management work will ensure that ops can move faster and more confidently in building and maintaining Wikimedia infrastructure. And Canonical’s Mark Mims and Kapil Thangavelu worked on improving methods for Wikimedia developers “to spin up stacks of services within the labs environment” using Juju (more details).
• 

  Brion Vibber leading developers into the "glorious Git future"

  Since the engineering department is planning a switch from Subversion to Git in the next few months, Brion taught nearly everyone there how Git works (slides, audio), and how we’ll be using Git in the future. This change in our source code repository and workflow will, we hope, enable more speed and flexibility in development, both for WMF developers and community contributors.
• We prioritized and addressed several open requests for the operations team and defect reports about the latest version of MediaWiki, 1.18, which had just been deployed across WMF sites.
• Roan found and fixed an issue that was spouting symbolic link errors into our Apache logs, so now it’ll be easier for us to see more dangerous errors in those logs.
• Google Summer of Code students Salvatore Ingala and Kevin Brown made progress on integrating their summers’ work into MediaWiki as used and deployed by others; Salvatore and WMF developer Roan Kattouw have a plan for getting his user scripts improvements reviewed and deployed, so they can benefit Wikimedia readers and editors.
• A volunteer came in on Friday night knowing nothing about developing for MediaWiki, and by the end of the weekend had a working development environment on her laptop and had some ideas about how to contribute.
• We had substantive conversations about the summer internship program and about third-party collaboration that will affect how we work in the future.

We also ate dinner together, walked Bourbon Street, and generally got to know colleagues we’d never met before.  I expect these relationships will bear fruit for years to come.

Thanks to Ryan Lane and Dana Isokawa for organizing the event with me, and thanks to Launch Pad New Orleans for providing the venue!

Our next developers’ event is a hackathon in Mumbai November 18-20 concentrating on internationalization, localization, and mobile work.  To find out about other upcoming Wikimedia technical events, check the meetings wiki page, and follow @MediaWikiMeet on Identi.ca or Twitter.

Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation

The October 2011 Coding Challenge has begun! Programmers are invited to enhance MediaWiki, the software that powers Wikipedia, by one of the following features:

• Mobile Photo Upload – upload images and video via smartphone
• Making Wikipedia More Alive – surface change in real-time
• Wikipedia Slideshow – showcase Wikipedia’s beautiful multimedia

After less than a day, 500 contestants from 80 countries had already signed up to participate, but submissions are still welcome until November 7.

---

Follow this series of brief news on enhancing Wikipedia participation via RSS, on Tumblr, or on Wikipedia.

Congratulations to the seven Google Summer of Code students who made it through the summer of 2011! They all accomplished a great deal, but want to continue contributing to ensure their work maximally benefits Wikimedia.

Yuvi Panda‘s assessment parsing/aggregating extension aims “to make it easier to select and export article selections for various offline collections.” Yuvi needs some code review and suggestions on how to improve it to meet the Foundation’s quality standards for deployability, as he wrote the developers’ mailing list.

Salvatore Ingala worked on making gadgets customizable. As he elaborated, that means:

• “allowing gadgets to easily declare the list of configuration
  variables they have;
• allowing users to easily change those settings, with an easy-to-use
  UI integrated to the Special:Preferences page.”

The next step is merging his code into trunk, which Salvatore’s planning with other MediaWiki developers.

Kevin Brown created the ArchiveLinks project to address the problem of linkrot on Wikipedia:

In articles we often cite or link to external URLs, but anything could happen to content on other sites — if they move, change, or simply vanish, the value of the citation is lost. ArchiveLinks rewrites external links in Wikipedia articles, so there is a ‘[cached]‘ link immediately afterwards which points to the web archiving service of your choice. This can even preserve the exact time that the link was added, so for sites which archive multiple versions of content (such as the Internet Archive) it will even link to a copy of the page that was made around the time the article was written.

Kevin’s next step: getting a security review of his code, getting a starter feed set up so that the Internet Archive can start archiving it, and campaigning to interest Wikimedians and thus eventually get consensus to turn it on. At least one Wikimedian has already praised Kevin for his work.

Akshay Agarwal wrote a MediaWiki extension, SignupAPI, that makes it easier for a new user to create an account. “This extension creates a special page that cleans up SpecialUserLogin from signup related stuff, adds an API for signup, adds sourcetracking for account creation & provides Ajax-ified validation for signup form.” Akshay’s waiting for code review and discussion before the project can move forward further and benefit Wikimedia users.

Yuvi, Salvatore, Kevin, and Akshay all worked on features that they aim to get into Wikimedia Foundation-run wikis, such as Wikipedia, Wikisource, Wikinews, etc., sooner rather than later. In contrast, three students worked on extensions that will primarily benefit the larger MediaWiki community. For example, Yevhenii Vlasenko‘s project was a “UserStatus” feature for SocialProfile. The SocialProfile extension is not currently deployed on any WMF wikis, but will benefit several other MediaWiki administrators and users. Zhenya finished his work but would like to continue by integrating better with social networks.

And two students worked on Semantic MediaWiki, which is also not currently deployed on any Wikimedia Foundation sites. Devayon Das made a “QueryCreator” and other improvements, and hopes to simplify its layout, make its interface easier to use, and add some features. And Ankit Garg worked on “Semantic Schemas”.

Congratulations to the students and their mentors.  Here’s hoping they’re all here to help out when next year’s interns roll in! :-)  And I’m looking forward to meeting Kevin and Salvatore, and introducing them to other Wikimedia & MediaWiki developers, at the New Orleans developers’ meetup next month.

Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation

MediaWiki’s Google Summer of Code students have been busy! We’re more than halfway through the summer, so here’s what they’re up to:

• Akshay Agarwal’s “Account Creation, Login Screens and AJAX-ification of everything” (mentor: Brandon Harris). Code, project status.
  The last task I accomplished: “Added source tracking functionality in the account creation API that I am building.”
  Something I’ve learned: “True learning can happen only in an open environment & with a highly supportive community.”
• Kevin Brown’s “Working Archival for Web References/Citations,” “to facilitate the archival of external links used as references in the English Wikipedia” (mentor: Neil Kandalgaonkar). Code, project notes.
  The last task I accomplished: “Adding support for wget local archival, currently working on feed for external archival services.”
  Something I’ve learned: “Where do I start? A lot. I think the biggest thing is probably managing a large project and time management, which I still have a lot to learn on.”
• Devayon Das’s “Improving Semantic Search/Semantic Query usability issues in SMW” (mentor: Markus Krötzsch). Code, project notes.
  The last task I accomplished: “Added RSS links to the results generated by the Query Creator interface I’m building.”
  Something I’ve learned: “A 30 second chat with a community member can save you 30 minutes of scratching your head in frustration.”
• Ankit Garg’s “Semantic Schemas extension” (mentor: Yaron Koren). Code.
  The last task I accomplished: “I finished adding the inheritance support to the PageSchema XML structure.”
  Something I’ve learned: “I have a learned a great deal of PHP; also how to manage a huge project.”
• 

  "A 30 second chat with a community member can save you 30 minutes of scratching your head in frustration."

  
  Salvatore Ingala’s “AMICUS: Awesome Monolithic Infrastructure for Customization of User Scripts” (mentors: Max Semenik and Brion Vibber). Code, project notes.
  The last task I accomplished: “I made a prototypal user interface for editing preferences of an existing gadget, HotCat.”
  Something I’ve learned: “Unit testing is boooooring, but ends up saving you a lot of time!”
• Yuvi Panda’s “Making Offline Wikipedia Article Selection Easier with Mediawiki Extensions” (mentor: Arthur Richards). Code, project.
  The last task I accomplished: “Filter articles based on name, quality and importance.”
  Something I’ve learned: “That spending time talking to everyone involved in the process from start to finish (devs, community maintainers, etc.) saves a truckload of time later on.”
• Zhenya Vlasyenko’s “MediaWiki Extension: SocialProfile – UserStatus feature” (mentor: Jack Phoenix). Code.
  The last task I accomplished: “Internalization of the UserStatus feature with the help of the MakeGlobalVariablesScript hook.”
  Something I’ve learned: “I’ve found out for myself a new ways of data interaction between PHP and Javascript… Convinced that knowing some tricks and hooks can greatly save time.”

Aigerim Karabekova, who was working on extension release management, ran into several delays (including medical issues) and the project has been dropped. We’re glad she made the attempt and wish her the best.

Continued best wishes to Zhenya, Yuvi, Salvatore, Ankit, Devayon, Kevin, and Akshay as they work to make MediaWiki, and the Wikimedia experience, better.  We’re glad to be helping young developers learn how to contribute to our community.

Sumana Harihareswara
Wikimedia Foundation, Volunteer Development Coordinator

On May 24th and 25th, the Wikimedia Foundation hosted a CiviCRM coding sprint in our San Francisco office. CiviCRM is the premier open source constituent relationship manager; WMF uses it to store donor and contribution information. Our CiviCRM database contains more than a million contact records and a million contribution records.

The sprint was a terrific success. The eight participants squashed many CiviCRM bugs — and the Foundation directly benefited, as they improved CiviCRM contact/contribution search performance by 15 to 25 times! Formerly, it could take more than two minutes for someone to search among the contribution records. The developers’ tweaks, hacks and patches whittled that down to about 4-6 seconds per search. This will save innumerable hours for WMF administrators and fundraisers.

The Foundation’s Arthur Richards, a fundraising engineer, enthused: “Any software tool, open source or not, comes with headaches; the beauty of tools like CiviCRM is that we can solve our own problems. Thanks to having some great hackers in one place, we managed to mitigate one of our biggest CiviCRM pain points in a matter of hours.”

You can read more details about the sprint on Donald Lobo’s CiviCRM blog.

Richards was especially excited to “highlight how awesome it is working with other open source projects and using other open source tools. We get to scratch each other’s backs, which helps support a sustainable, healthy ecosystem of software/communities. Also, using open source tools like CiviCRM – while not without their (often big) pain points – is great because we can fix the software ourselves. While the tools are free to use, with a little bit of elbow grease and some resources, they can be molded and fixed to meet our needs much easier (and likely much cheaper) than relying on proprietary tools. Plus, the CiviCRM community has been instrumental in helping us troubleshoot, solve problems and add new features to meet our usage requirements.”

The CiviCRM community is planning to run another code sprint in the fall in Northern California; please contact them if you’d like to participate or even host it. In the meantime, Wikimedia and thousands of other nonprofits will enjoy the CiviCRM improvements developed in May.

-Sumana Harihareswara
Volunteer Development Coordinator, Wikimedia Foundation