FOSSLC e.V. freut sich in Zusammenarbeit mit der Gesellschaft für Informatik e.V. Vertreter der großen Java Application Server in Ilmenau begrüßen zu dürfen. Vorträge über Apache Geronimo, JBoss AS, WebLogic und WebSphere versprechen einen spannenden Nachmittag mit Einblicken in die Technik der Application Server und JEE.

I prefer Peggy Lee’s version of the song to Bette Midler’s; I wonder if Mark Guzdial thought of either when he wrote this post a couple of days ago:

Surely, this can’t be it—it can’t be that Sakai + Twitter + a blog or Wiki is what all future studies will call the “traditional” form of online courses?

It’s worth checking out some of the tools he links to: there’s a revolution waiting to happen here, and I’d really like to be part of it.

Rochester Institute of Technology prides itself upon co-operative educational component of its degree programs.

Event Description

The Free and Open Source Software Learning Centre (FOSSLC) will be hosting our flagship annual conference on Saturday, August 14th, 2010. The event will take place at the University of Ottawa Campus, Ottawa, Ontario, Canada. This event will bring together industry, academia, government, and community to learn about open source. Over 30 talks during the conference will cover technical, legal, and business aspects of open source use in private industry, community, and government. This event is relevant to technical and non-technical audiences. This event is relevant to all industries as 85% of businesses already use open source today. Talks will be a mix of skill levels with emphasis on approachable material suitable for beginners making this an excellent learning opportunity.

We have chosen themes to encourage cross pollination of ideas and talent.

Themes:
1) Education using open source software
2) Business and ecosystem development using open source principles
3) Developing open source software, and developing using open source
4) Free and open source software for Geospatial systems
5) Legal issues including Licensing, DRM, Case law, intellectual property
6) Open source in Government

Read more for instructions on how to submit a talk proposal, registration, accommodations, and travel details.

                   University of Ottawa Campus, 

read more

Freeseer is open source software that lets you record presentations such as full motion demos, or slide presentations. What makes it unique is that it is capable of capturing video from a vga capture device, webcam, or camera using firewire. The following video shows you how to set up for vga capture.

read more

Whilst this blog allows OSS Watch members and guest posters to express personal opinion we don’t usually use this blog for personal items. However, I’m making an exception today to remind myself, and hopefully some others, that whilst life can sometimes be horrible it is more often than not wonderful

. 

On Sunday at 17:17 (GMT) March 7th my wife gave birth to a beautiful and healthy baby girl, Saskia Frances Gardler at 7lb 10.5 oz. Mum and baby are doing very well and are now home with a proud Dad.

I’d like to publicly acknowledge the superb  care that my wife and I received during this pregnancy. We only truly appreciate the National Health Service when we really need it, and Heidi and I have  needed it on far too many occasions over the last few years. The care we have received has been exceptional when compared to what I have seen in other countries.

I should also mention Oxford University Computing Services. I could not have hoped for a more understanding employer, it was clear from the first day that as long as I worked hard when I was able OUCS would respond by giving me as much space and time as I needed to support my family during this difficult period. I’m truly grateful to my boss Lou Burnard and to my exceptional team here at OSS Watch.

As for extended family and our friends - we hope they already understand how appreciative we are of their combined efforts in recent years.

Like I said in the intro, sometimes life is horrible, but more often than not life and the people around us are wonderful. We should never forget that in the difficult times.

Since July last year we've been holding an open source business breakfast meeting once a month. The events have been very interesting, educational, and fun. Despite that, we've decided to put the breakfasts on hold for a bit to allow us to focus on other activities. We'll share more about what we're working on soon.

