Wednesday, 31 July 2013




Early research process. Mapping up our domains and sorting them on time and category

Monday, 29 July 2013

http://opensource.com

Stumbled across Opensource.com.
The interesting thing about this website is that it constantly opens up and demands debates on all issues surrounding Opensource, from the ethics, to ways it can be integrated into society, its limits, and also interviews with major leaders of the open source movement.

Heres a video to check out when you have 17 minutes to spare also!

http://www.youtube.com/watch?v=bLGTrz1Zolk

maybe we could watch this in class today?

Unavoidable Questions about Open Source

Unavoidable Ethical Questions About Open Source

These questions follow the Markkula Center for Applied Ethics "Framework for Ethical Decision Making."
From a Utilitarian Perspective
Questions about the greatest good vis-à-vis open source software mirror larger discussions about intellectual property protection. Is human knowledge advanced by full and free access to all information, allowing engineers and developers to correct and improve on already existing systems? Or does a lack of strong protection for IP discourage innovation by removing the financial incentive for developing it? What is the balance of these potential benefits over these potential harms?
From a Rights Perspective
According to the Free Software Foundation, free software “is a matter of liberty, not price. To understand the concept, you should think of ‘free’ as in ‘free speech,’ not as in ‘free beer.’” Classically, free speech is understood as a right, but is this a useful way to think about open source software? Is there anything in the nature of software that would give people a right to it in the same way that we have a right to speech?
From a Fairness Perspective
Is it fair to expect software developers to create and distribute their intellectual product without restrictions while we do not expect the same from other inventors or producers?
From a Common Good Perspective
The Vatican document “Ethics in Internet” argues that “use of the new information technology…needs to be informed and guided by a resolute commitment to the practice of solidarity in the service of the common good.” Flowing from this view, the document says that “cyberspace ought to be a resource of comprehensive information and services available without charge to all, and in a wide range of languages. The winner in this process will be humanity as a whole and not just a wealthy elite that controls science, technology, and the planet's resources.” Is this view applicable to software as well?
From a Virtue Perspective
Richard Stallman, often called the founder of the free software movement, has argued that “for beings that can think and learn, sharing useful knowledge is a fundamental act of friendship. When these beings use computers, this act of friendship takes the form of sharing software…. This spirit of goodwill—the spirit of helping your neighbor, voluntarily—is society's most important resource. It makes the difference between a livable society and a dog-eat-dog jungle.” But to others, “sharing” software is like having to consent to its theft because the sharer is giving away someone’s work product, which is the result of sweat and ingenuity and which has monetary value, as well. Will open source inculcate the virtues of friends or of thieves?

Open Source Communities


10 secrets to sustainable in open source communities


Elizabeth Leddy gave the next talk I attended entitled, Wish I Knew How to Quit You: 10 Secrets to Sustainable Open Source Communities. Elizabeth works with Plone but wasn’t really involved in open source until about five years ago. With open source we often start by working at a company that supports a specific open source application and there are two paths we can take. One path is that you start to get annoyed with the way things are going and so you jump to another open source project. Or you can get involved in the open source community so thoroughly that you can move from one related company to another (this is what I have been doing with Koha so I totally understand this path).
The goal of Elizabeth’s talk was to make sure we all create loving communities like the one around Plone. When picking your community you should think about what you want to get out of it and what you want to contribute. Open source isn’t just about code. The people in your open source community (if you’re like Elizabeth or me) are the first people you say good morning to—you wake up and get on IRC and say "Hi" to your family. Elizabeth said that she sometimes wakes up and feels like she has 400 brothers... I totally agree... but I’d change that to ‘siblings’ :)


#1 Make plans

When developing your community you have to make it clear that you’re in it for the long term. You need a plan for marketing, legal issues, documentation code cleanup—and much more!
One problem communities have is that they hold one person or a few people up as the experts in the community and the fact is that they might one day go away so you need to create a leadership pipeline (something I think Koha is good at). In addition to the fact that these people might go away—you really want to help new blood jump in to leadership roles. Also you don’t want to burn people out! You need spread the wealth.

#2 Break plans

