Windows Live Writer Is Now Open Live Writer

openlivewriter-purpleheader

Scott Hanselman blogs about the release of Open Live Writer which replaces Windows Live Writer (not updated since 2012) which despite its lack of maintenance is a very popular blogging platform, especially with the WordPress community.  Give it a try and see.

ARE YOU AN EXISTING USER OF WINDOWS LIVE WRITER?

We encourage you to install Open Live Writer and try it out! OLW will run side-by-side with your existing Windows Live Writer installation. Open Live Writer installs VERY quickly and updates itself automatically. Try it out! It’s early but it’s a start. Please bear with us as we work to improve Open Live Writer.

if you do find bugs, please share your bugs at https://github.com/OpenLiveWriter/OpenLiveWriter/issuesand be specific about what’s not working. And please, be patient. We are doing this as volunteers – we are NOT representing Microsoft. Open Live Writer is no longer a Microsoft project, so while we will do our best to support you, let’s all try to support one another!

Open source computing started with the bicycle

Derived from ComputerWeekly.com

A new video on the origins of OpenSource explaining the suggestion tht OpenSource existed prior to the Industrial Revolution has been hosted on OSS Watch, an advisory service for issues relating to free and open source software in the Further Education (FE) and Higher Education (HE) sectors.

Open source and the bicycle

The first iteration of the bicycle dates back to 1817 and the invention of the Laufmaschine (German for "running machine") or Draisine (English).
drasine.png
This all wood construction basic "bike without pedals" was later to be innovated upon (in an open source fashion) all the way through to it becoming the bicycle as we know it.

The OSS Watch video below suggests that this great invention was taken up by lots of individuals… who all saw the potential in the device — and so the innovation curve was started.

Over the next 200 years we added brakes, pedals etc. and we’ve never looked back.

This collaboration is what the open source model of open contribution is all about i.e. it’s a level playing field fuelled by community input.

How to teach undergrads how to become open source contributors without writing any code

Posted 21 Feb 2012 on OpenSource.com by Sebastian Dziallas

Imdergrads and open source contributors without writing any code 

This is the story of a college class taught inside an open source community. Last fall, I taught Release Engineering to a small group of undergraduates at Olin College, an engineering school a few miles outside Boston. The goal was to teach them how to become functional technical contributors to an open source project–without writing any code. In the hopes that others will be inspired to teach similar classes, I’ve written our experiences up as a case study in three pieces: cultural, technical, and "getting real."

The cultural

My students all came from different backgrounds, so we started the semester by diving into some of the cultural particularities of open source communities reading pieces such as "the Cathedral and the Bazaar." See our reading list and notes from the first session.

We grappled with concepts such as "scratch your own itch," "radical transparency," and "release early, release often." (See a more detailed list of concepts.) Experienced open source contributors practice these cultural norms daily and often take them for granted, but norms vary from community to community and might not be immediately obvious to newcomers. When going into a new environment, it is important to know how not to offend.

The technical

The technical meat of the course came in a strange format: packaging–the art of getting an application into a distribution’s repositories. Although the task of packaging is at the core of every Linux distribution, it is unusual outside the world of open source, so many (if not most) computing majors will never experience it. So why teach packaging? It’s a complex task that depends on knowing and using a large number of key skills in release engineering, but it can also be done in a very short period of time, in a matter of hours or days–you don’t have to wait through an entire 6+ month release cycle.

For instance, dependencies need to be tracked and kept up to date, meaning that students quickly get a firsthand knowledge of the chaos that ensues when developers independently decide on API changes that break compatibilities. Patches need to be maintained for accuracy. Bundled libraries need to be cut out without damaging the actual application. Things like "documentation" and "version control" and "modular design" become painfully relevant instead of abstract values students know they "should" follow but don’t see the reason for. However, I do want to point out that these materials are designed to be taught by an experienced packager and release engineer; as with many arts, engineering is best taught through apprenticeship. Since I’ve been doing release engineering in major open source projects (including Fedora, the project where my students worked) since I was 16, I was able to guide them through. CS professors may want to find one or more community liaisons to mentor their students through these sorts of activities.

Real projects and interactions

As their large project, my students packaged the programming language io. In order to facilitate teamwork, I required them to write the configuration file in Etherpad, a collaborative text editor. This way, they could see at all times what the other students were doing, ask questions, and launch into a conversation. Control was not solely in the hands of a single student holding the computer. The experiment worked quite well. They returned with a set of very precise questions and an almost-complete configuration file, which was farther than I’d expected. We eventually found that the package was already part of Fedora. (Read more details.)

By the end of the semester, my students had interacted with the open source community primarily through IRC, but I also wanted to show them that in-person events were also valuable. So when Fedora Engineering Manager Tom Callaway gave a talk at the nearby Western New England University, we organized a field trip. Tom’s talk, "This Is Why You FAIL," (inspired by this chapter of The Open Source Way), was a hit. Having someone else explain to my students now not to Do Things Wrong was powerful. The Western New England students seemed to think so too.

Many teachers, many thanks

One of the best parts of teaching open source is that your students get to learn from many people, not just you. I’d like to express my gratitude to Tom "Spot" Callaway and all the Fedora contributors who answered my students’ questions online, as well as to professors Allen Downey, Heidi Ellis, and Zhenya Zastavker for being models and mentors for my own teaching.