[I wanted to post this on my WordPress.com blog here, but they seem to strip out <video> tags (i.e. I don't see them being shown when I click Preview, but it does on self-hosted Rumbling Edge).]

Blog post on The Rumbling Edge

I was at the Shuttleworth Foundation last Friday to receive my mesh potatoes (MP) from Steve. I unpacked the telephone equipments some days ago and thought I could easily set them up. I fiddled with the equipments for some hours before I could get them to work.  It was awesome to see the MPs connect to each other via the wi-fi link. I am currently exploring the tracking feature (Afrimesh) and the billing mechanism (A2Billing) for the MPs. In addition, I am thinking of carrying out some benchmark tests (using SIPp/IMS bench SIPp). I hope to make some contributions before the next Village Telco workshop. Check here for my previous post on the Village Telco Project.

My Mesh Potatoes (The Village Telco Project)

This post is by Patrice-Emmanuel Schmitz, Director for European institution studies at Unisys Belgium (Brussels). His team is in charge of the www.OSOR.eu (Open Source Observatory and Repository), the Free/Libre/Open Source information platform and forge launched by the European Commission for public sector projects.

Combining freedoms and copyleft in the Gnu GPL license (invented by Richard Stallman) was the cornerstone of free software. This is now questioned due to the proliferation of incompatible copyleft licenses.

After counting 1,800 free software licenses used in hundreds of thousands of projects, the Black Duck company patented (Patent US 7,552,093 B2) the technology for controlling the use of open source licensing in a multi-source development process (meaning combined works, elaborated from multiple free components under different licenses).

No need to say that patenting proprietary technology to solve copyleft licenses incompatibility may not be seen by everyone as a major achievement!

Lamenting on license proliferation or blaming new license authors – who all call upon the best reasons of the world, looks useless. It would certainly be reasonable, as recommended by Bruce Perens, to deal with only four permissive and copyleft licenses, but this is wishful thinking. New licenses are presented every week by FLOSS authors and communities, and no benevolent dictator will limit human innovation regarding licensing.

The heart of the problem does not lie in the number of licenses, but in their incompatibility. I do not think that license proliferation is a failure of the FLOSS movement, it is rather the entire contrary: a testimony of the attractiveness of FLOSS models. In reality, license proliferation illustrates the failure of a certain model of strong copyleft, as it was initiated by the GPL in the 80’ and – unfortunately - reproduced by nearly all subsequent copyleft licenses. Once necessary and successful, this model looks not adapted anymore because it was copied and - seeing the Black Duck patent - one may question (like Ernest Park has done) if the way copyleft is applied does not generate today more jails than freedom.

According to my first study for the European Commission, the Gnu GPL v2 was used in 85% of the FLOSS projects in 2001. With a copyleft that was – maliciously – said “viral” by some, meaning that compatibility is always “upstream” (to itself) and never “downstream” (to other licenses), the adoption rate of the GPL should have been universal in 2010, confirming analysts’ assumption that “it is good for the community if people use a single copyleft license [1]”. However, the exact reverse happened: the GPLv2 (reducing) is still used in 50% of projects, the new GPLv3 reaches little more than 5% and other licenses are proliferating.

The fact a dozen of licenses are used by 90% of the FLOSS projects does not help very much, as the implementation of free solutions (which are often combined works) is done through integrating many components. It is enough to find only one incompatible license to compromise the distribution of these solutions.

The current situation is damaging for other reasons: it creates endless discussions on what could be considered as integration in combined works (dynamic or static linking) and it feeds disputes. To preserve their communities from schisms, gurus and acolytes urge followers not to use any other copyleft licenses, whatever their specific merits or advantages could be. It is time to admit that the strategy of keeping a “captive asset” of license users was not successful for avoiding proliferation, and that it is not the most appropriate way to reinforce the freedom, collaboration spirit and consistency within the fragmented FLOSS world.

In Europe, the recent - OSI approved and copyleft - European Union Public License (EUPL) meets some initial successes due to its compliance with Member States’ law and because it has equal value in the 22 languages of the Union. It has been selected by the German Federal Agency for Information Technologies, it is the license of choice in schemes published by the Dutch NOiV (see on the www.OSOR.eu site an English version of this scheme, translated by a member of the Swiss administration), a dedicated EUPL site was created in Italy, etc. In Spain, the Ministry of Industry, Tourism and Commerce (where the public agency Red.es is located, in charge of information technology) provides the following in call for tenders (software specifications):

“In case the contractor integrates in the development that is the object of the contract with modules or elements owned by third parties, he must first obtain from the legal owners the licenses and rights necessary to transfer the ownership of the development to , which will submit it, including the elements that are performed under the contract (such as fonts, dll, scripts, etc..) to the public license EUPL. In any case the total and final result of the development and the overall project will be subject to a license EUPL.”

Applying such provisions excludes strong copyleft components from the delivered combined work: all original developments are allowed; all “permissive” components are allowed (BSD, MIT, etc.); all “weak copyleft” components are allowed (i.e. LGPL), but no Gnu GPLv2 (or V3) components (except if the copyright owner is entitled to dual license the component under LGPL-like terms, for the purpose of addressing the contractual specifications).

The EUPL itself has an innovative approach to solve copyleft licenses conflicts: it publishes a downstream compatibility list (to other licenses). It is allowed to integrate EUPL components in a combined work that will be distributed under a compatible license. The concept is not new, as the FSF applied it with the LGPL a long time ago. The LGPL (now LGPLv3) is convenient for software libraries aimed to produce combined or derivative works: if the library is propagated on its own, it must be under the provision of its original license (LGPL), but if the library components are part of a derivative work, this work can be licensed under another license, while the original library remains LGPL. The EUPL compatibility is exactly the same, but its copyleft effect is stronger than in the LGPL (because compatibility is restricted to a limited and published list of other copyleft F/OSS licenses). Therefore it is not a weak but – say, a “tolerant copyleft”.

Such flexibility removes incompatibility barriers and restores developers’ freedom, while keeping it in the limits of the desired copyleft effect.

While the EUPL solution may be considered as a conceptual progress, its tangible impact will stay very limited as long other copyleft licenses will not give some reciprocity: the quantity of available EUPL-ed material is quite small today, compared to the mass of components that are already available under the GPL terms. Extending the list of EUPL compatible licenses (i.e. by adding the still missing GPLv3) will not change the issue resulting from the Spanish specifications, where the government requires the facility to distribute the received combined work under the single license of its choice (the EUPL in this case).

Solving problems related to the proliferation of copyleft licenses requires setting up interoperability provisions between these main licenses. It will create, and focus attention, on a kind of “circle of trust” where the original copyleft licensing condition of a software will never be changed, but where – just to take an example – a GPL component could be part of a combined work that the recipient (let’s say the French or the Spanish government) could distribute as a whole under the provision of the copyleft license of its choice (i.e. CeCILL or the EUPL) provide these licenses are allowed in the compatibility list.

The Gnu GPLv3 includes (in its section 13) the exact provision corresponding to the above need, but it is directed to the AGPLv3 only. The intellectual effort to extend this provision in direction of a small list of interoperable licenses seems easy to deliver. The reciprocal condition must be added: in the example above, the combined work could be also (as the need may be) distributed under the provisions of the GPLv3.

This could be a way out to the deadlock where we are, due to the proliferation of incompatible licenses.

Looking for alternative? Pay a Black Duck patent license!

Patrice-Emmanuel Schmitz – www.OSOR.eu

[1] R.T. Nimmer, Legal issues in Open Source and Free Software distribution, The Law of Computer technology, Ch. 11 (1997, 2005 Supp.) (“Two different copyleft licenses are usually “incompatible”, which means it is illegal to merge the code using one license with the code using the other license; therefore it is good for the community if people use a single copyleft license (GPL)”).

I was recently listening to a FLOSS Weekly podcast (episode 100, congratulations!) interviewing Chris DiDona from Google. One of the items he spoke of that resonated with me was his/their practice of deciding who they wanted to reach and focusing on that audience even if it meant delaying or forgoing contact with others. DiBona explained that to him, it seemed Google was the place Computer Scientists go to practice Computer Science. Thus, though it would be nice to reach other people such as open source enthusiasts, their real desire was to reach computer scientist practitioners. The rate of innovative product development, focus on algorithms and performance, and more demonstrate that nurturing Computer Scientists is a key part of Google's success. Thus I found it very interesting to see the languages chosen by entrants in Google's AI challenge organized by the University of Waterloo. Read on the see the list.

read more

Karsten and I task-swapped last week – he’s been driving Fedora Insight like a storm, and I took the Summer Coding SIG… and stared at my screen for days. When I don’t understand the global picture, I have a hard time diving into the tactics that need to be executed, and instead freeze up and babble aimlessly – I finally realize that the next step was to draw out the global picture, and whipped up the video below in a 30-minute whiteboard frenzy this morning.

What we’re trying to do is a generalization – think Google Summer of Code with the “Google” replaced by “any funding organization,” and “Code” replaced by any deliverable important to an open source project. What’s the underlying model here? How could, say, the Uncle Pennybags Summer of Test Plans build on this framework?

Karsten later told me this is called a “swim lane chart” – apparently I reinvented the wheel, thinking that I’d come up with the idea of sorting flowcharts into columns by role. ;-)

Now, I’ll put out the disclaimer that this comes from my brain aggregating everything I’ve seen and heard on Summer of Code and similar programs, and that there may be bugs or missing bits in the workflow I’m describing. Part of the reason I’m throwing this video out there is to get an idea of where I’m wrong. I’m sure I’m wrong in many, many places – if a patch needs to be made, please say so!

If this sounds about right, we should Inkscape up the flow chart and type out the narration and put that document up… somewhere. Any takers, or ideas where the upstream ought to be? I’m putting it in the Summer Coding SIG by default, but am happy to migrate it somewhere if there’s a better upstream to be found.

The Fedora qemu-system-arm package provides pretty good ARM processor emulation, which can be used to run the Fedora ARM secondary architechture. This is an easy way to get started working with ARM -- for example, while waiting for your plugcomputer, beagleboard, or OLPC XO 1.75 to arrive

The previous wiki notes on using ARM with QEMU didn't cover using qemu-system-arm under libvirt management. This meant that you couldn't easily take advantage of libvirt benefits such as automatic network setup (with DHCP and NAT), the virt-manager GUI tool, guest autostart, or disconnection/reconnection to the console.

I've updated https://fedoraproject.org/wiki/Architectures/ARM/HowToQemu to include some basic notes on setting this up, and provided some files to simplify and speed up the process. Jump in and join Fedora-ARM, the water's nice!

One of the most satisfying aspects of working for OSS Watch has been observing the outcomes from introducing people and then encouraging them to collaborate on new ideas. Outcomes such as personal development and new or improved projects. The recent Dev8D event was a real highpoint in several strands of OSS Watch activity and I was inspired to have been able to observe what happened and be part of the action. Dev8D is about developers getting together and seeding new project ideas, something that is an important aspect of open development, and so is important to OSS Watch. The Dev8D team, led by Mahendra Mahey, along with everyone who participated over the 4 days made Dev8D a fantastic event. Much developer happiness was expressed both during and after the activities, not to mention the many new project ideas that were hatched.

Several coding challenges where made and our very own Sander won 2 of them with MuCoMaCo an interesting Google map mash-up of MLA library data. OSS Watch have provided continuing support services to the Apache Wookie (Incubating) project from the University of Bolton. Recently Sander recently organised a Wookie Training day at OSS Watch. This was led by Scott Wilson, Wookie project lead, and Ross, OSS Watch manager. Scott was with us at Dev8D, so it was no surprise that Sander’s winning entry was a Wookie served W3C widget. This enables it to be readily deployed in a range of contexts with little effort.

The other winning entry that OSS Watch had close connections with was Wookie BaLTI. BaLTI is a sample Moodle course by Mark Johnson and Dan Hagon and features the newly developed Twirlymol and CollabMCE widgets. These 2 widgets use the widget loading and collaboration facilities of Wookie to provide a shared 3D interactive view of a molecule model and shared WYSIWYG editing. Several threads came together to make this happen. Those familiar with OSS Watch and open development will not be surprised at how open collaboration has made this possible.

Since we spotted Mark’s announcement of his first small contribution to Moodle and subsequently invited him to present it at an OSS Watch workshop, he has gone from strength to strength. At the Dev8D awards dinner Mark deservedly one ‘Best newcomer’. An award that provided him with a small Lego car kit, which we ‘knocked up’ during the meal, and a rather handmade certificate. The point is that Mark’s enthusiasm for learning about and contributing to open development has been noticed and is sending ripples through the HE and FE communities. Mark attended the previously mentioned OSS Watch Wookie training day, which stood him in good stead for working on the challenge with Dan. Since the Dev8D fun, Mark has pledged on the Wookie lists to reimplement his editing widget without the current LGPL licensed code dependency and to contribute it to the project. Further evidence of Mark’s personal development and it’s far reaching affects comes from his recent blog post. He also supplied us with this comment.

My manager appreciates the opportunities that open development provide to us as a department and an institution, both internally and externally. By letting me go to events like Dev8D even though the things I did there don’t relate directly to my current job, she gave me the opportunity to develop new skills which will allow me to provide new facilities to the staff and students in our institution. We’ve just started an ILT working group with our teaching staff, so hopefully I’ll be able to apply some of my new skills and knowledge to the ideas that come from that.

Mark’s collaborator, Dan, was the first person I met at Dev8D, and as with Mark you can’t help but be affected by his friendly enthusiasm. When I discovered that he had created an interesting Google Wave widget I steered him towards Scott and Mark and watched the magic happen. Scott explain how trivial it was to port the widget to Wookie, and once they’d decided on the LTI challenge Scott added BasicLTI interfaces to Wookie in order to support the challenge work. These are now part of the Wookie project code. More great collaboration followed and someone gave them an Amazon cloud server to install Moodle on. I observed them working together, discussing ideas, fixing bugs and working on their ‘judgement’ presentation. I tried to muscle in on the action with another widget idea but got rather distracted and bogged down in practicalities. Still I do have some new ideas to add to Wookie at some point.

I also attended their pitch to the judges as moral support and I’m glad I did. Chuck Severance of IMS and Sakia and Steve Vickers where in the judging team. A soon as the pitch was over, Chuck and Steve rushed off to add the widget to Sakai, Blackboard and WebCT. Chuck made the point that by using Wookie and LTI it is now possible to have something running in all these platforms, and in a matter of minutes. He then distributed screen shots around various lists.

Dev8D saw many other collaborative ventures seeded or strengthened. New skills were learnt by motivated developers and new contacts made. For example I enjoyed watching Chuck and Tobias Schiebeck work on a tricky Sakai bug. Finally I’d like to mention GNOME who were running an overlapping event in London. After a bit of prodding for collaboration, Willie Walker and Brian Cameron came over and presented on accessibility and GNOME work. Both were very interested in the accessibility possibilities of “Mr gadget” Ben O’Sheen’s demonstration of software to talk to wiimotes. A representative from Dev8D also went over the to GNOME usability hackfest and I expect we will see fruitful cross pollination developing from this mutual interest. Not least is the opportunity for HE/FE developers to learn from a large, established and successful open source project.

There are many interesting open source projects that can be beneficial to academic research. As OSS Watch’s recent article on e-Research by Gabriel Hanganu shows there are social and organisational problems in adopting open source for e-Research, but there are many open source software projects there to be joined. Some projects are suited very well to be used in scientific research and I feel that this is especially true in the realm of big data databases.

Google showed the way, really, with the MapReduce paper in 2004. They published their programming model for processing large amounts of data in parallel and although publishing it, they did not neglect to apply for a patent as well, which was recently granted. Hadoop, which originates from a project at Yahoo!, also implements the MapReduce pattern, but is completely open source being a project of the Apache Software Foundation. And now recently Apache Cassandra has joined the mix. Cassandra originates from Facebook, but has become open source in July 2008. It recently promoted from the Apache Incubator and is now an official top-level Apache project.
Work has been initiated to facilitate integration between Cassandra and Hadoop, which simplified means the Hadoop database HBase is replaced with Cassandra. There has been discussion of this on the list and a feature has recently been implemented. So there’s Yahoo! working on Hadoop and Facebook working on Cassandra, and recently also Twitter has announced that it is working towards using Cassandra for their backend. Also worth mentioning is the open source implementation of Amazon’s Dynamo database which is named Voldemort. This project is used and actively developed by LinkedIn and is therefore another example of how you can benefit from the work this large company is investing by engaging with this project.

To me, this all shows that there will be large investments in NoSQL databases from major companies in the coming years, and it will all be in open source software. This means that there is a lot of opportunity for anybody who has to deal with big data to profit from this investment. All you have to is try out the software and engage with these projects. Researchers also have to cope with more and more data, so I think they have good reason to follow these developments closely and step in to benefit.

My talk at PyCon 2010 was titled “What We’ve Learned From Building Basie (and lots of other software using student labor over the course of eight years)”. The slides are up on Slideshare, and there’s video of the talk itself on blip.tv, but I thought readers of this blog might be interested in a summary.

My starting point is Joel Spolsky’s comment that, “…student projects, while laudatory, frequently fail to deliver anything useful.” Respectfully, I beg to differ: About a quarter of the student projects I’ve helped supervise since 2002 have delivered software that clients actually used, and the rest have produced something even more useful: experience. (And when I say “about a quarter”, I’m talking about a quarter of 368 people from 35 countries of origin working on 136 projects.)

To make a long story short, undergraduate students can build great software if:

1. you have realistic expectations,
2. you’re patient, and
3. you realize that “how” matters more than “what”.

Let’s take those in order.

Realistic Expectations. Most undergrads are doing five courses at once, which leaves them only 8-10 hours/week per course. Putting it another way, 13 weeks of student time is equivalent to 3 weeks of full-time work. When you’re planning projects, you therefore have to ask yourself how much you would expect a new (junior) hire to do in their first three weeks on the job, particularly if (as is often the case with students) they’d never used the tools or worked in the application domain before.

It’s equally important to have realistic expectations of faculty, most of whom are working even harder than their students. A colleague of mine once summed up professorial life by saying, “We’re here to do research, they pay us to teach, and we spend our time on admin.” Keep in mind that computer science professors care about computer science, which is emphatically not the same thing as programming. Computer science is the scientific study of what computers can do; a computer scientist’s job is to invent (or discover, depending on your philosophical point of view) new knowledge. That sometimes involves writing code, but that’s like saying that mathematics sometimes involves doing integrals.

It took me a long time to understand this, and I’m not the only one to misunderstand this. I believe very strongly that being a better programmer can help someone be a better computer scientist, but if you want any traction in academa at all, you have to remember that programming really is just a means to an end.

Patience. Your project may be the first time students have written something that isn’t just going to be marked and thrown away. It may also be the first time they’ve been in a situation where 90% right is a failure rather than an A. You must not make students feel like failures for working the way the educational system has trained them to, even (or especially) if those ways are wrong.

Aside #1: one of the best students I’ve ever had explained to me several years ago why she always left her assignments until the last possible moment. “If I start early,” she said, “I’m the one who has to ask the prof all the questions to clear up what the assignment actually means. And if I start early, the odds are good that one of the prof’s answers will mean I have to re-do something. On the other hand, if I leave it ’til the night before, I can be sure that I have a stable spec.”

Aside #2: People often ask why schools don’t teach students Git, or Haskell, or GPU programming, or mobile devlopment, or whatever else is currently cool. The answer is that the curriculum is full. 4 years × 2 terms/year × 13 weeks is 4800 hours, and every single one of those hours is spoken for. Do you want to add functional programming? Cool! What are you going to take out: operating systems or B-trees?

How Matters More Than What. When I ask alumni of my project courses what the most valuable thing they learned was, none of them name a particular technology—none. Instead, they talk about teamwork, presentation skills, code reviews, time management, prioritization, communication, negotiating real requirements with real users, and building their network and portfolio. This is why I think that efforts to teach open source are slightly mis-aimed: in my experience, students don’t care if the code is open or closed nearly as much as they care about how to build complex things. It just happens that the various open source communities are both good at that, and able to talk publicly and in detail about the mechanics.

My colleagues and I at the University of Toronto have learned a lot of other things about running student projects, including:

• How to run meetings
• How to teach students how to do code reviews
• What level of tooling is appropriate/feasible
• Accountability
• How to accelerate ramp-up
• Carry-overs from previous terms
• Importance of full-time summer work (yay GSoC!)
• Industry support
• Presentations, presentations, presentations
• Scoping and re-scoping deliverables
• Recruiting students and faculty
• How to grade one-of-a-kind projects

We’re now scaling up what we’ve learned in UCOSP, a set of undergraduate capstone projects in which students from 14 universities work together in distributed teams. If you’re interested in taking part, we’d like to hear from you.

Had a little fun today while talking with Diana about her research. She was explaining how it’s hard for her to figure out who’s an active Fedora contributor since there are so many ways and means and places (git, wiki, lists, etc) to contribute and everyone contributes in a different place (someone may maintain a lot of packages but never blog, another person may blog and never touch the wiki, etc), so I pointed out that just about everything in Fedoraland was a website with FAS authentication, so “fire up twill, scrape ‘em all down, do some text processing, and you’ll have a per-user portfolio you can analyze to get an activity count.”

8 minutes of coding and 29 minutes of documenting later, a quick and dirty solution prototype is up in the form of FAS scraper. It takes a list of FAS usernames and makes little portfolios for each user using his/her recent activity from a variety of services (so far, just wiki recent changes and packages-maintained). This isn’t meant to prototype the architecture of the code (this code basically has no architecture, it’s 11 lines long), it’s meant to be a rough demo of desired functionality. Think about making the user-portfolios themselves more query-able and you’ll have a notion of how this could be extended – it would be neat to run queries like:

1. How many people who blogged on Planet at least twice a month for the last 6 months are also frequent wiki editors?
2. Show me all the users who maintain at least 10 packages and are also members of the syadmin-test FAS group?
3. For each user with recent wiki edits to the F13 Talking Points page on the wiki, give me all their emails to the advisory-board list in the past month.

I’m sure you can think of better ones. For students (and professors), I actually think this might make a neat variant of a problem set I was once given in college.

To run it, you’ll need the python and python-twill packages (that’s what they’re called in Fedora, dunno about other distros), so this is what I think most people reading this will want to do, for easy copy-pasting into a shell script or a terminal.


sudo yum install python python-twill
mkdir fasscraper
cd fasscraper
wget http://mchua.fedorapeople.org/FAS_scraper/FAS_scraper.py
python FAS_scraper.py


You’ll get a directory full of output that looks like this. They look reasonably pretty on account of they’re straight scrapes of the html pages. This is the sort of thing I pull up to show students when I speak about what a “FOSS portfolio” looks like, so I might just use it to quickly autogenerate “portfolio pages” for the folks I’m introducing them to on IRC. And yes, I realize some of these services are likely to have better APIs to interface with than “scrape the webpage, then consider parsing the html in later versions.” I do not know what they are or where they are.

I am, lines-of-code-per-unit-time-wise, one of the slowest programmers I know, because my docs-per-line-of-code ratio is ridiculous. It’s an old habit that comes from writing APIs usable by mechanical engineers. Fighting the temptation to rewrite. Will probably cave at some point and do a more proper version than the kludge that’s up now, but… if someone takes it off my hands before then, I’ll rest easier and not stay up all night fiddling with this.

In terms of moving this forward, what actually needs to happen is for this to be re-architected into a good general-purpose python library for getting data from FAS-authenticated services. Do things like “instead of manually defining the list of FAS usernames in the code, grab the list of usernames from the actual FAS system.”

Any takers? The first thing to do, methinks, is to get this baby under version control.

It is often said that open source software will reduce costs.

Those with little or no experience of implementing computer systems assume these savings come from the fact the free and open source software does not carry a license fee. However, this is not usually the case.

Anyone who has rolled out an software solution, even in a small organisation, will tell you that there are hidden costs. These include training, support,  customisation and maintenance.

In 2005 BECTA published “A study of the spectrum of use and related ICT infrastructure costs” which concluded that training and support costs accounted for 60% of total cost for any software solution. The report also found that open source software reduced these costs by 40-50%.

Further to reducing training and support costs, open source can reduce the cost of customisation for specific environments.

It is extremely rare for a back-office software solution to be a perfect fit for any specific organisation straight out of the box. Consequently, the software needs to be customised to suit specific needs. In a closed source environment there is a single provider, or a limited set of approved providers, who can make these modifications. However, in an open source environment anyone with the appropriate skills can make these modifications, including internal staff.

As a result of this competition, market forces can often result in a lower cost for a tailored product. Just how much can be saved here depends on the customisations you need to make.

Finally, the open source culture of code sharing results in lower development costs for the software in the first instance. That is, once one user has commissioned a specific feature or configuration option the results of that work is available to all. As a result, the more a product is used and developed within any given domain, the more widely the development costs are shared. In addition to a reduction of costs open development can significantly increase the rate of innovation as it brings together great minds to collaborate on shared solutions.

Where there is no pre-existing solution to match ones needs the open developent model can be an extremely cost effective way of reducing cost. This process is examined in more detail in our document “Meritocrats, cluebats and the open development method: an interview with Justin Erenkrantz.”

We’ve just released Processing.js 0.6, and with it a bunch of bug fixes and more WebGL-based 3D support.  You can download it here, and read the full blog-post here.  We had hoped to get a rewrite of the color implementation in this time, which will bring with it some nice performance gains, but that is going to slip to 0.7.  If you’re using Processing.js, please file bugs and show us what you’re building.

From Luis Villa’s post on wiki usage in law school classes:

In my experience, wiki writing- whether the goal is inclusion in Wikipedia or not- really should be part of the law school curriculum. It is better than traditional papers for teaching basic research and scholarship, and if done well, can also teach collaboration, editing, and other writing skills. There is still a lot to learn about the ‘done well’ part, but I hope Prof. Goldman and others continue to experiment with it. They’re doing the right thing even if their students don’t realize it yet :)

