SHA2017: hacker conference/camp videos are up

SHA2017: hacker conference/camp videos are up

SHA2017 is on today (it started over the weekend and ends tomorrow) and it is a hacker conference and camp.

Most of the conference videos are up on Youtube and they are very informative and fun. There are a lot of good talks. I’ve picked a few to showcase here but you should check out the whole playlist of SHA2017 videos.

Decentralize! Self-hosting in your own home using Sovereign

In the Decentralize! talk, the software Sovereign is explored and shown to be a good way to set up your own personal cloud and host your own services and data. Sovereign is a set of playbooks that can be run to install the software on a server that you run. It’s similar to the Freedom Box project.

The software you can self-host with Sovereign is:

  • Dovecot, Postfix and Roundcube for email servers and a webmail interface
  • Jabber/XMPP messaging server with Prosody
  • RSS reader
  • VPN server with OpenVPN (FreedomBox also can do this)
  • Git code repository hosting

Continue reading “SHA2017: hacker conference/camp videos are up”


ELearning Management Systems: Moodle vs Sakai

Hi, I’m Tony and I am a university student in Sweden. The university I go to uses two great free/open source products for their elearning platform and learning management system. Today I am going to talk about these products: what they are, some of their features and what strengths and bottlenecks they have.

Both are educational web-based platforms which allow students and teachers to communicate with each other on bulletin board systems, with web-based online forums. More importantly, they are places where students can hand in their assignments and have them graded by teachers.

They both offer an educational platform with similar feature sets, so in that regard they are competitors.


Flexible in design, students and teachers can customise how pages appear by choosing from a multitude of themes. All you have to do is log in with a username and password and go change the theme in your account settings. Apart from the visual appearance, there are lots of other features, mainly being able to enroll in “courses”. This is an analogy to your university course. Students must enroll into courses to be part of it. Courses can either be open for enrollment or available with a course key (aka password). Once you are enrolled in the course, you can start talking to other enrolled students, by, for example: sending a private message and discussing in forums.

Teachers can create assignment sections on the site, accessible by each course-enrolled student. After a student has handed in the assignment, the teacher will be notified one way or another (e-mail notifications are most commonly used). After reviewing the sent-in assignment, the teacher can grade it so that the student knows whether they passed the grade on the assignment or not.

You also have a course participants section where you can see a list of the students and teachers. The activity list is a handy way to see a history log of assignments you have handed in. Even your course buddies’ assignments will show up in the history log.

All in all, it’s an open source solution suitable for universities wanting a way to administer courses and communication with their students. It is not perfect, but it has a lot to offer.

Pros of Moodle

  • Minimalistic web interface.
  • Runs well on older computers
  • Looks good on tablet devices

Cons of Moodle

  • Somewhat confusing to use at first. Hard to navigate and searching the site is not optimal.
  • As far as I know, it is not able to integrate with single sign-on (SSO), which means your users will probably need to register a special Moodle account to use Moodle.
  • I have found that some versions of the Moodle software don’t work 100 %. Your mileage may vary. They do update the code kind of frequently, so if something does not work in the version you are using, there is a chance it will get fixed eventually, in a newer version.
  • The system is very simplistic in appearance and features. I recommend developing your own theme if you have the time and skills, in order to integrate it smoothly with the rest of your university website.


The Sakai system is similar in features to what Moodle offers. However, the visual appearance, layout and administration of the system is very different. The whole site is focused mainly around forum/discussion topics and different forms of teacher news bulletins. You also have an area where you can submit your assignments.

Pros of Sakai

  • Invites the student to discuss topics with fellow students in a structured way.
  • Perfect for teachers who need to communicate with students about upcoming changes in course schedule
  • Well-organised forum section.
  • Support for Single Sign-On (SSO). While this depends on how your university set this up, you at least have the ability to enable and use SSO with Sakai.

Cons of Sakai

  • While the navigation between forums is well-organised, it is unfortunately single-session. This means you can’t open multiple tabs in your web browser to navigate between different forums and forum posts, which can be a reoccurring annoyance.

