Open Source Blog

Archive for the ‘Google Open Source’ Category

Ed. Note: You may recall that last week we published the first installment of Emil Ivov’s report on SIP Communicator’s participation in Google Summer of Code™. This week, Emil shares more of the project’s 2009 success stories and lessons learned by the project over the past three instances of the program.

Geek Communicator

Linus Wallgren from Sweden completed a task that many of us have been dreaming about for a long time now: handling SIP Communicator entirely through the command line. So what exactly does this mean? Well, now, you can exit the application, hide or show it, send or receive messages, make or answer phone calls and open or close chats, entirely through the command line. So, you remember that super script that you always wanted to do? The one that sends a message to all your online friends at 3 o’clock every morning? You can now do it thanks to Linus! His work is going to be integrated into SIP Communicator some time this year so stay tuned!

Geek Communicator: Using SIP Communicator through the Console

Setting Your Own Avatar

Shashank Tyagi from India was accepted for the “Dude, checkout my photo!” project. His work consisted of making sure that it was possible for SIP Communicator users to upload a new photo/avatar with popular protocols like XMPP, MSN, Yahoo! Messenger, ICQ and AIM. He first started by exploring the mechanisms supported by the various protocol stacks that allowed this, discovering a few glitches on the way. He then worked on the glue that allows the SIP Communicator protocol modules to export this functionality to the rest of the application, and the GUI. Finally, with some help from his mentor, he also managed to wrap up a module that allowed users to take a picture of themselves using their webcam right before uploading it. Cool, isn’t it?

Shashank’s work is definitely going to get integrated into our trunk as soon as possible. However, until then you can either test it through his SVN branch or at least sneak a peek here:

Setting Your Own Avatar via SIP Communicator

DTMF with RTP

Romain Philibert from France worked with us on the project “DTMF with RTP” which had the goal of providing an alternative transport for DTMF tones in audio RTP streams in addition to the existing SIP INFO method. The first phase of the development consisted of research on the possible approaches to solving the problem and the viability of each of the approaches was explored with proof-of-concept implementations. The second phase was the actual implementation of the chosen solution and involved refactoring existing source code to generalize it enough to also serve the goal of the project, employing the rearchitected design for the sake of sending and receiving DTMF tones as part of audio RTP streams, writing new UI to allow switching between the alternative DTMF transports, and creating unit tests to assure the correct operation of the functionality. Romain was exposed to communicating on our development mailing list where he reported his progress throughout the program, gathered feedback from members of our community and helped another contributor in resolving a common problem related to the unit tests. The source code he produced has been reviewed and currently awaits for a major redesign of the media service of our project to be finished in order to be updated and integrated into trunk.

DTMF with RTP

Impressive list, right? We’re quite happy with it

So, let’s now get to the final part and look through the three most important lessons we’ve learned throughout the past three years.

Lesson 1: You’ve Got to Have the Time

Google Summer of Code is a two-way process. Really! You take a lot so you have to be prepared to give as much. This is not a subcontracting deal where you could simply expect work to get done by itself because it is being paid for (not that this ever happens in subcontracting, anyway). Having a dedicated mentor for a student’s project is almost as important as having a dedicated student. I’ve seen very few exceptions to this and it actually comes down to the following:

1. We are dealing with students who are still learning. As eager as they are to get things done, most of them have little development experience. Therefore if left to themselves, students would tend to over-engineer, go for a dirty hack, overlook existing documentation, misunderstand the goal of the project or a bunch of other things that seem so natural to experienced project developers.
2. Three months is hardly enough time even for experienced developers to fully grasp the internals of a mature project that they’ve never seen before. It is therefore naive to expect that a student would be able to come up with a usable and integratable contribution without a fair amount of guidance.

I am far from saying that you should be spoon feeding your student or do their work for them. To make things a bit more specific, I’d say that according to our experience a mentor should be ready to spend an average of about 45-60 minutes per day working with their student. Time is rarely equally spread across the summer. Our mentors would often find themselves spending up to two or three hours a day in the beginning of the program while 15 minute chats would be enough to resolve issues toward the end of the term.

Lesson 2: Less is More

