Categories
Greek Guest Posts

Γιατί ανοικτό λογισμικό;

Reading Time: 3 min

(δημοσιεύθηκε στο blog της Social Mind στις 20/10/2015)

Πριν λίγο καιρό είχαμε δει 5 λόγους για να δημιουργήσετε το εταιρικό σας website σε WordPress. Εκτός από ένα δωρεάν, εξαιρετικά ώριμο και πλούσιο σε λειτουργικότητα εργαλείο, το WordPress αποτελεί επίσης σύστημα Ελεύθερου Λογισμικού / Λογισμικού Ανοικτού Κώδικα (ΕΛ/ΛΑΚ), χαρακτηριστικό στο οποίο οφείλονται πολλά από τα πλεονεκτήματά του.

Για να μείνουμε στην ουσία, θα αποφύγουμε να εμπλακούμε στο διάλογο για το αν το Ελεύθερο Λογισμικό ή ο Ανοικτός Κώδικας είναι πιο δόκιμοι όροι και θα παρουσιάσουμε μια σειρά από πλεονεκτήματα που “θα απολαύσετε” εάν επιλέξετε να υλοποιήσετε τα digital assets σας κάνοντας χρήση ΕΛ/ΛΑΚ.

Πλήρης προσβασιμότητα

Σε συστήματα κλειστού λογισμικού, είναι στη διακριτική ευχέρεια των κατασκευαστών να σας αποκαλύψουν το κομμάτι των λειτουργιών του λογισμικού που εκείνοι επιθυμούν. Αυτό συμβαίνει γιατί πολύ απλά σαν χρήστες της εφαρμογής δεν έχετε πρόσβαση στον κώδικα (πως φτιάχθηκε δηλαδή το λογισμικό), αλλά μόνο στο τελικό εκτελέσιμο αρχείο.

Με το ΕΛ/ΛΑΚ, οι χρήστες έχουν πλήρη πρόσβαση στον κώδικα, το εκτελέσιμο αρχείο, την τεκμηρίωση και εν γένει σε οποιοδήποτε άλλο asset του λογισμικού. Έτσι υπάρχει διαφάνεια μεταξύ της ομάδας ανάπτυξης και του τελικού χρήστη, αφού ο τελευταίος μπορεί να πιστοποιήσει ότι το λογισμικό προσφέρει πραγματικά “ό,τι υπόσχεται”, είτε μόνος του (αν έχει τεχνικές γνώσεις), είτε χρησιμοποιώντας κάποιον εμπειρογνώμονα.

Η τεκμηρίωση υπάρχει (!) και είναι συνήθως υψηλής ποιότητας

Όταν δε χρειάζεται να μοιραστούμε τον πηγαίο κώδικα του λογισμικού μας με άλλους, συνήθως τεκμηριώνουμε πρόχειρα, ελάχιστα ή καθόλου. Αυτό συμβαίνει κατά κόρον στα λογισμικά κλειστού κώδικα αφού, επειδή ο κώδικας μοιράζετε μεταξύ των προγραμματιστών της εταιρίας, οποιαδήποτε απορία σχετικά με αυτόν μπορεί να λυθεί δια ζώσης.