Worth reading. Also worth reading for engineering students frustrated and befuddled by those annoying “contract” things: what writing a contract feels like, explained in coding metaphors (analogy actually from Alex Macgillivray, but following Luis’s blog is what led me there):

“To put it in computer terms, imagine the contract as a computer program. In each the object is to be able to interpret the words and have that interpretation drive a result. Now imagine that there is no compiler for your program and that you can’t run any tests. All debugging must be done only theoretically and in your head.”

About this time last year, I made time to sit down and blog about trends I was seeing in the job market pertaining to open source skills. This is an update after 1 year. What are the trends in the job industry pertaining to open source? Evidence indicates there are good jobs out there if you know where to look.

read more

In the closing chapter of this complex story, the intricacies of which have previously been explained in this blog, the parties in Jacobsen v. Katzer have filed a settlement agreement with the California district court. The ruling, which favours Jacobsen, is also seen as a significant victory for the FOSS community in that it establishes for the first time in the US a developer’s right to prevent their copyright and authorship acknowledgements from being removed from their code, and their right to collect damages if the terms of the licences they choose are violated. The implications for the UK are not yet clear, but there is no doubt that the outcome of this closely watched case strengthens the legal standing of open source licensing and could set an important precedent.

Fedora design guru Mo Duffy gave a presentation on Fedora at RPI, her alma mater. Slides are available from the post, and as usual, they’re gorgeous. I’m reblogging here since Mo isn’t part of Planet TOS and I thought some professors might be interested in the slide deck.