I know, I know … what a cliché! Still, it took us some time to actually realize it so I think it’s important to note this lesson. I already mentioned that in 2008 we took 15 students and that this was not our best year. Mentoring resources were of course part of the issue. We had 4 of our most active developers take up two students each. First, this proved to be quite hard for the mentors themselves. Dedicating two hours a day to mentoring may turn out to be an issue when this is not part of your day job. Second, it was also a problem for the other students and their mentors. Given that our most active mentors had their hands full with their own students, they had little time to spare giving advice to other mentor-student pairs when they needed it. This turned out to be a blocking factor on more than one occasion and there was no one happy with the situation.

In addition to mentoring resources, a higher number of students are also hard to handle by the community itself. This means that people would be less aware of the progress of every project, there would be hence less interest, less encouragement, less acknowledgment and community integration for the students.

At the end of the day, we did manage to handle things and we only had a single failed project in 2008. However, the experience was far from the pleasing memories we had from 2007. It was therefore a good lesson to learn because taking less students was one of the main reasons for a successful 2009.

Lesson 3: One Committer per Student

I believe the one-mentor-for-one-student ratio is now commonly accepted practice for Google Summer of Code and that most projects are striving for it. We definitely have done our best to avoid mentor sharing since 2008. Having more than one (non-shared) mentor per student is even better but unfortunately not always possible. Another ratio that is just as important, and probably not that popular, is the number of committers involved as mentors. Code integration represents a significant part of the effort that projects spend over Google Summer of Code. It is quite obvious that if the developer committing the work of a particular student is also their mentor, integration is going to be a lot easier than if it were someone else.

For example, we had some very valuable stuff written during 2008, like support for proxies from Atul Aggarwal. Atul did a good job, but, his only mentor, despite being very technically savvy and knowing the project quite well, did not have committer access. Proxy support is quite important for SIP Communicator, although not necessarily critical. Committing Atul’s work however, would require an existing committer to study all his work, and there always seems to be something in the critical path for development that must be reviewed. Things would have been a lot easier if one of the people that were expert in this field had been following the project right from the start.

We therefore decided to add pair each student with a committer in 2009, and each committer only had to take care of one student. The results were excellent, and as I already mentioned, we already have approx 30% of the GSoC code committed barely a week after the end of the program!

Lesson 4: Specific Tasks and Clear Conditions (Learning in Progress …)

Ok … this case is not really that straightforward and we have more learning to do before we really get it. Here’s the problem:

In 2007 and 2008, we had a couple of students who would get to 50% or 60% of their work and then get distracted with unimportant stuff or simply disappear for a while. At a point their mentors would remind them that they have more to do and this would cause the students to feel uneasy, panic, or start arguing about things, such as:

“Oh, I didn’t know I had to do unit testing!” or “I was never told this feature was part of the job!”

The statements weren’t completely false. It could indeed happen that a task would seem obvious to a mentor and in the same time feel utterly unnatural to a student. In one case, it was actually the mentor who didn’t request a task that was considered important by other community members.

So either way, in order to try and limit the surprises we decided that we needed to start every project with a list of clearly defined sub-tasks. This way, we thought, students would know exactly what they need to do and organize better. It would also help make sure that everyone on our side was well aware of the “official” project vision. Sounds neat, right?

Well, it didn’t really work out that way.. Most of the students didn’t have a problem with the new system, but then again, most of the students didn’t have problems without it either. One of the students we failed, however, claimed the requirements list had been misleading and had made them believe they could plan a few weeks off. When we told them that this would be risky they complained it was too late to cancel the reservations, so they didn’t listen … and eventually failed.

So it appears that a list of what we believe to be specific requirements doesn’t seem to change much in terms of understanding the goals of a particular project since there’s always something that could be misunderstood. Clearly, continued mentor-student communication is crucial here but it seems that we’d also need explicit there-may-be-more-to-this-than-you-think notes.

Phew, that sums it all up! Hope the lessons we’ve learned above would help others in similar situations. Good luck to all of you future Google Summer of Coders!

By Emil Ivov, Project Lead, SIP Communicator and Google Summer of Code Mentor

Go to Source

Google Summer of Code™ 2009 (GSoC) was filled with fresh faces and exciting new projects for The Perl Foundation (TPF). As I write this, we are currently in the final stage of the summer where students submit evidence of their work in a zip/tar.gz file by uploading it to a publicly viewable repository. I very much like that now anyone on the ‘net can download a file containing the entire summer of work by the student, and there is even a download count next to each file for each student!