Στο ΕΛ/ΛΑΚ τα πράγματα είναι διαφορετικά. Σχεδιάζουμε κώδικα ο οποίος θα χρησιμοποιηθεί, διορθωθεί και επεκταθεί, από προγραμματιστές που δεν γνωρίζουμε προσωπικά (και ενδέχεται να μη συναντήσουμε ποτέ στη ζωή μας. Προκειμένου λοιπόν το λογισμικό μας να είναι ελκυστικό προς όλους αυτούς τους εν δυνάμει συνεργάτες που θα τον επεκτείνουν pro bono, προσπαθούμε να γράφουμε όσο πιο αναλυτική και καλογραμμένη τεκμηρίωση γίνεται.

Ακόμη, όμως, και για projects ΕΛ/ΛΑΚ που η τεκμηρίωση είναι κακής ποιότητας ή ελλιπής υπάρχει περίπτωση κάποιος τρίτος να επέμβει και να τη διορθώσει.

Η λειτουργικότητα είναι ώριμη

Ένα πολύ συχνό φαινόμενο στα συστήματα λογισμικού είναι οι αστοχίες (bugs)… τα οποία για να διορθωθούν, πρέπει κανείς να τα βρει πρώτα. Πολλές εταιρίες λογισμικού σήμερα απασχολούν προσωπικό με την ιδιότητα του tester, δουλειά του οποίου είναι ο έλεγχος του λογισμικού για bugs.

Στο ΕΛ/ΛΑΚ επειδή το λογισμικό είναι συνεχώς ανοικτό και προσβάσιμο από όλους, οι τελικοί χρήστες το χρησιμοποιούν (και άρα το ελέγχουν), καταχωρούν τα bugs που βρίσκουν και πολλές φορές τα διορθώνουν κιόλας, αν έχουν τεχνική κατάρτιση.

Ας σκεφτούμε το εξής τώρα: Τι είναι πιθανότερο να είναι περισσότερο ελεγμένο; Ένα λογισμικό μιας εταιρίας που αναθέτει το testing σε μερικούς υπαλλήλους ή ένα λογισμικό που ελέγχεται καθημερινά από δεκάδες διαφορετικών χρηστών, ενώ χρησιμοποιούν το λογισμικό σαν τελικοί χρήστες;

Πληθώρα επεκτάσεων

Όταν φτιάχνουμε ένα σύστημα λογισμικού έχουμε στο νου μας μια σειρά πραγμάτων που θα θέλαμε να κάνει. Αυτό το λέμε version 1.0. Ας υποθέσουμε ότι το ίδιο λογισμικό θέλει να το χρησιμοποιήσει κάποιος άλλος χρήστης ή εταιρία. Οι ανάγκες του/της μπορεί να είναι διαφορετικές. Σε αυτήν την περίπτωση προχωράμε σε αυτό που ονομάζουμε επέκταση συστήματος, δημιουργούμε δηλαδή νέες λειτουργίες προσπαθώντας να καλύψουμε αυτές τις έξτρα ανάγκες.

Στο κλειστό λογισμικό επεκτάσεις γίνονται μετά από απαίτηση κάποιου πελάτη. Στο ΕΛ/ΛΑΚ, επειδή η πρόσβαση στον κώδικα είναι ελεύθερη, οι ενδιαφερόμενοι μπορούν να προχωρήσουν σε υλοποίηση των δικών τους επεκτάσεων ανά πάσα στιγμή. Οι άδειες ΕΛ/ΛΑΚ, ωστόσο, συνήθως επιβάλλουν αυτές οι νέες επεκτάσεις να “επιστραφούν” πίσω στην κοινότητα λογισμικού ώστε να χρησιμοποιηθούν και από άλλους. Έτσι, τα έργα ΕΛ/ΛΑΚ επεκτείνονται συνεχώς με νέες λειτουργικότητες που αποτελούν ανάγκες των τελικών χρηστών και το βασικότερο, οι επεκτάσεις αυτές είναι τις περισσότερες φορές δωρεάν για όλη την κοινότητα.

Μπορείτε να ζητήσετε support, αλλά δεν είστε υποχρεωμένοι

Δυο κόστη που είναι προαιρετικά στη χρήση ανοικτού λογισμικού είναι το κόστος άδειας (lisence fee) και το κόστος υποστήριξης (support). Επειδή το ΕΛ/ΛΑΚ είναι ελεύθερα διαθέσιμο προς όλους, οποιοσδήποτε επενδύσει χρόνο ώστε να το μελετήσει σε βάθος μπορεί να το κατανοήσει και να το υποστηρίξει. Αν δεν υπάρχει τέτοιο άτομο διαθέσιμο, η εταιρία μπορεί να αναζητήσει υποστήριξη από την κοινότητα του συγκεκριμένου έργου ΕΛ/ΛΑΚ επί πληρωμή.

Φορητότητα και αλλαγή τεχνικού team

Αν έχετε συνεργαστεί με εταιρίες ανάπτυξης ιστοσελίδων κλειστού κώδικα, μπορεί να έχετε συναντήσει τον όρο ότι αν επιλέξετε να αλλάξετε συνεργάτη, δεν μπορείτε να “πάρετε” την ιστοσελίδα σας μαζί. Η λογική πίσω από αυτό είναι ότι, αν πάρετε το site μαζί σας, παίρνεται και τον πηγαίο κώδικα, που είναι ιδιοκτησία της εταιρίας που το έφτιαξε.

Με τα συστήματα ΕΛ/ΛΑΚ αυτό δεν είναι πρόβλημα καθώς ο κώδικας βρίσκεται ήδη ελεύθερα εκεί έξω. Αυτό σημαίνει ότι ανά πάσα στιγμή επιλέξετε να αλλάξετε συνεργάτη, το website σας μπορεί να μετακινηθεί χωρίς πρόβλημα στο server του νέου συνεργάτη χωρίς να χρειάζεται να το φτιάξετε, και άρα να το πληρώσετε, από την αρχή!

Categories
English Videos & Podcasts

Presenting Open Source Software Resilience Framework at Open Source Systems 2018 (OSS2018)

Reading Time: < 1 min

What does the work resilience means to you? What are the characteristics of a resilient system? How is resiliency affecting a software system? How can we design and built resilient systems?

During June we had the honor and delight to participate to the 14th International Conference on Open Source Systems (OSS 2018). We presented our work, “Open Source Software Resilience Framework”, a preliminary study that aims to adapt the famous City Resilience Framework, created by Arup with the support of the Rockefeller Foundation, to the Open Source Software Engineering Domain.

Categories
Chest

Mozilla Open Leaders: The power of keeping an open source project journal

Reading Time: 4 min

The 6th round of Mozilla Open Leaders program is about to start. If you are didn’t have the chance to apply for this round consider applying to the next one since it is a great and very educational experience. If you are participating in the 6th round, congratulations for joining the Work Open Lead Open (aka WOLO) movement 🙂

During my training in the previous round I had the chance to learn a great deal of stuff and also experiment on tools and processes with the aim of effectively managing open source projects. One tool that helped me during the 3 month training program of Mozilla Open Leaders was keeping a project journal.

Why create and maintain an Open Source Project Journal?

When you begin working on your project you will be advised to create a project road map. This road map will have to initially  include goals for the Mozilla Open Leaders 3 month program and, as time passes, you will be extending it to the future by closing some tasks and adding new ones. Mozilla Open Leaders is a human centric program with lots of interaction (with fellow trainees, coaches, mentors, etc.) something that makes you continually evaluating your project’s goal and adapt appropriately.

So the road map is a sequence of actions we would like to – ideally – follow in order to see our amazing project come to life. But, since usually things aren’t going as planned, you might find yourself held back from those goals. Keeping a journal with the tasks you actually accomplish help you be able to reflect on your original vision and the things you actually accomplished and effectively plan your next steps. Moreover, when contributors start joining your project you will have a well formed summary of what happened to date to share with them and get them quickly up to speed.

TIP: If you decide to create a public open source project journal, try to keep it up to date or your contributors might get the feeling that the project is being abandoned. Remember that, in some cases, your team doesn’t have a view, as clear as the leader of the project, about the project’s status. Keeping an up to date journal can give clarity and transparency to the project.

How to create an Open Source Project Journal?

A journal is nothing more than a dated document with bullets. It works as a summary of how the project is moving forward and its main purpose is to inform anyone working on the projects on what has been accomplished. Therefore it can be a document on your Google Drive or Dropbox, part of your Github project, etc.

I would suggest to create your project’s journal to accompany your project core files. During your Mozilla Open Leaders training you will be introduced to Github. Github is a control versioning system originally created to serve open source software projects but, as you are going to find out soon, it can be used to host open projects with the need of collaborative access to files.

If you work with Github you can use the Wiki feature to create your journal (and other project related pages you might need such as the roadmap, documentation, etc.). In the following image you can see Github’s Wiki environment for my project, HealthyWP, part of the 5th Mozilla Open Leaders round 🙂

Github’s Wiki Functionality

Part of HealthyWP project’s journal

What to write on an Open Source Project Journal?

The basic goal of your journal is to be a summary of your project’s evolution over time. Imagine it as a ship logbook. Here are some thoughts on what information your journal can contain:

  • Date
  • Events / Information to log
  • People involved
  • Tags (if you have different types of events you can use tags to easily differentiate the log entries)

For the needs of my journal (kept during Mozilla Open Leaders program) I used the following, pretty simple, structure:

Date #1

  • Record 1
  • Record 2

Date #2

  • Record 1
  • Record 2

My journal for the Mozilla Open Leaders 5th round

Following you can find the journal I kept during my training in the 5th round of Mozilla Open Leaders.

May 10-11, 2018

  • Mozilla Global Sprint 2018.
  • Documentation added as a wiki page.

May 9, 2018

April 30, 2018

  • Basic business logic of the WP plug-in.

April 24, 2018

April 2, 2018

  • Working to WordPress plugin data extraction.
  • Waiting for the results from the UX workshop (soft deadline: April 15)

March 29, 2018

  • Participated in 5th UX Thessaloniki Meetup where I pitched the project (and got additional feedback). Also made an open call for volunteers. During the meetup we had the chance to practise UX Research and Design methods:
    • User Interview
    • Empathy Mapping
    • User Jouney Mapping
    • Wireframing

March 26, 2018

March 19, 2018

March 17, 2018

March 11, 2018

March 4, 2018

  • Github projects added to the project in order to track tasks & milestones.
  • During the week, contacted local experts / meetup organizers for help.
    • WordPress Plug-In Observatory Project will be presented to the 12th WordPress Thessaloniki Meetup.
    • WordPress Plug-In Observatory Project will be featured as the case study (for hands on experience) at the upcoming 5th Thessaloniki UX Meetup. The results of this meetup will be “donated” to WordPress Plug-In Observatory for its UX design and will be applied with the help of the meetup’s organizers (Anthi Malteza & Ioannis Feneris) who kindly volunteered to help.

February 25, 2018

  • Open Canvas (v1.0)
  • Roadmap (v1.0)
  • Github project created to host the code and (probably serve) be used as the project management tool.

(Photo by Easton Oliver on Unsplash)

Categories
English

It’s not about Open Source

Reading Time: 2 min

Three days ago we celebrated 25 years from the birth of Linux. I have been an Open Source user for over a decate now and I consider myself lucky to be part of this awesome network.

Open Source gave me free access to applications that, have they been proprietary, I would need to pay good money or illegally obtain them. Open Source fueled my research when I was an undergrad computer science student and, later on, during my MSc and currently during my PhD endeavor. As a researcher it gave me the opportunity to be part of EU funded research projects and get paid to study what I love. As a freelancer it gave me the means to rapidly develop software and therefore deliver competitive, high quality and tested software to my clients. It also allowed me to do consulting work for a couple of amazing software development companies and startups.

Anyways, it was not until recently that I realized that it’s not about Open Source! I was invited as a guest speaker to an event of the Arcitecture Dept., Aristotle University of Thessaloniki. My mission was to present a short history of the free software movement / open source initiative and then present applications of open source to the arts / creative professions. I have never touched a similar area before so I tried to think as a creative professional (NOT easy, if you are a tech person!) and imagine how open source, open licenses and so forth could benefit my world.

After my experiment was over the following came in mind: Open Source helped the world get familiar with the concept of sharing the raw materials of a creation, plus know-how (if needed), allowing the community to take it to the next level. Initially, those creations were open source software and their raw materials the source code but, nowadays, we have moved past that. Books, music, video productions, hardware even games are being published under open licenses.

Supporting openness is a choice anyone can make. Following the philosophy of openness however is a whole different discussion. One that I will leave for another post 🙂

Happy birthday Linux! Happy birthday Open Source!