Mo’s deck does a good job of addressing a problem I often have when speaking with a group of students (or for that matter, a group of people with a wide range of backgrounds in and exposure to FOSS). How do you describe such a huge and complex space (“The Fedora Project”) without either oversimplifying things or getting bogged down in details for hours? Her presentation sketches out the broad outlines of a space (“look at the wide range of things you can do in Fedora!”) and then show examples of how to dive into details in a few of them (specific projects in specific teams).

Anyhow. There’s a Rensselaer Center for Open Source Software – this is a page I hadn’t seen beforehand, and which has some projects that seem to overlap with projects other schools in the TOS space are doing. For instance. OLPC Math (yes, RIT, I’m looking at you) or multi-touch (which is, if I recall correctly, how Seneca got started with Mozilla back in the day).

Synergy time? Luis Ibanez and Mukkai Krishnamoorthy are TOS-ers from RPI – looking at the list of TOS-ers also turns up Will Schroeder. RCOSS has a nice (and pretty darn up-to-date!) portal page, with projects – they have great talks going on, they have courses being taught… and I’d love to learn more about them, and what other schools can learn from what they’ve done. RPI folks, what’s happening in your neck of the woods these days?

The first day of the Teaching Open Source Summit (TOSS) was great. I tried catching up with what other folks at the Free Software and Open Source (FSOSS) symposium were doing, but it was not what I thought it would be. Really, I had earlier thought I would be able to do both.  But I missed out on a couple of interesting workshops at the FSOSS.  However, TOSS was awesome. I met with great people – Greg from Red Hat, Frank from Mozilla, Karlie from Webpath, Mel, Dave, Fardad and Chris from Seneca, to mention a few.

There was a lot of discussion about teaching open source around the globe. In addition, how Mozilla and Red Hat, as Open Source Software Companies, have been promoting Open Source Education was also discussed. At the end, we came up with a list of what we would like to have in TOS.

Our Needs at TeachingOpenSource (TOS)

No doubt, it was a great experience. For once, I could see the difference between a College/Polytechnic/Univ. of Technology and the conventional academia. And now, I am asking myself some questions – Where do I belong?, Where do I want to be?, Can I find a linkage between the two? I will be brainstorming on these questions in the next few days or weeks. For now,  I look forward to another great day today – FSOSS Presentations.

A few weeks ago the Storytelling Team announced CrisisCampROC here on the innovation blog. The event, sponsored by the CSI, and organized by Vickie Krauchunas of Computer Science House saw a group of 15+ students and volunteers to help work on several projects, databases, and data collection projects. Storytellers interviews with the teams at CrisisCampROC:

I’m happy to announce that Processing.js version 0.5 is now available for download.  This release fixes many bugs and adds new features, including the first support for WebGL based 3D functionality (PMatrix3D, box, camera, etc.).  Please note that you’ll need a WebGL enabled browser (e.g., Firefox nightly as discussed here) to use these 3D features.  See the changelog for full details.

Our focus continues to be on keeping the release cycles short (0.4 was released on Feb 3) as we close in on 1.0, which we anticipate releasing in early May.  As a result, now is a very good time to test your code and file bugs when you find things are wrong, slow, etc.  We work in the #processing.js irc channel.

We’re seeing more and more people doing interesting things with Processing.js, from putting it on the iPhone, to using it to teach Game Development to university students, to creating real-time interactive visualizations on the web.  It’s great to see, and we look forward to unlocking much more functionality and speed in the coming releases.

After an extensive gestation period, OSS Watch are pleased to have jointly published 3 documents on the important subject of Governance Models for open source projects. That is excellent value for your money.

The documents on our web site undergo a rigorous quality assurance process that ensure they are technically correct and well scribed. The result in this case is an comprehensive introduction to a topic that can be over looked by projects, or may cause confusion and uncertainty.

I have on several occasions heard lead developers say that if they make their code open source they fear they will loose control and anyone can update their source, leading to chaos. As you read these documents you will see that this clearly should not be the case. The project leaders remain in control, in fact they make the decisions on who the leaders are and how the project is controlled. The governance model describes how this happens.

Having a governance model in place is one of the clear marks of an open source project that practices open development. That is, it marks a project that positively encourages community engagement.

Governance models provides an introduction to the what, why and wherefore of managing an open source project.