We started the summer with nine students, but Kevin Tew was not able to work on “A prototype LLVM JIT runcore for Parrot” in the program due to external issues. He is still a core Parrot Virtual Machine developer and I hope that he can find time to work on this awesome project some time in the near future. Since Parrot is currently redesigning its JIT framework from the ground up, a project similar to this would be great for next year.

The other Parrot VM project was Daniel Arbelo Arrocha working on “Decimal Arithmetic: BigInt, BigNum and BigRat for parrot” with Christoph Otto as a mentor. Big Decimal Arithmetic basically means storing arbitrary large/arbitrary precision numbers internally in a decimal format rather than the binary format usually used. Doing this can prevent catastrophic rounding errors. If you can store numbers internally with exactly NO error, then obviously this is A Very Good Thing. Daniel worked on making dynamic PMC’s (Polymorphic Parrot Classes, or Parrot Magic cookies, take your pick) which wrap the mature and extensive IBM’s libdecnumber library. What this means is that Parrot can do arithmetic on arbitrarily large integers (BigInt’s) or floating point numbers with arbitrary precision (BigNum’s.) Financial people are very interested in these as well, since no one wants to be short-changed on their interest due to rounding error. Daniel has also been contributing patches to many other parts of Parrot and will probably be getting a commit bit soon, which is great news to hear.

Devin Austin worked on “Refactoring Catalyst helper modules“, with Kieren Diment as a mentor. This involved some “Moosification”, which means refactoring home-rolled object-oriented code to use Moose (the post-modern Perl 5 object system), i.e. less code to maintain and more features at your fingertips.

I am excited to talk about our next student, who worked on a Perl 6-related project. Carl Mäsak mentored Hinrik Örn Sigurðsson on “Perl 6 End-User Documentation Tools” (github repo) . Hinrik is working on the grok command, which is the Perl 6 relative of perldoc. With it, you can get documentation for Perl 6 functions from the spec, read the Synopses and Apocalypses, and occasionally attain temporary enlightenment. If you have a properly installed CPAN client on your computer, you can install it with cpan App::Grok.

Our other exciting Perl 6 project was Paweł Murias working on “Multimethods for SMOP”, mentored by Daniel Ruoso, the lead developer of SMOP. SMOP stands for Simple Meta Object Programming (or Simple Matter of Programming, if you are feeling snarky) and it is an implementation of Perl 6, a sister of Rakudo. Multimethods, short for Multiple Method Dispatch, is a feature where a language can determine which variant of a set of functions to call, based on the type of their arguments. One way that this becomes very powerful is that you can use wildcard arguments when you declare your multimethod, so you can essentially write many functions at once. Less code to maintain is a big WIN ! Paweł’s code is being directly merged into the mainline SMOP codebase and from what I hear, he is and will continue to be a core contributor. That is what GSoC is all about. That and free t-shirts.

Pascal Gaudette worked on “HTTP/1.1 Compliance Testing and User-Agent Development for the Mojo Web Framework” with mentor Viacheslav Tykhanovskyi. This is important because Mojo, one of the newest and most exciting Perl Web frameworks did not have much testing for acting correctly according to HTTP/1.1 . Part of the work of this summer has become the CPAN module MojoX::UserAgent. He has a great blog post about “State Transitions in Mojo” wherein he explains how Mojo deals with state and generated some pretty cool transition diagrams by documenting when a state transition happens in the test suite and then feeding this data into Graph::Easy.

WebKit has become often-forked and very influential open source browser engine, so it is no surprise that Perl hackers want bindings to it. Ryan Jendoubi worked on “Cross-platform Perl Bindings for wxWebKit” with mentor Michael Peters, which allows WebKit and WxWigdets, a cross platform GUI library, to talk to each other via wxWebKit. I think this was one of the more difficult projects this year, not because of the programming/algorithms involved, but because it requires getting lots of cross-platform, constantly-changing and fickle pieces of software to get along with each other. This is often like inviting zebras and lions to the same party. Messy and dangerous. But Ryan prevailed and we give him much respect and hope that he continues to maintain and improve the Wx::WebKit bindings.