In addition to creating plans, you have to break plans! Don’t get so stuck on your plan that you don’t embrace change.
Make sure you keep metrics to see what’s going on in the community. Bad sentiment is hard to combat. Counter attack that by measuring community success like you would performance and share that info (I think of Chris Cormack’s Koha stats sharing with each release).

#3 Think globally / Act locally

Remember that there is going to be a language barrier! Many people to speak English, but they don’t prefer it. This means that people might take longer to reply on a mailing list because they’re translating and trying to decipher what’s being said. It also means that tone in things like flame wars might get lost on these community members.
One way to handle this is to provide multiple language channels—on IRC, mailing lists, websites, etc. Also you can encourage local symposia so that people can learn about the software in their area and don’t have to try and travel.
At the very least make sure that your 'how to contribute' documentation is translated into several languages! That way people around the world can contribute to your project in the way you want.
Diversity isn’t just about accepting women! It’s about accepting people of different nationalities, genders, backgrounds, companies, etc etc.

#4 Communicate

Offer to mentor new people. Always give feedback instead of just replying with +1! Ask your community members for code reviews so that you can get better—and if others ask for reviews help them—in the end you all make the product better. Remember to thank people—especially the people behind the scenes who are doing things like managing your domain name or hosting your mailing list.

#5 Culture

We have to think about culture. "Culture is best perpetuated in person"... but most open source happens online. So coming up with as many ways to meet in person can really help your communication and community growth.
Remember to be transparent. Work in groups on new developments so that here is more trust. Nothing can be implied or assumed—you have to share everything out in the open so that the community knows what’s going on. You can also find people who have maybe disappeared and reach out and ask them what’s going on—it might be as simple as life has gotten hard for them and they’ll appreciate the support—even if it’s just beer delivered to their doorstep.
In person meetings shouldn’t focus just on code—more importantly we want to educate the new people, we want to hash out the problems while you’re in person. Getting people to participate is more important than fostering observers... if the focus of an in person meet up is on producing code you might end up with this.

#6 Stop recruiting developers

There is a lot of stuff that has to get done in a long term project that does not include code. Things like marketing, business, documentation, legal, and fiscal issues. For Koha all the documentation for users was written by librarians (not developers).

#7 Redefine 'participate'

Make sure it’s not just development.

#8 Governance

Think twice before contributing to a project without non-profit foundation. Koha has seen this problem... but at the same time I’m not a fan of absolutes (never/always) so I of course contribute to Koha and always will even while we figure out the legal issues that a foundation could help us with.
Foundations can also help with conference planning, fundraising, infrastructure—they don’t have to have any say in the technical decisions if you don’t wan them to.

#9 Lose control

Have diverse, self policing redundant teams. Other projects do have tight control and work just fine, but having groups means that one person can drop out and you don’t end up scrambling to fill the spot.

#10 Be awesome / Expect awesome

You’re responsible for the energy you bring into the room! The tone of your voice and how you treat people will effect everyone in the community. Thank you Koha family for having an awesome energy and welcoming all new community members!!

Open source (as software)

The Open Source Definition


from - http://opensource.org/osd


Introduction

Open source doesn't just mean access to the source code. The distribution terms of open-source software must comply with the following criteria:

1. Free Redistribution

The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.

2. Source Code

The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost preferably, downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed.

3. Derived Works

The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.

4. Integrity of The Author's Source Code

The license may restrict source-code from being distributed in modified form only if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software.

5. No Discrimination Against Persons or Groups

The license must not discriminate against any person or group of persons.

6. No Discrimination Against Fields of Endeavor

The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

7. Distribution of License

The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties.

8. License Must Not Be Specific to a Product

The rights attached to the program must not depend on the program's being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program's license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution.

9. License Must Not Restrict Other Software

The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software.

10. License Must Be Technology-Neutral

No provision of the license may be predicated on any individual technology or style of interface.

Tuesday, 23 July 2013

Authentication in the digital realm is becoming less and less secure as 'hackers' are finding alternative ways to gain entry to 'secure' accounts.

Within the cells of any organism is a substance called Deoxyribonucleic Acid (DNA) 
which carries the genetic information of a cell. This is completely unique to each individual - which can be important for identifying that you are in fact you.

Using DNA as a form of authentication is at this stage entirely conceptual, but experts have said that it could become very common in the foreseeable future.

see: http://tinyurl.com/mhwc99b