A governance model describes the roles that project participants can take on and the process for decision making within the project. In addition, it describes the ground rules for participation in the project and the processes for communicating and sharing within the project team and community. It is the governance model that prevents an open source project from descending into chaos. This document explains why a governance model is necessary, considers some of the challenges associated with adopting a governance model in open source projects, and looks at the key areas such a model needs to cover. It also describes how to encapsulate your governance model in a governance document.

Meritocratic governance model provides a detailed insight into this common model that is lead by an elected leadership team or ‘board’. A template is provided for use by projects interested in applying this model.

The meritocratic governance model is a commonly found model in which participants gain influence over a project through the recognition of their contributions. The Apache Software Foundation (ASF) is perhaps the most famous example of a large-scale meritocratic community. The foundation operates with an almost completely ‘flat’ structure, which means that anyone willing to contribute can engage with their projects at any level.

Benevolent dictator governance model describes another popular model where one person leads the project and has a final say in decisions. Again a template is provided for projects wanting to use this model.

A benevolent dictatorship is a project controlled by a single leader. Perhaps the most commonly cited example of the benevolent dictator model is the Linux Kernel project, which is run under the direct decision making leadership of Linus Torvalds. Being a benevolent dictator is not an easy job. It requires diplomacy and community building skills, in-depth technical knowledge of all aspects of the project, and exceptional levels of commitment and dedication. However, as the Linux Kernel project illustrates, it can be very effective.

With any project, good leadership or management are vital, and these documents will help you install the basics with little overhead. If your project already has a governance model in place then these documents could help you refine it, perhaps by making it explicit. If you don’t yet have one, then these document will help you decide what model best suits your style, and quickly get it into operation.

And you can do it all without any sign of pointy hair.

After almost a month, ATI has come up with a new version 10.2 of its Catalyst (fglrx) drivers. The drivers can be download from ATI Catalyst™ 10.2 Proprietary Linux x86 Display Driver Page. As AMD is famous for doing nothing but just incrementing versions of there software, even this version doesn’t support xorg-1.7.4. But if you still want to give it a try, you can download and try installing the driver. Otherwise mesa-experimental drivers are your friend. Checkout the post Fedora 12 and ATI Drivers and save yourself from frustration

And yes, lets wait for next version of ATI Drivers

Related Posts

• News : ATI Catalyst Drivers 10.1 Released. Test them now!
• News: Will ATI Catalyst Drivers 9.12 work with Fedora 12?
• News: ATI Catalyst Display Drivers 9.9 Released
• Fedora 12 ATI Catalyst Drivers
• News : ATI Catalyst Graphics Drivers 9.11 Released

Fedora Tutorials and Videocache by Kulbir Saini.

This short demo shows you how to connect the twinkle softphone to the asterisk pbx to make voice over ip (VoIP) phone calls on Linux. Doing so can provide very attractive calls to land lines and mobile phones - one cent a minute or less is possible.

read more

Yesterday I was frustrated.  I’m teaching my open source Mozilla courses, and I happened to look at our blog planet.  Right now we’ve got more than 30 students working on various open source projects, and to look at their blogs, you’d think they were all on holidays.  I view blogging as a barometer for development activity.  “I don’t have anything to write about” is synonymous with “I am not doing anything worth writing about.”  I went around the room and asked my students why they hadn’t done the coding I’d assigned (I asked them to modify something simple in Firefox).  The answers were weak.

I’ve been teaching long enough to know that students often do the minimum required to get a grade.  And while that might be a reasonable way to get grades, it’s not going to turn them into software developers.  Software is hard.  I was commenting to Chris yesterday that a computer is basically just a box built on a system of reason you don’t understand yet.  Programming is mostly about overcoming your own limitations.  It’s creative, problem solving work, and it is something you have to spend a lot of time to get the hang of before you’re any good.

Some of my colleagues talk about students either getting it or not getting it.  I’m not sure I believe this.  I think the right way to think about this is that there are students who push themselves, and those who don’t.  I know some developers who seem to just be built for the task of thinking through these problems.  I also know that they’ve worked really hard to get to this place, and that it’s easy to confuse their ability now for something innate vs. something acquired.  Sure, you have to have certain qualities in order to get there; but the one we don’t talk about enough, which I think is the most important, is that you have to be willing to put in the time and push yourself.

While I was getting after my students, I pulled up a favourite essay of mine, Peter Norvig’s Teach Yourself Programming in Ten Years.  He’s writing about a phenomenon I don’t see as much today–the “Learn X in 21 Days!” books.  What I wanted to show my students, though, is how well what he’s saying maps onto open source development.  Here are some examples:

• Get interested in programming, and do some because it is fun. Make sure that it keeps being enough fun so that you will be willing to put in ten years.
• Talk to other programmers; read other programs. This is more important than any book or training course.
• Program. The best kind of learning is learning by doing. To put it more technically, “the maximal level of performance for individuals in a given domain is not attained automatically as a function of extended experience, but the level of performance can be increased even by highly experienced individuals as a result of deliberate efforts to improve.” (p. 366) and “the most effective learning requires a well-defined task with an appropriate difficulty level for the particular individual, informative feedback, and opportunities for repetition and corrections of errors.” (p. 20-21) The book Cognition in Practice: Mind, Mathematics, and Culture in Everyday Life is an interesting reference for this viewpoint.
• If you want, put in four years at a college (or more at a graduate school). This will give you access to some jobs that require credentials, and it will give you a deeper understanding of the field, but if you don’t enjoy school, you can (with some dedication) get similar experience on the job. In any case, book learning alone won’t be enough. “Computer science education cannot make anybody an expert programmer any more than studying brushes and pigment can make somebody an expert painter” says Eric Raymond, author of The New Hacker’s Dictionary. One of the best programmers I ever hired had only a High School degree; he’s produced a lot of great software, has his own news group, and made enough in stock options to buy his own nightclub.
• Work on projects with other programmers. Be the best programmer on some projects; be the worst on some others. When you’re the best, you get to test your abilities to lead a project, and to inspire others with your vision. When you’re the worst, you learn what the masters do, and you learn what they don’t like to do (because they make you do it for them).
• Work on projects after other programmers. Be involved in understanding a program written by someone else. See what it takes to understand and fix it when the original programmers are not around. Think about how to design your programs to make it easier for those who will maintain it after you.
• Learn at least a half dozen programming languages. Include one language that supports class abstractions (like Java or C++), one that supports functional abstraction (like Lisp or ML), one that supports syntactic abstraction (like Lisp), one that supports declarative specifications (like Prolog or C++ templates), one that supports coroutines (like Icon or Scheme), and one that supports parallelism (like Sisal).

Notice how your grades aren’t really what matters here?  Some of the best programmers I know never went past high school, and some of them went to Harvard.  It turns out that there is something other than grades that makes you good at this stuff.  I honestly believe that involvement in open source for students is one of the most critical things to doing what he describes.  How do you do some of this stuff without open source?  How do you work on projects with other programmers if you can’t get hired somewhere (no experience? no job)?  How do you get to work with programmers who are better than you if you don’t know any?  How do you get to work on large code bases after someone else has written them if you can’t access them?  How do you learn half-a-dozen languages without a need for them all?  How do you learn how to read code without code to read?  Open source might not be the only way to do what he describes, but it is the most readily available way for large numbers of students.

The last thing that happened in my day before I went home was that another student (not in my class) came to see me to ask about how to fix his Firefox debug build.  He came to me a while ago looking for a bug he could do in Mozilla.  “I want to learn, what do you suggest I work on?”  I gave him a non-trivial C++ bug in Mozilla’s XPCOM system that is causing some strange crashes.  Since then he’s taught himself a lot, started to ask some useful questions, and gotten underway on his 10 years to becoming a software developer.

What is necessary to get students to do this kind of work?  They have to want it.  They have to push themselves.  There’s not much you can do to make them do it, since no course lasts 10 years.  It’s not that there are those who are good at this and those who aren’t.  There are those you push themselves and those who don’t make the time.  Want to get good at this stuff?  What are you doing about it?

Spent the day at RIT (thanks to Karlie and Todd Robinson and their family for graciously hosting me!) working with Steve Jacobs and Remy DeCausemaker on POSSE (we’re on for June 14-18 with Chris Tyler coming down from Toronto to be one of our instructors) and RIT’s teaching-open-source-fu. As part of this, Remy and I spent the evening at Computer Science House (CSH) talking with students about how Getting An Open Source Job/Internship/Co-op Works. It was one of the best such sessions I have been to; Remy and I are both recent-enough grads to remember our student-brains and bridge a little bit of our current world (FOSS) back to our old one (school).

It was done completely off-the-cuff, but I now have a 10-slide set of slides that I think will replicate the important parts sitting as pages in my notebook. At some point I should transcribe and post them. Nagging me may help accelerate this process. ;-) This, however, was the most important section (in my mind). Here’s what we’re taught as kids. Or at least what I was taught as a kid.

In My Parents’ World – How to Do Stuff (answer: “Get A Job according to these Complex Procedures”)