I had the pleasure of mentoring Robert (Bob) Kuo this summer on his work entitled “Implement BPSW algorithm as a Perl 5 CPAN module, Math::Primality with extensive test-suite.” The Math::Primality module is already on CPAN and I am glad to announce that Bob is listed as co-maintainer and published the latest release. This module is important because the Perl 5 Cryptography CPAN modules (mostly in the Crypt::* namespace) have one, very large, very fragile dependency, called Math::Pari. Math::Pari is an amazing library that gives Perl access to the extensive state-of-the-art number theory library PARI, but to attain ultimate speed, Math::Pari pokes into undocumented internal-only Perl core internals, which means that changes to Perl internals that *shouldn’t* have any effect on the outside world can cause the entire Crypt::* namespace to break. Also, most of the Crypt::* namespace require only 5-10 functions from Math::Pari, which provides an interface to thousands of functions. Math::Primality implements the few prime-checking (primality) functions that Crypt::* modules want from Math::Pari in a small, easy-to-maintain, pure-Perl CPAN module. Bob implemented the BPSW algorithm, a state of the art prime-number checking algorithm which allows you to check if an arbitrarily large number is prime in O( log(n) ) i.e. logarithmic running time. It is actually a combination of very different prime number checks, which weed out different types of non-prime numbers. So far, no one has found a counter-example to the BPSW algorithm (even though those pesky mathematicians say there probably are), so it is the best out there currently. It is estimated that because no one has seen this algorithm fail yet, and it being used extensively from within other algorithms, that the first counter-example must be at least 10,000 decimal digits long! Future steps for this module will be to work on its sister module, Math::Factoring, which implements the remaining factoring-related functions that Crypto modules want and then use both modules as new dependencies for the Crypt:: namespace, instead of Math::Pari.

Justin Hunter was mentored by Ash Berlin on the project “SQL::Translator Rewrite” (github repo). SQL::Translator is a very popular CPAN module for translating various “flavors” of SQL to and from each other, such as Postgres to MySQL. This involved more “Moosification”, as described above. Justin also has some advice for hopeful GSoC students:

• Get over yourself.
• Understand there are people smarter than you or people better at some things than you.
• Just the same, you’re still needed.
• Just Go Ahead and Do It and find your niche.

I wish someone had told me that about 10 years ago. I would not have wasted a lot of time worrying that people would think I was stupid and starting diving into Open Source projects much more earnestly.

In total, we had a success rate of 8/9 = 88.8%, just a bit above this year’s all time high of 85%. Please join me in congratulating all these students and mentors for their top-notch work ! I can honestly say that I had much fun interacting with so many corners of the Perl community. This was my first year being an organization administrator, I learned a lot by my favorite method: sink or swim. I was handed over the magic rocket-powered surf board by Eric Wilhelm after successfully mentoring Thierry Moisan last year on the Math::GSL CPAN module. Organizing and communicating with people spread across a dozen time zones is definitely an art that I am still mastering. I think using as many mediums as possible to communication with people is key. I already use chat, email and IRC, but I wish I had done voice/skype and/or video chat with some of my students and mentors, so that everyone has a face to attach to a name.

I would also like to thank Jerry Gay for being The Perl Foundation co-pilot this year and welcoming me into the Parrot community. Your guidance in certain matters went a long way.

For anyone that would like to help/be involved in Google Summer of Code with The Perl Foundation next year, we cordially invite you to our IRC channel, #soc-help on irc.perl.org, and the mailing list.

By Jonathan Leto, Google Summer of Code Mentor and Organization Administrator

Go to Source

At Google we are doing some exciting work with SVG, including hosting the SVG Open conference, helping SVG to work on Internet Explorer, and working with Wikipedia. Make sure to check out the Google Code Blog for all the details!

By Brad Neuberg, Google Developer Advocate

Go to Source

Keeping informed in a fast moving world can be a challenge. What if you could use those moments when your body is busy but your mind is idle to catch up on the news? That’s how I decided that I would get my Android phone to read the news to me, out loud. This is doubly useful for me, because I am blind.

The Talking RSS Reader application reads articles out loud using text-to-speech. The text of the sentence currently being spoken is colored on the screen. Speech and text scrolling are synchronized. The touchscreen buttons to skip articles are right at the bottom corners of the screen, where your fingers can find them on their own. Menus and dialogs are also spoken out, so that you can “star” an item or choose a different RSS feed without ever having to look at your phone.

The application integrates with the Google Reader service, which means that articles read on your phone need not be shown to you again when you use Google Reader on another device.

It is my hope that drivers, joggers and commuters will find this a helpful tool for keeping up with the news that concerns them.