How are they different from each other?

While I would say Sakai is a competing solution to Moodle, it is also very different in nature. They are not competing in the sense that their target audience will be the same. Some university courses will be perfect to use Sakai for, while others benefit greatly from Moodle. Moodle is assignment-oriented while Sakai is a discussion-oriented platform with a strong focus on communication between the teachers and students.

How does the university use them and which one should you choose?

The way Sakai is focused around discussion topics and teacher news announcements, it is targeting university courses that revolve around assignments where students are supposed to discuss specific topics with each other, in categories of studies such as arts, philosophy and language learning.

Moodle on the other hand, is very focused around reading about each and every assignment you have in your course and later hand them in when they are ready to be submitted to Moodle. While there usually are forums set up to use in the courses, it is more of an optional feature and not the center of the attention of the product.
Moodle is suited for scientific and programming courses where you do programming code assignments or scientific paper assignments, where each student work individually and hand in their results when they are done. It is not much of a collaborative community approach, unlike the discussion approach Sakai takes on.

Hands off teaching vs hands on teaching

If you want to put together a course for students, with moodle you can be more hands off and let students run through the course themselves. this is the strategy taken by organizations such as the Open University ( and the Ontario Ministry of Labour. Other educational organizations such as Coursera would be more suited to use Sakai as their classes start at the same time for all students so they have cohorts of students that can communicate with one another and with teachers. Moodle can be used for self-learning, Sakai can be used for group learning.

Both Solutions Are Good

Both solutions are good on their own terms. You will find that both Moodle and Sakai are solid web-based educational platforms.

You only need to consider four things when you evaluate these two systems:
– What kind of courses are we running and how do we match these to our educational web?
– Are students working alone or working together?
– What is the core structure of your courses: communication oriented and collaborative (Sakai), or solution oriented (Moodle)?

No matter which solution you choose: good luck!

Tony Granberg (@teknisktsett on Twitter) is a university student in Sweden with years of experience in using Moodle and Sakai.

What I’m Thankful For (Happy Canadian Thanksgiving!)

In Canada, this weekend has been all about Thanksgiving. So here’s what I’m thankful for when it comes to free/open source software and the community!

I’m thankful for:

  1. The Linux Kernel and the development team, for giving us a free/open source alternative to the dominant OSes
  2. The GNU Project, for giving us the core tools to build a free operating system and free/open source user applications
  3. The Free Software Foundation, for never ceasing to promote the ideals of free software
  4. The millions of people volunteering their time and skill to helping so many free/open source software and hardware projects get going and keep moving forward

I’m especially thankful for all the maintainers of our favourite software. From the one maintainer for a rarely used project to the team of maintainers for the biggest projects that are daily, it takes a lot of patience and hard work to deal with all the incoming patches, requests for features, bug reports and everything else. I’m thankful for the maintainer who takes a few minutes out of their day to do a code review.

I’m also thankful that so many people out there believe that free software ideals are the future and that the open source development model can and should be adopted by everyone.

On Open Sourcing Libraries

William Durand has written a great post on how to release code under a free/open source license. It isn’t simply a matter of uploading the latest version of your code, it’s a matter of updating the documentation so that others can contribute easily, so that others know the purpose of the project and how to get it running.

The most important section in the post, at least for me, is being standard:

It is important to use the right tools for your library. Look at your community again, and choose the tools people tend to use. In PHP, we use Composer as dependency manager. Don’t waste your time with PEAR or anything else, use Composer. If you write a Node.js library, register it on npm. For Ruby developers, distribute your library as a gem. For C# developers, use NuGet.

Another example, in Symfony2 it is considered good practice to add documentation in Resources/doc. It is a convention. Don’t duplicate your documentation. Add a link to quickly jump to this folder on your README file instead.

He outlines what a README should include:

  • name
  • description
  • Usage section
  • Installation section
  • Contributing section
  • Testing section
  • License section

The project should include a file that clearly states which license is being used and should be clearly visible in the README or any other project home page.

The project should be tested and have some kind of automated tests:

Open Source projects are a way to write beautiful code as there are no deadlines, and no “customers”. Keep in mind that your projects show what you are able to do. As a developer, your library is your business card.

Write tests, a lot! How do you expect people to contribute to your library if you don’t provide a test suite? So, write tests, and use Travis CI. It is all about adding a .travis.yml file describing how to run your tests. It is another way to document how to run the tests.

Add a status image to your README file too.

Take a look at online tools such as Scrutinizer for PHP and JavaScript, or Puppet Linter. Automate as much as you can.

I think I’ll write a HowTo based on Mr Durand’s blog post.

Another good example of how to announce a free/open source project

Another good example of how to announce a free/open source project

The Sunlight Foundation and the Media Standards Trust worked together on a project called Churnalism. It’s a web browser extension available for Chrome, Internet Explorer and Firefox.

Their announcement is a good example of how to announce a project. In the 1st paragraph they’re giving credit to the teams involved in building the project and they give us a brief overview as to the purpose of the project. The 2nd paragraph tells us how to use the project with links (very important!) to the project so that you can try it out yourself. They include a video tutorial to further explain how the tool works.

Further down in the article they tell us more about how the project was developed and link to another blog post with more details:

Sunlight’s Churnalism is based on a UK site of the same name and is driven by open-source text analysis technology dubbed SuperFastMatch, both developed by the awesome Media Standards Trust. For a deeper dive into the underlying technology and process behind the project, check out this detailed post from Drew Vogel, another developer on Churnalism.

There’s also a privacy concern with the project, so they clearly state and what they’ve done to mitigate that risk:

We understand the privacy sensitivities with an extension extracting text from what you read, so we’ve designed Churnalism to be quite customizable and never retain identifiable information such as your IP address. You can easily change which sites Churnalism runs on by going into the settings for the browser extension. We’ve provided a basic whitelist of major news sites, a listing of local news affiliates and the ability to let Churnalism run on any site with news or article in url, but all these can be removed or paired down (or expanded!) to whatever sites you’re interested in.

Unlike the announcement by Airbnb for their Rendr.js library or the announcement by the Universidad Carlos III de Madrid for quantitative analysis tools, the announcement for Churnalism doesn’t state why the project has been released as free/open source, and they don’t try and play up why free/open source is important to them. This shouldn’t always be done; if there’s a way to promote your organization’s brand further and to state their commitment to collaborating in a free/open source community, it should be done.

To summarize, when you announce the first public version of your project, released under a free/open source license, you should do the following things:

  • clearly state the purpose of the project, this will establish the target audience and the types of users to expect to use the project
  • describe how the target audience can use the software
  • answer these questions:
    • is there a demo?
    • can anyone download the software and run it?
    • can it be tried out on the web?
    • which platforms are supported?
  • link to other blog posts or articles or Wikipedia articles that explain how your software works behind the scenes
  • link to other blog posts that are testimonials and use cases of your software
  • promote any other free/open source projects that your organization is working on or contributing to

New quantitative analysis for free/open source software projects

Universidad Carlos III de Madrid has created some quantitative analysis tools for free/open source projects, used for extracting information from code repositories.

I like a few things about this article:

they define “open source” with a simple definition,

Open source software is that which, once it is received, can be used any way one wishes: it can be redistributed (for free or for a fee) and modified, if one knows how to do so.

they mention an advantage of participating in free/open source development,

The main advantage for companies when they participate in open source software projects is that, because they are participating in a development community, they are sharing costs with the other participants, so company resources can be used more efficiently. “The risks come from there as well: you are dependent, as least partially, on how well, or how poorly the development community behaves,” warns the researcher.

they also state that free/open source is much more transparent and therefore much easier to verify for correctness,

The difference that exists in the evaluation process with respect to proprietary software is that, in the majority of open source software projects the data sources are public, because these projects are very interested in transparency. This makes it possible for anyone to analyze reliable data without the need to even have agreements with the projects. In the case of proprietary software this is impossible: it is only for authorized users who have a special agreement with the program’s producer.