1. Be interested in something
2. Study (very, very, very) hard
3. Get (very, very, very) good grades
4. Make a resume
5. Buy suit
6. Apply to jobs
7. Get introduced to recruiter
8. Get interviewed
9. Get hired
10. Do Stuff

Except that the “Do Stuff” might be… well, entry-level job, filing stuff, doing thankless gruntwork waiting ’till you could move up the ladder and really Do Stuff, you know…

In The FOSS World – How to Do Stuff (answer: “Do Stuff”)

1. Be interested in something
2. Do Stuff
3. Get hired

So here’s the thing: to your employer (according to my parents’ world), steps 2-8 in the first list are filters for the “getting hired” step. Hypothetically, your future boss can use things like grades, cover letters, etc. to figure out who’s going to add value to the project. And… all right, maybe they kinda work. And that’s about as good as you can get when Getting Hired is a prerequisite to Doing Stuff – they have to hire you before they give you access to the lab, the mailing list, the hardware, the code, and so forth.

But in FOSS-land, Getting Hired is not a prerequisite to Doing Stuff. In fact, it’s the other way around. Doing Stuff is the filter. Your future boss is waiting for you to give him/her an excuse to hire you. Not only hire you, but hire you to do something you’re already so interested in that you’re doing it for fun in your free time, and do it better. And this is not restricted to open source companies – banks need sysadmins, hospitals need programmers, robotics labs need UI designers… if you ask the question “could open source benefit this place?” and the answer is yes (and it should basically always be yes), then seriously consider offering to be the one to Bring It There.

Now, folks who’ve been around open source for a while will think this is obvious. But to me a couple years ago, coming squarely from the mindset I was taught as a kid, this blew my mind. In FOSS-land, we toss around “oh, just Do Something” as if it were the most obvious thing in the world – but it isn’t. See, steps 2-8 in the first list serve as a filter for potential employers, but they also serve as scaffolding to first-time jobhunters. You’ve never been through this process before, where do you start, how do you figure out what people value? Well, you make a resume according to these recommendations…

So if we’re replacing and reordering a whole chunk o’ steps with an extremely nonspecific instruction to “Do Something,” we’d better elaborate a little more on what that is and how you start going about it.

That’s what the rest of the evening was about.

Last week OSS Watch organised its first training day in Oxford. We got together with about 15 people to gain hands-on experience with Apache Wookie (Incubating). Wookie provides an implementation of the W3C widget specifications, so a lot of emphasise was put on building these kinds of widgets. We succeeded quite well in getting to know the spec and how to build widgets and ended the day with a nice collection of newly built widgets and even a submitted patch to the Wookie source code.

Scott Wilson, the Wookie guru from Bolton University, where it all started, started the day off with a presentation (pdf) of what widgets and Wookie are all about. Widgets are basically small mini applications that are designed to work in a small view area. Many platforms have created their own format for it, but the W3C is working on a set of specifications for it with a consortium of partners from both traditional computing and mobile platforms, which will lead to a true cross-platform standard which will hopefully lead to widespread adoption. A minimal W3C widget consists of nothing more than a config file and an HTML file, zipped up as an archive with file extension .wgt. The config file contains basic configuration such as the name, description and preferred dimensions of the widgets. The widget can furthermore include as much HTML, CSS, images and JavaScript files as one would like.

Apache Wookie (Incubating) is an application that provides a W3C-compliant widget server. You can use Wookie to deploy widgets and you can serve W3C widgets from the Wookie server in third party applications. Plugins have already been written for Moodle, LAMS, Sakai and Google Wave. Wookie also has a REST API that can be used to get, or create widgets.

After Scott’s intro it was time to get dirty. Ross handed out CDs containing the latest sourcecode of Wookie (which can be downloaded by anybody from Subversion) and prerequisites like a JDK and Apache Ant. His presentation (pdf) was about ‘how to build your first widget’. I was surprised to see that there were 10 people with Mac-books in the room, amongst 4 Windows machines and one Linux netbook. Apple surely knows how to impress the developer these days! After some initial troubles with environment settings etc. most people got up-and-running fairly quickly and were ready to build their first widget. Wookie provides handy Ant tasks for building and deploying widgets, which means that generating a hello-world skeleton widget is as easy as typing ant seed-widget and answering some questions about the name, description and dimensions of your widget. After you have started up the Wookie server using ant run you can deploy the widget using ant deploy-widget. That was it, quite easily. I must say, having moved away from Ant and using Maven2 for the last few years, it’s nice to be remembered of the powerful features Ant has to offer. Especially since Wookie uses Ant in combination with Apache Ivy, the dependency management alternative for Maven2. (To be precise, you can also use Ivy with Maven2 repositories). Ross also demonstrated how you can make use of OpenStreetMap JavaScript APIs to embed cool navigational features in your widget quite easily. You can check out his presentation (pdf) or directly check out the source code of the tutorial including the example JavaScript.

In his second presentation (pdf) Scott focussed on some design principles behind the widget specification and gave a walk-through of how you can design a more advanced widget by making use of features of the W3C widget object API and integrate with the Google Wave Gadgets API. No Wave server is needed to get this working, as Wookie can handle everything for you. Scott demonstrated a Task widget with collaboration features, that can be used by different users concurrently using State and Participants.

After the break it was high time for everybody to create their own widget and some interesting ideas had come up. One of us decided it would be much cooler to hack directly in the server code instead of building widgets and he submitted a patch to Wookie to allow hot deployment of a widget to ease the development/deployment cycle. That’s very cool, thanks Matthew!

The rest of us built some widgets for a wide variety of purposes. One of the nice things about the widgets was that we could easily merge them all together on one Wookie instance and show all widgets there. These were some of the widgets that resulted from this 1.5 hour hack-fest:

• Video player embedded in a widget with fallback to other formats depending on the user agent
• Display a list of links using output from one of the Yahoo pipes
• Display the last.fm playlist of a user and show what that user is currently listening to
• Show a canvas drawing where multiple people can collaborate by working on the same drawing using HTML5
• Cool kids’ game where the user can name his pet dinosaur
• Currency converter that (eventually) would use an external currency conversion provider

It was fun to see how easily you can create functional widgets. If you make use of external JavaScript APIs or data feeds it is also quite simple to create a useful (or not so useful…) widget. This was a nice conclusion of the day and seeing all the widgets we had created we thought we had deserved our beer and headed off to the pub. Thanks to Scott and Ross for making this a successful Wookie training day!

This time, three students from National University of Singapore are taking on Mozilla projects across various disciplines, in no particular order:

• Chris Cai (AnttyC on IRC) is working on improving Thunderbird search visualizations.
• Daniel Le Duc Khoi Nguyen (Libras2909) is fixing ‘non-trivial’ and/or ‘enhancement’ bugs.
• Simon Teo (Simon or Nomis) is working on converting Litmus tests to Mozmill ones.

Feel free to say hi to them if you spot them on IRC!

This is a guest post by Gaganpreet Arora AKA bitgeek.

My Facebook app list was cluttered with useless apps accumulated over the time I had joined Facebook. The worst thing is that Facebook does not allow you to remove multiple apps in one go. You have to select one, confirm on “Are you sure?” first and then click on “Okay” when it is deleted. Very cumbersome. So I wrote a Javascript hack to remove all of the apps in one go.

Warning: This will actually delete all the apps

Step 1

Go to: http://www.facebook.com/editapps.php?v=allowed.

Step 2

Select and copy the complete code below and paste it into the address bar.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

javascript:
function postwith (to,p) 
{

 var myForm = document.createElement("form"); 
 myForm.method="post" ; myForm.action = to ; 
 for (var k in p) 
 {
   var myInput = document.createElement("input") ; 
   myInput.setAttribute("name", k) ; 
   myInput.setAttribute("value", p[k]);  
   myForm.appendChild(myInput) ; 
 } 
 document.body.appendChild(myForm) ; 
 myForm.submit() ; 
 document.body.removeChild(myForm) ;

}
 
function getElementsByClassName(classname, node) 
{ 

 if (!node) 
 { 
   node = document.getElementsByTagName('body')[0]; 
 } 
 var a = [], re = new RegExp('\\b' + classname + '\\b'); 
 els = node.getElementsByTagName('*'); 
 for (var i = 0, j = els.length; i < j; i++) 
 { 
   if ( re.test(els[i].className) ) 
   { a.push(els[i]); } 
 } 
 return a; 

}
 
var arr = []; 
els=document.getElementsByClassName('app_row'); 
arr['fb_dtsg']=document.getElementsByName('fb_dtsg')[0].value; 
arr['remove'] = 1;  
arr['post_form_id_source']='AsyncRequest'; 
arr['post_form_id'] = document.getElementById('post_form_id').value; 
arr['app_id']=els[0].id.replace("editapps_allowed_","");   
arr['__a'] = 1; 
for (i=0; i<els.length; ++i) 

{postwith("http://facebook.com/ajax/edit_app_settings.php", arr); arr['app_id'] = els[i+1].id.replace("editapps_allowed_","");}

Step 3

Press Enter.