The source code for the application is available on Google code, so that anyone wanting to develop a useful talking application for Android will benefit from what I learned. If you’d like to send feedback or have questions, drop by our discussion list. Happy hearing!

By Stephane Doyon, Software Engineering Team

Go to Source

So, here we are: we have just completed our third Google Summer of Code™. Despite the nostalgia that has settled in after the end of the summer, we are all feeling very, very happy about how things went this year. While observing my fellow mentors, who are busy integrating our students’ contributions into our code base, I am tempted to reminisce about our three year history with the program and the lessons we’ve learned.

First of all however, a quick history of our participation: Our adventures started in 2007 when we were accepted into the program for the first time. I can still remember jumping all around the room when I saw SIP Communicator’s name in the list of accepted organizations. Back then we were a brand new project and this acceptance was a tremendous recognition. As it turned out later, it made a great difference in terms of popularity, credibility, and bringing new contributors both directly and, above all, indirectly.

Our first summer went exceptionally well. First of all, we had a decent number of applications, 87 to be precise, and by decent I mean not too much for the available mentors to handle and yet enough for us to have a wide choice of candidates. We received funding for eight student projects, which, as it turned out later, was also just right. At the end of the summer we had 7 successful students. During the months following Google Summer of Code 2007, we integrated virtually all the work that came out of it. We also voted and accepted two of the students as permanent committers.

Then came 2008. Once again we were all rejoicing in anticipation of a productive summer. This time we had 187 candidates and were received funding for 20 student projects. At that point, however, we started realizing how big a number 20 is and we got a bit scared. We were afraid that would be too many students for us to handle so we decided to only take 15 and let other projects mentor the additional five. It turned out later that 15 was still a bit too many – more on that later. The summer went pretty well and a lot of work got done. Once again we voted and accepted two of the students as permanent contributors and only had a single failing student at the end of the season.

This leads us to 2009, and boy was this year a good year! I can now safely say that this has probably been our best participation so far. We received a staggering number of applications: 203 to be precise. We only had around 15 mentors so it took us quite some time to go through all of them. Once we were done with the evaluations we requested 12 student projects but played it safe and decided to go with only ten, leaving the rest of the funding for other student projects. Once again, it was a really great summer. We are still in the process of integrating all the contributions and it will probably take us a few months before we are done. Even at this point, with about 30% of the work in our repository, we have already voted and accepted 2 of the students as permanent committers with probably two or three more to come in the the following months. Hip Hip … Hoorray!!!

Here’s an in-depth look at some of our 2009 projects:

Growl Notifications, and Next Generation Sparkle Updates

Egidijus Jankauska from the United Kingdom has implemented a native popup notification for the MacOS X version of SIP Communicator. It makes use of the Growl notification daemon through a new implementation of the Java bindings of the Growl API. For that purpose, Egidijus has implemented a dynamic library using Java Native Interfaces, a set of Java interfaces, and the corresponding implementations for SIP Communicator. The new born library can of course be used in other projects and this implementation has already been integrated in our source trunk.

Egidijus has also updated our package update system on MacOS X. It was based on Sparkle 1.1, and Egidijus has provided the necessary patches and documentation to switch to Sparkle 1.5b6. This work has also been integrated in our source trunk.

Egidijus has since been voted as a committer and is now part of our developer team!

Hush-hush Chats with Off The Record (OTR) Messaging

George Politis from Greece worked on extending SIP Communicator with Off The Record (OTR) message encryption. OTR provides encryption, authentication, deniability, and strong forward secrecy. Until now SIP Communicator did not have any text message encryption and our chats were often unprotected. George started with the implementation of our own Open Source native java OTR library, which can also be used in other projects. George also implemented all the message transformation functionalities and the GUI necessary for us to integrate OTR support in SIP Communicator. It is already implemented in many of the other popular instant messengers such as Kopete, Pidgin, Adium, mICQ, Miranda, and Trillian. SIP Communicator is now able to carry out encrypted communications with other SIP Communicator clients and the aforementioned messengers.

George’s implementation has already been integrated in our source trunk and George has achieved committer status for SIP Communicator with a strong approval of our community.

Storing Chat History and Contact Lists in a Database

Ajay Chhatwal from India was in charge of implementing a Database system to allow us to store all chats in a database instead of XML files. Ajay has studied many database systems, produced a comprehensive comparative evaluation on them and suggested a winner that would best suit our use case. He has then implemented a database service and a backend to provide a working database service to all the components of SIP Communicator, after which he worked on a transition mechanism that would allow transferring XML files from the old implementation into the new database system.

Once he completed his work on the history modules – yes, he still had time to hack before the end of the summer – Ajay has also coded a new version of the contact list service which now also uses the database service.

We’re hoping to vote Ajay in as a committer soon.

Recognizing and displaying remote user agents

This one was worked on by Brett Geren from the United States. The project consisted of retrieving the names of the applications that our buddies are using when chatting with us, and showing the application icons to the user. In order to accomplish this task, Brett first completed extensive research determining which of the protocols we support in SIP Communicator actually deliver such information and how they transport it.

He then defined the interfaces necessary for a new user agent module and implemented the feature for MSN, IRC and XMPP. During the second half of the program, he worked on the user interface that actually displays the remote client icon and allows users to configure the behaviour of the user-agent plugin. He also completed tests with a long list of known clients in order to confirm the way they are publishing their client name and to make sure that SIP Communicator was working with them as expected.

Ed. Note: This post is the first installment from the SIP Communicator project on their participation in the Google Summer of Code program. Look forward to even more information on their 2009 student projects and some in-depth details on lessons learned on this blog next week. Stay tuned!

By Emil Ivov, Project Lead, SIP Communicator and Google Summer of Code Mentor

Go to Source

The Open Source Programs Office’s Cat Allman will be in Columbus, Ohio this weekend for the seventh annual Ohio Linux Fest, which runs from September 25th – 27th. Cat will be speaking on Saturday the 26th about “Getting Started in Free and Open Source,” which will cover the basics of participating, choosing a project, joining a community, and more. Both newbies and veterans will gain insights about the issues that Open Source newcomers face.

This will be Cat’s second time attending Ohio Linux Fest. She notes, “I was so impressed by the conference in 07 that I’m really honored to get to speak there.” If you missed meeting Cat last time, this is your chance to hear her talk, introduce yourself, and ask questions in person.

Come see Cat talk and get started in FOSS!

By Ellen Ko, Open Source Team

Go to Source

Many Open Source projects grow too large for free services such as Google Code Project Hosting and SourceForge.net, or simply have infrastructure needs that cannot be met by those services. Where can projects turn if they need a stable hosting environment but can’t get by with the offerings available at other free hosting providers? Many projects turn to the Oregon State University Open Source Lab (OSUOSL). The OSUOSL hosts many of the world’s most well-known Open Source projects and foundations, including Drupal, the Linux Foundation, the Apache Software Foundation, and many more.

Google, through its Open Source Programs Office, has been one of the strongest supporters of the OSUOSL by providing multiple large donations which help the OSUOSL provide world-class hosting to many Open Source projects. With these contributions, the OSUOSL has been able to expand its data center and provide jobs for many student system administrators. Student employees at the Lab work closely with hosted projects to setup, maintain, and optimize hosted services. OSUOSL is able to provide system administration services and expertise so that projects don’t need to worry about the trouble of running a server and can instead dedicate time to improving their open source project.

Over the last year, thanks to funding from Google and other supporters, the OSUOSL has been able to expand many of its services

• The three OSUOSL FTP mirrors have been upgraded, and space doubled to 6TB per server
• The data center in Corvallis, OR has expanded in size to allow for future growth
• Data center power and cooling have both been increased to meet future demand

All of these improvements have allowed the OSUOSL to take on new hosted partners including Cacti, Fedora, OpenMRS, Parrot, RPM, and Sugar Labs. To continue to provide such a world-class hosting infrastructure for Open Source projects, the OSUOSL needs your help. For more information on OSUOSL donation programs and to find out how you can help support the Open Source Lab, please see http://osuosl.org/donate.

By Jeff Sheltren, Operations Manager, OSUOSL

Go to Source

Celebrating Software Free Day at Atlanta Linux Fest? Should you happen to find yourself in Georgia’s capital this Saturday, please stop in hear our very own Ellen Ko deliver a talk on Endless Summer: Create Your Own Program Based on Google Summer of Code™. Ellen will be covering topics from marketing to motivating a developer community, with a special emphasis on lessons she’s personally learned during her first year as the program’s coordinator. You can also get your questions about the program answered and meet up with fellow Google Summer of Code participants during an evening Birds of a Feather Session. We hope to see you there!