The browser may get stuck for a few moments if the list is large, so if it does, just wait a bit and it will respond back.

References

Function postwith was taken from here, and getElementsByClassName was taken from here.

Related Posts

• IntelligentMirror: RPM and DEB Caching Improved (0.5)
• How To: Install Javascript Plugin in Eclipse
• Hack: Mange Fluctuating Wireless
• Hack: Mail Filter – Shell Script
• Hack: Graphical Implementation of CP Command

Fedora Tutorials and Videocache by Kulbir Saini.

Dear students involved in Fedora, Sugar Labs, OLPC, and/or any other open source project:

Please take a minute to explain to people with fancy titles why you are awesome.

That is all. I hope to see some of you in Boston in April spreadin’ the good news.

The layoff of Willie Walker by Oracle is causing consternation in the the open source accessibility world, and for good reasons. As lead of GNOME accessibility and head developer of the Orca screen reader for the blind, Willie is a key member of GNOME accessibility. GNOME itself is a key player in the open accessibility field. The recent OSS Watch briefing note on open accessibility identified the importance of GNOME’s position and it’s contribution under the leadership of Willie.

Until this fallout from the recent takeover of Sun by Oracle, Willie was employed by Sun to work full-time on GNOME accessibility. The removal of Willie’s salary has removed a critical source of funding for open accessibility and the community is reeling as a result.

However despite the understandable concerns for the future of both Willie personally and GNOME accessibility, this is also a opportunity for both. People like Willie are highly sought after by employers who value leadership skills coupled with excellent technical experience. A couple of people described Willie as the Linus of open accessibility, a simile that has some merit. We can hope his next employer (or funder) will allow him to further develop his passion for accessibility, building on his impressive legacy to date.

For the GNOME and open accessibility communities, the impact of this seemingly crass business decision also causes us to focus hard. It can be a catalyst for improving the sustainability of this small but effective community as Willie himself indicates. I’d like to explore the subject a little in this post.

In general people get involved in open source for selfish reasons. These may be personal needs, corporate motivations or academic interests. The power of open development comes from working together to develop and maintain a common resource that benefits all players. The famous phrase is ’scratching an itch’. When it comes to open accessibility, however, there is an extra dimension. While many members of the community are users of accessibility, others are not and are involved for more complex reasons like social concern, if not quite altruism. This leads to members being in a position of “scratching another person’s itch”. There are elements of accessibility being a basic human right and these colour the community relationships and explain some of the strong outraged reactions to Willie’s layoff. As an aside it’s worth recalling Sun’s significant contribution to accessibility, something that was obviously not core business for them.

The fact that community members are in it for largely selfish reasons means they are likely to leave for equally selfish reasons. There should be no surprise at that. The key is to develop a broadly diverse community that can sustain any individual member’s exit. This is the opportunity I see we now have. I hope that Willie will continue to work full-time but I also hope we will work hard to attract more members who will also bring resource with them. Many of the reactions have vocalised the need to find funding but I feel we should focus on building the community first and the funding will follow. We also need to build community as, to be frank, there is a huge amount of work to be done, as can be seen on the GNOME 3.0 accessibility roadmap.

That might sound rather glib and the question is how can we move forward and encourage? Building community is difficult and not a science but there are many good examples to learn from. I’m fortunate to work for OSS Watch who’s key message is open innovation through community. Ross Gardler our service manager is also Vice President of Community Development at The Apache Software Foundation. The Foundation are also highly experienced in community development. Their informal moto is ‘Community over code’ and most of their activity is community building. For example the Apache Incubator helps projects develop their community and graduation requires at least 3 independent comitters to have joined. So there is a wealth of experience available to tap into and I’d like to see how the open accessibility community can use this to become more sustainable.

On to some practicalities. We are already seeing signs of the community dusting itself down and moving on. Eitan posted yesterday on further plans for the GNOME accessibility ‘hackfest’ at the CSUN accessibility conference. CSUN is THE accessibility conference and this year GNOME joins Mozilla in having a booth. This is the perfect opportunity to introduce GNOME’s work to the #CSUN10 visitors and encourage users and companies to engage. If you are going to CSUN be sure to find the booth and meet the team. The hackfest is the place for other developers to come along and learn what the code looks like and what needs doing. If your are a GNOME, KDE, Linux or Linux Mobile developer you should look us up to find out how to make your program accessible or how to work on accessibility programs.

This year the winners of Projects:Possibility’s SS12 open accessibility coding competition have been invited to attend CSUN. They will look around and present their winning projects. Accordingly computer science students from CSUN, UCLA and UCS will be able to learn about GNOME accessibility and find how they can engage in the action. At a minimum they will take their knowledge of GNOME to their future employers.

In a couple of weeks the GNOME Usability hackfest is in London and overlaps with the Dev8D developers days event. Cross fertilisation is planned and given that accessibility may be viewed to be a part of usability there is another opportunity to explore how to support GNOME accessibility.

OSS Watch have developed a tool that will be useful for exploring the sustainability options for GNOME accessibility. It’s part of our forthcoming Software Sustainability Maturity Model and provides a Q & A on the areas that need to be be covered in order to reach open sustainability. I encourage community members to try it on their project or the community as a whole. It will help focus on the the gaps and provide a common language for discussion of the solution. The form provides detailed explanations and the results are presented as percentages. If you are not sure just leave it as “don’t know”. Results are likely to be cleared at some point, so if you want to keep them drop us a line and we will provide a copy.

So in summary the news of Willie’s layoff is a source of considerable concern for him personally as well as the GNOME accessibility and the wider communities. It is also an opportunity to move on and develop new strengths through open development. The community has previously survived funding loss (IBM) and a key player leaving (Bill Haneman). As Willie says in his email - spread the word far and wide. The time is good as there is not only growing interest in open source in general but also a widening awareness of the benefits of open accessibility. If you are a member of the community then you can start thinking about how to reach out. If you are not yet a member then do introduce yourself at one of the events or on the lists or IRC.

I admit it, I picked up a funny domain name.

Allegheny College has a Freshman Seminar series where students engage in writing and speaking exercises that explore a subject in the context of the liberal arts. Darren Miller (Art faculty) and I linked our seminars (mine is titled Technology and Activism, his is Art and Activism) so that we would come together as a large group on a regular basis, while breaking apart into smaller sections for discussion and debate on related but different themes.

The role of openness plays a critical role in my course. Every text I required was Creative Commons licensed, and we will be talking about the Commons (as well as notions of openness in software) throughout the course. This is, in part, because contributing work to the Commons is a kind of activism. Further, we wanted to introduce our students to the tools that open communities use to communicate and enact change in the world. The first tool we introduced them to was the weblog.

I was surprised at how few students were familiar with weblogs. Clearly, an assumption on my part that all of my students today have at least five blogs and seventeen Twitter accounts. Who knew? So, there are now 40 new bloggers in the world. (They also learned what an RSS reader is.)

To do this, though, we didn’t use private blogs in Sakai. Instead, I set up a Wordpress-mu instance, and created accounts for them. The best part?

http://act.ivism.org/

OK, so it’s cheeze. But it’s some damn good cheeze.

I have aggregated all of their blogs at

http://act.ivism.org/planet.xml

which is managed through the magic of rawdog.

I’ll write more later, but I’m leave with the teaser that I’m very excited about our tie-in that we managed with Mel Chua, one of my POSSE wranglers last summer, now member of the RH Community Architecture team. She’ll be visiting later this term, and we’re going to do some Great Awesome with the students. At least, that’s our intent. Forty students will be introduced to the goodness of Fedora, but not in the way that you’d expect…

On the OpenCast Matterhorn developer list the following question was recently posted by Rudiger Rolf:

we have a release of Matterhorn now, and people start to use our system and they need support. I’m sure that many of us are willing to help these adopters, but in which way should they communicate with us?

This prompted a discussion I have seen many times, and so I was prompted to post my response here.

In my opinion there are two main reasons why someone would support a user:

1. they are selling services
2. they want to improve the quality of the product

Financial transactions should be divorced from community activity and thus, from a community perspective, we are left with those wanting to improve the project (I’ll return to paid support later though). People providing support in the community have two main objectives:

1. increase the number of users
2. understand the problems users are facing in order to improve the product, to attract more users

Increasing the number of users will ultimately increase the number of contributors (bug reports, feature requests, documentation, user support etc.) and eventually developers (code improvements). Thus attracting users is a key part of creating a successful open source project.

However, not all users will become contributors, and not all contributors will become developers. In fact, the numbers of people progressing along this scale of contribution is very small. Nevertheless, just one contributor is a reduction in the centralised cost of development and thus a step towards sustainability for the project.

For some people the idea of free support for a growing number of users appears to lack scalability. They ask “if we are attracting users at a faster rate than contributors/developers how does the project continue to provide support? Surely there is  a danger of too many resources being devoted to support and not enough on development.”