By Leslie Hawthorn, Open Source Team

Go to Source

Using CSS sprites makes web pages faster, but they can take hours to create. Neophytes to this advanced performance optimization technique face the daunting challenge of trying to grasp the logic needed to convert their existing web page’s background images into a spritified tribute to web performance. The bar shouldn’t be so high.

SpriteMe is an open source project that helps web developers create sprites in a matter of minutes rather than hours. Its main features are:

• finds background images
• groups images into sprites
• generates the sprite image
• recomputes CSS background-positions
• injects the sprite into the current page

SpriteMe is a JavaScript bookmarklet, so it runs in all major browsers. It converts the web page to use sprites while you watch, making it easy to verify that the visual layout is preserved. It lets you drag-and-drop to re-arrange the sprite suggestions any way you want. Or, you can adopt all of SpriteMe’s suggestions with one click on the “make all” button. When it’s done spriting, simply save the sprite image(s) to your server and integrate the modified CSS into your stylesheets. Try the tutorial to see SpriteMe in action.

Happy spriting!

By Steve Souders, Performance Evangelist

Go to Source

Clearly designed as a conference to start but certainly not finish the conversation, last week’s Gov 2.0 Summit assembled an impressive cast of presenters and interviewers. Key White House decision makers, government innovators and industry enthusiasts took the stage and lined the hallways for three days.

Having spent the last five years focusing on helping government adopt Open Source software and its collaboration model, my radar was tuned for explicit mentions / inclusions / endorsements of Open Source software. It appeared that leveraging Open Source software to solve some of the thornier technology problems challenging government (think healthcare and public safety interoperability) had been more implied than expressed in recent months. For the wider community looking for more signs of game change, the event provided plenty of evidence that Open Source is clearly at play.

Paul Rademacher, Google and AllForGood.org, Brian Behlendorf, White House Consultant and Richard Lin, CodeforAmerica.org

The Google-hosted reception Monday evening packed the public space at their headquarters on New York Avenue. The event was attended by private industry, publicists and social media converts, non-profit and Open Source community leadership and government attendees and offered a nice opportunity to mix it up after a day of the Gov 2.0 Expo Showcase I sadly missed. Some of the sessions however are video-archived on the web.

Lifting off in a small flurry of debate over the right hash tag for the Gov2.0 Summit, the two day Gov2.0 Summit opened with the and energy and grin of Aneesh Chopra, Federal Chief Technology Officer. Chopra earned a reputation for creative collaboration with industry in his prior role as the Secretary of Technology for the Commonwealth of Virginia and brings the same to the federal scene. Virginia’s extensive use of Open Source and open collaboration, as well as that of former D.C. CTO — now Federal Chief Information Officer Vivek Kundra, is well known.

The conference brought attendees through a whirlwind tour of recent innovation in government IT: data transparency projects like Apps for Democracy and resulting mash-ups and visualization as inexpensive and “dirty” Open Source solutions to real problems. Open Source and its exceptional benefits of open standards and interoperability were highlighted in many presentations.

Conference highlights:

• Beth Noveck provided the most comprehensive picture of what progress had been made by the new administration and its policy road map.
• Best of Show for Crowd-Rallying: Carl Malamud discussed the need to make judiciary information — data and hearings — truly public in a day where “public” means “on the Internet.” In his speech designed in part for an audience not in the room, his closing comment asserted government operating systems should be Open Sourced brought the crowd to resounding applause.
• Favorite Projects: Anything visualized — and most frequently enabled by Open Source.
• Killer App: All things Geo-spatial.
• Significant Announcement: The General Services Administration (GSA) will begin experimenting with the use of OpenID to manage identity on government web sites.

David Recordon, OpenID Foundation Board of Directors

For the seasoned government attendees, there was in reality not a great deal of new information to be had. That was, in fact, good news; as one government manager shared with me, social media tools like Twitter and GovLoop have made it much easier to stay in touch with what other agencies are up to, plus the 2009 Federal IT Strategy has been broadly distributed and much discussed internally.

The White House will release its new Open Government Directive in a few weeks and will set federal agency wheels in motion. Implementation will be challenging and require the philosophy of change to shift into gear. Industry and government seem to agree that the next non-trivial challenge to technology innovation will be procurement reform.

By Deb Bryant, Public Sector Communities Manager, Oregon State University Open Source Lab and Producer, Government Open Source Conference

Go to Source