These are common concerns in a growing project. However, these assumptions ignore the fact that some people are willing to pay for support. The ideal solution is to provide a user support mailing list along with supporting documentation. There is a need to encourage everyone to assist with these community support channels. This channel should become the place where the not only users get support, but also where those providing paid for support seek support themselves. However, support provided from the project community is provided on a voluntary basis and therefore no guarantees of service are provided. The message is clear, if you want guarantees of service then you need to pay for it.

Of course “paying for it” may not mean in cash. For example, if an organisation is known to provided paid for support but they also provide resources for project management, documentation, code or some other contribution they are earning “credits” to get support themselves.

Over time, the number of “first level user support requests”grows. However, the number of people able to answer these questions is also growing, lets not forget that some of those users are still around and are now indebted to the support community. Furthermore, since a healthy project encourages people to contribute early by documenting their experience in FAQs and getting started documentation there is an increasing amount of support documentation for newcomers.

This self-help culture enables core community members to focus on bug reports and feature requests rather than first level support requests.For those users who need a fast turnaround on support requests, they will have to pay. They may contract a third party or they may use local resources to set up a local support infrastructure.

If these paid support providers are smart they will reduce their own costs by interfacing with the wider support community via the project support lists. They will both consume and produce commons support materials in the project. They will also recognise that visibility in the community support channels is a form of marketing for their paid-for services. And this is where the virtuous circle finally closes.

This is the third in our series on Asterisk. This article will cover enabling asterisk to record calls. You may want this to interview people over the phone, podcast, or some other purpose. Read on.

read more

In the past, we've been given feedback that as an organization supporting open source and open standards we should not use certain technologies. Adobe flash, and Adobe Air have been two notable examples of this. For some, this issue is black or white... if you want to reach people on the web, flash is a big part of doing so. Conversely, those advocating open standards note the risks and damage caused by using technologies encumbered by patents and royalties and thus push strongly for free alternatives. It is thus interesting to see what Adobe has to say on the matter. Read on.

read more

I have seen people, most especially academics, ask me the following questions.
1) Why can’t I implement session mobility using Mobile IP or Media Independent Handover (MIH)?
2) Who needs session mobility?
3) Why did you choose to use SIP?

Having done an extensive literature review and got a number of papers (in a journal and conf. proceedings), I can now say that my answers to the questions have always been right. Once again, these are my answers:

1) My work is an “application layer solution” for HTTP/Web session mobility. I don’t work at the lower layer(s) of the OSI layers. Mobile IP and MIH have been used to achieve terminal mobility at the lower OSI layers. My work involves moving web sessions between PCs, but not moving terminals (mobile nodes) between access points. That is what Mobile IP and MIH can help you achieve, and it’s called terminal mobility.

2) The work offers solutions to problems faced by the regular Internet users. I explained what the problems are using two use case scenarios here. Most of us (the regular Internet users) often do one of these things: 1) send a URL to a friend in an e-mail or through the Instant Messaging (IM) service when we want him/her to take a look at what we are viewing online; 2) save a URL in our e-mail/diary with the intention of continuing with what we are doing somewhere else. Interestingly, many software companies, such as Mozilla and Google, are introducing new products/services to address the problems. Examples are the Mozilla Weave and the outdated/de-supported Google Browser Sync. What I have done in my work is to make a person send a URL from one browser (or PC) to the other without using a third-party service like IM or e-mail.

3) It’s obvious that HTTP without being extended can’t deliver the services desired in this present day. That’s why it’s been patched to provide the services. Mozilla Weave was once using WEBDAV (an extension to HTTP). In another sense, cool tools like AJAX, Restful APIs have been introduced in order to provide those new services – Rich Internet Applications. HTTP User Agent (UA) can either be a client or a server, but not both. Hence, it had to been extended to do both. The case is different in SIP in which its UA is both a client and a server. Software firms are now relying on protocols like SIP and XMPP to offer some appealing services. An example is the Google Wave, which uses XMPP (Draft Protocol Specs here). I also chose to use SIP in my project in order to gain the instant messaging and presence capabilities in SIP.

I am happy to answer other related questions or provide more information on the work.

CAS stands for Converged Application Server. It is the controller for the TransferHTTP extension, and I blogged on it sometime ago here. The controller, also known as the proxy, is called CAS  because it provides two endpoints (a SIP endpoint for the signalling and services and an HTTP endpoint for the services administration). Below is the User Interface (UI) for setting policies in the work. The policies include web session mobility blocking and forwarding policies. In web session mobility blocking policies, users could add SIP URI they would not want to accept a session transfer from; while in web session forwarding policies, users could forward (i.e. redirect) a session transfer request to any of their PCs.

User's Policies Interface

Below the user’s policies (in the above figure) are registered SIP URIs of the user. Those are the URIs at which the user could be contacted.  The log in credentials (SIP URI and password) will be required to connect to the server. Here is the client interface – http://transferhttp.mozdev.org/screenshots.html – where the user will enter the credentials.

I already have a number of things under future work. These include extending CAS to support buddy list with presence and extending the TransferHTTP extension to support an address book.

I finished up some work today on the Processing.js automated test tools.  Previously I wrote a test harness to allow JavaScript based unit tests, as well as parser tests.  However, after watching some of my students struggle through bugs during the lead up to their 0.5 release, I decided we needed a way to also be able to write them in Processing.  Right now I see a lot of tests being drawn into sketches, and then manually comparing results.  It’s sub-optimal to say the least.

Having written the unit test functions already, I decided to simply load them into Processing via a library.  Processing.js, like Processing, has the capability to load “native” libraries.  In Processing.js, such libraries are JavaScript functions written like so:

(function() {
  Processing.lib.Foo = function() {
    this.something = function() {...};
    ...
  }
})();

Then, in your Processing.js sketch code, you initialize the library by calling its constructor (e.g., Foo();), and then any function (e.g., something();) will be available to your code.

Using this technique I added the same set of _check* functions already available to JavaScript unit tests, such that I’m now able to write small unit tests in Processing like this:

// Tests for Processing str() function - http://processingjs.org/reference/str%28%29
boolean b = false;
byte y = -28;
char c = 'R';
float f = -32.6;
int i = 1024;

_checkEqual('false', str(b));
_checkEqual('-28', str(y));
_checkEqual('R', str(c));
_checkEqual('-32.6', str(f));
_checkEqual('1024', str(i));

I’ve fully documented the setup and use of the new automated testing features. All Processing.js developers (especially my students), should read through this. Beginning with the 0.6 code, we’ll start using this by default for all regression and API testing.

Registration http://tinyurl.com/CrisisCampROC Spread the word

The announcement about Symbian going open source made me watch an introduction video flagged by my colleague Rowan, who has written about open source in mobile devices.

What I heard, among others, was that developers are encouraged to contribute to the open source platform, and in the final section (3′45″) that Symbian’s governance model allows virtually anyone to be part of the working groups and councils and have a say about their future direction. This looks good, I thought, let’s check further.

There is a wealth of information on Symbian’s developer site, including another video suggesting how users and developers can get involved.

The contribution process includes both general issues about contributing source code and more specific ones, such as how to contribute a fix, an enhancement, an extension, or how to start a new Symbian-related project.

In a nice piece on the wiki I also found things very much in the spirit of how we talk about open development and the process of building open source communities:

“Contributors are also users (which is one reason why they are motivated to meet the needs of the users) but contributors want a say in the roadmap so that they have a chance of influencing it in directions that benefit them and they want to be able to get their contributions accepted into the project. Contributors may provide code for bugfixes and new features (the most obvious form of contribution) but they can also contribute support services, translations, documentation etc.”

Community-wise this looks like a nice step to open source for Symbian. Let’s wait and see.

For those in academia: I’m wondering whether this might be the kind of mini research problem (or even non-mini research problem) that university students might be excited about picking up.

From Matt Domsch’s post to the Fedora advisory board list:

I’ve spent quite a bit of time over the last week fixing up the scripts that generate Fedora’s worldwide user maps including the worldwide map for all Fedora versions currently in use as determined by yum requests for mirrorlists… we currently have no way to know, within even a 2-4x margin of error, how many current installs of Fedora there are. But this number, and it’s growth (positive, or negative), would be interesting to know, if only it were more accurate.

Now… it seems to me that this is an interesting technology-related problem requiring technical fluency, development of keen analysis skills, and with immediate potential real-world (i.e. would-actually-affect-the-work-of-thousands-of-people) implications. And it also seems to me like it would fit nicely into the format of an independent study or a small thesis – actually, my first reaction (before starting to think about potential solutions) was “huh, this is something I could work on, write a paper about, and turn in for school, if I were still in school.”

Thoughts? Would these sorts of “huh, we wonder how we’re doing on this front?” introspective semi-research-ish questions coming from open source communities make good material for student projects (independent research, class projects, whatever format it would fit in)? If so, how could we help students get started on them? If not, why not – and what sorts of problems would be better?

JGrass, present and future by Andrea Antonello, Silvia Franceschi

read more

This story is very interesting given it's significance from both an open and closed source perspective given the high performance and disruptive potential involved.

read more