Skip to content

Software Development News: .NET, Java, PHP, Ruby, Agile, Databases, SOA, JavaScript, Open Source

Methods & Tools

Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!

Open Source

Projects of the Week, March 17, 2014 Front page news - Mon, 03/17/2014 - 21:06

Here’s the projects that we’re featuring this week on the front page of


Wireshark is a powerful network protocol analyzer developed by an international team of networking experts. It runs on UNIX, OS X and Windows. (Looking for Ethereal? You’re in the right place. We switched names in May 2006 due to trademark issues.)

[ Download Wireshark ]

Dolibarr ERP – CRM

Dolibarr ERP – CRM is an easy to use ERP and CRM open source software (run as web php or standalone) for small to mid-sized businesses, foundations or freelancers (inventory, warehouse, order, invoice, shipment, POS, members for foundations, bank accounts…). Dolibarr is also available with auto-installers for users with no technical knowledges to install Dolibarr and all its prerequisites (Apache, Mysql, PHP) with just one package. Available platforms for such packages are: Windows, Debian, Ubuntu, Mint, Redhat, Fedora, OpenSuse, Mandriva, Mageia. Other platform can use the generic distribution. This is a modular product, than can be enhanced with tons of external modules to provide you features not available by default.

[ Download Dolibarr ERP - CRM ]


Slackel is a Linux distribution based on Slackware and Salix. It is fully compatible with Slackware and Salix but the difference is that it includes the current version of Slackware. So Slackware users can benefit from Slackel repositories. It is available in two editions, KDE and Openbox. Slackel disc images are offered in two different forms, Installation disc image and Live disc image. Slackel developed in Greece by Dimitris Tzemos.

[ Download slackel ]


JabRef is a graphical application for managing bibliographical databases. JabRef is designed specifically for BibTeX bases, but can import and export many other bibliographic formats. JabRef runs on all platforms and requires Java 1.6 or newer.

[ Download JabRef ]


SparkyLinux is a Live Linux distribution created on the “testing” branch of Debian GNU/Linux. Featuring customized light desktops, multimedia plugins and selected set of apps.

[ Download SparkyLinux ]


rEFInd is a fork of the rEFIt boot manager. Like rEFIt, rEFInd can auto-detect your installed EFI boot loaders and it presents a pretty GUI menu of boot options. rEFInd goes beyond rEFIt in that rEFInd better handles systems with many boot loaders, gives better control over the boot loader search process, and provides the ability for users to define their own boot loader entries.

[ Download rEFInd ]

Free Pascal Compiler

A 32/64/16-bit Pascal compiler for Win32/64/CE, Linux, Mac OS X/iOS, FreeBSD, OS/2, Game Boy Advance, Nintendo NDS and DOS; semantically compatible with Delphi, Borland Pascal and Mac Pascal (partially) with extra features, e.g. operator overloading.

[ Download Free Pascal Compiler ]


Our goal is to improve upon VisualBoyAdvance by integrating the best features from the various builds floating around. In order to uncompress the downloaded package, you need WinRAR or 7-Zip:

[ Download VBA-M ]

Subversion for Windows

Win32 build of Subversion. These binaries are built using Visual C++ 6.0 Should work on all flavours of Windows from Win2000 to Win8 and 2008 Server including server variants (not all tested). (1.7.x does not work on NT4 due to APR using new functions). Modules for Apache 2.2.x and 2.4.x (1.7.6 and up) is included. Language bindings are NOT tested. Source code is found at the Apache Subversion site at Code in this project is just a “Build script” and patches for VC6

[ Download Subversion for Windows ]

Categories: Open Source

Progress in person: the 2014 Buildroot Developers Meeting

Google Open Source Blog - Mon, 03/17/2014 - 20:00
The Google Open Source Programs Office recently co-sponsored the annual Buildroot Developers Meeting at our office in Brussels, Belgium.  Read more about their meeting below.

On February 3rd and 4th, the Buildroot project held its Developers Meeting at the local Google offices in Brussels. Buildroot is a tool that allows users to build embedded Linux systems by cross-compiling all necessary libraries, applications, the cross- compilation toolchain itself, the Linux kernel and other useful components. Buildroot is used by numerous companies and hobbyists, including Google for the Google Fiber devices, by many processor vendors and embedded system makers. It’s simple — you tell Buildroot what you want in your embedded Linux system through a kernel-like "menuconfig" interface, hit "make", and voila! Your embedded Linux system is ready to run!

The Developers Meeting brought together 12 participants from countries all over the globe including Finland, France, the UK and the United States. Over the two day event, participants discussed hot topics and made key decisions for issues that prove difficult to discuss over mailing lists or IRC. We also worked on cleaning up the list of patches waiting to be integrated — a list that has grown significantly with the popularity of the project! Meeting physically not only allowed work to get done during the meeting, but also allowed contributors to get to know each other better.  We believe it will make our interactions online much more efficient in the future.

Join us at, or take a look at the detailed report of the meeting to learn more about our progress. Many thanks to our sponsors Google and Mind who made this meetup possible.

By Thomas Petazzoni, Buildroot Org Admin

Categories: Open Source

March 2014 Project of the Month, Universal Media Server Front page news - Sat, 03/15/2014 - 12:30

For our March Community Choice Project of the Month, our community has selected Universal Media Server, a Multi-OS DLNA-compliant UPnP Media Server for streaming videos and other media over a network. The project founder, SubJunk, tells us about the project’s history, purpose, and direction.

SourceForge: Tell me about the Universal Media Server project please…
SubJunk: Our program serves media (video, audio and images) to many devices like TVs, gaming consoles, smart phones and more.

SF: What made you start this?
SJ: I started this project when I was working on another project called PS3 Media Server, so just a quick background on that: I had used PS3MS for years, and the project founder and developer shagrath – who is not only a very talented programmer but also a very cool guy – eventually lost interest since he didn’t use the program himself anymore. I started to make builds of it for myself and published them on the forum, and SharkHunter did his own builds too. Our builds became popular and that led to me and another developer, chocolateboy, being added as official developers to keep the project going. We made some great progress and further down the line more developers were added. Unfortunately this introduced instability in the program and I was spending more time fixing new bugs than anything else, and after a few releases with major bugs I decided to branch the project off to create Universal Media Server (and was joined shortly after by SharkHunter) with more of a focus on stability, and as the name suggests, support for a wider range of devices. Now we have a core team of 6: SharkHunter, valib, skeptical, DeFlanko, Optimus_prime and myself, as well as other frequent contributors who help with code and translations.

SF: Has the original vision been achieved?
SJ: I think so. We’ve fixed a lot of old bugs and implemented better quality control methods into our process which results in better stability, we have manual and automatic tests that are run before new releases, and we have a great community who are generous enough to give us useful feedback when we make a mistake so we can fix it pretty quickly.

SF: Who can benefit the most from your project?
SJ: It’s a great tool for anyone who wants to just use a media server program with no hassle. Many competing programs require you to wait for a media library to be built, which can take hours for those with lots of videos, but UMS is ready to use straight away with no configuration needed. We have lots of advanced features as well for those who want to use them, but I think our biggest advantage is that it just works.

SF: What is the need for this particular media server?
SJ: Aside from the things mentioned above, we have so many advantages! We offer subtitle support on every device, whether it supports subtitles or not, and we even support adding subtitles on the fly so you don’t have to find and download them yourself. We can output full quality DTS audio, which most servers compress, we interface with iTunes and DVDs, and there are many more specific benefits on our comparison page.

SF: What’s the best way to get the most out of using Universal Media Server?
SJ: To take advantage of our ability to stream media at top quality, it helps to have an audio receiver that can take DTS. Having a wired network is also useful for the best stability and quality, since the highest quality videos can sometimes need to be compressed for smooth transfer over wireless networks.

SF: What has your project team done to help build and nurture your community?
SJ: We are very grateful for our community, and our project members use our forums and issue tracker a lot. We give credit where it’s due by featuring the names of community members who help us in our release threads and readme files.

SF: Have you all found that more frequent releases helps build up your community of users? (Please provide insights if this is the case)
SJ: We have definitely found this. There are a lot of media servers out there, and a lot of them have been abandoned or are inactive, so it’s important to us to keep releasing new versions regularly to show our community that we are very active and will therefore be a good investment of their time.

SF: What is the next big thing for Universal Media Server?
SJ: We have been working hard on a web interface, which will allow us to support devices even without DLNA support. There is really no excuse for a modern device to not have DLNA support, but sometimes companies cut corners and that’s not the user’s fault, so we want to remedy those situations. We also have lots of other things in the works!

SF: How long do you think that will take?
SJ: It is already working and we are working on making it better, and will hopefully release a new alpha version with the web interface in the next month.

SF: Do you have the resources you need to make that happen?
SJ: We are a free program and we all do this out of pure motivation to improve the program. Sometimes people show their generosity by donating and thanks so much to everyone who has, it helps to cover our hosting costs.

Categories: Open Source


TypEcs is TypeScript IDE for Eclipse.
IDE provides the following features:

  • Syntax highlighting
  • Code Completion
  • Code Outline
  • Find References
  • Rename / Refactor
  • Open Type
  • Code Compilation
  • Format Code
  • Comment Code
  • Open Declaration

1.5 - New and Noteworthy

  • Add TypeScript Definition from Catalog
  • TypeScript Perspective
Categories: Open Source

Scott Palmer: My Five Favorite NetBeans IDE Features

NetBeans Highlights - Thu, 03/13/2014 - 21:24
An article series focusing on NetBeans users and their five favorite NetBeans IDE features. Scott Palmer, an Application Architect at Digital Rapids Corp.
Categories: Java, Open Source

All New! Online User Guide for NetBeans IDE

NetBeans Highlights - Thu, 03/13/2014 - 21:24
A comprehensive documentation of everything you need to know about using the NetBeans IDE to develop applications.
Categories: Java, Open Source

Getting Started with Creating a Cordova Application

NetBeans Highlights - Thu, 03/13/2014 - 21:24
This tutorial demonstrates how to install the software necessary to install and develop an application with Cordova.
Categories: Java, Open Source

J4LBarcode plugin for Jasperstudio 5.5

Barcoding components plugin for the Eclipse based reporting tool Jaspersoft Studio.

It supports, linear barcodes, QR Code, Aztec code, PDF417 , Maxicode and Datamatrix.

The source is available.

Categories: Open Source

Virtual Developer Cloud-Connector

The Virtual Developer Cloud-Connector is a lightweight Eclipse plug-in that allows you to access code generators that run on the Virtual Developer Platform. This single plug-in suffices to use all generators that are available on the Virtual Developer Platform. Generators are not being installed in Eclipse but stay on the platform. The Cloud-Connector sends models to the platform and recieves generated source files in return.

Check out the Virtual Developer Info Site to learn more about Virtual Developer.

Read the Virtual Developer Blog to get to know more about the latest developments.

Register for free on the Virtual Developer Portal to try out the available generators. When you check the "provider"-checkbox during registration, you can develop your own generators and run and market them on the same platform.

Categories: Open Source

March 2014 Staff Pick Project of the Month, Win32 Disk Imager Front page news - Thu, 03/13/2014 - 16:00

The Win32 Disk Imager project is a father (Tobin) / son (Justin) team, plus another developer, Jeff. Tobin is a regular in our IRC channel (Freenode: #sourceforge). This is a pretty cool story. Read on!

SF: Tell us what the Win32 Disk Imager project can do for folks…

Tobin:  Win32DiskImager is a tool to take filesystem images and raw files and write them to memory devices (USB memory sticks, SD/CF cards, etc).  It can also read from the device and save the image as a backup.

SF: What was the problem you were trying to solve with this effort?

Tobin:  This tool was originally developed for the Ubuntu 9.04 (Jaunty) Netbook release, targeting users of Netbooks with Windows preloaded.  At the time, Ubuntu only shipped CD ISO images and Netbooks don’t have a CD drive.  This was created as an easy to use solution for Windows users interested in trying the Ubuntu.  I should note that the program went from concept to working release in a weekend.  Justin can comment more on this.

Justin: Tobin simply called me up on a Thursday after school (Senior year of high school if I remember correctly), and needed a screenshot by the end of the weekend so they could do preliminary documentation. I sent a screenshot only a few minutes later (gotta love developing with Qt) and then had to learn the win32 API *shudder* and by Friday night I had a fully functional prototype.

SF: Has your original vision been achieved?

Tobin:  For the targeted release, it went quite well.  After it was released in April, 2009, Ubuntu changed the format of their ISO images and combined the Desktop and Netbook images, so the tool was no longer needed for this purpose.  At this time, it was all but abandoned.

Justin: My original vision for it was simply a temporary tool for a temporary problem, that had other uses as well. After being asked to allow Ubuntu to take over the project and turn it into an Ubuntu specific tool, I kindly refused since I wanted to keep it a generalized tool with a wide range of uses. I didn’t quite imagine that that decision is what would ultimately allow it to explode in popularity like it has done.

SF: Who can benefit the most from Win32 Disk Imager?

Tobin:  Anyone that is using Windows based systems to do development work on embedded systems or users that want to test the latest Cyanogenmod on their Android devices.  I have also heard from users that use it to just back up their SD cards from their cameras.

SF: What’s the best way to get the most out of using Win32 Disk Imager?

Tobin:  The program is very simple in design.  The first thing to remember is to backup any important data you may have on your memory device before writing to it.  And also, read the readme.txt file.  If you have questions, please ask.  We try to answer all questions that we can.

SF: What is the Win32 Disk Imager release philosophy; do you all use the release early, release often precept?

Tobin:  There are currently two people actively maintaining it (Justin is focusing on another project also hosted on SourceForge).  We also have received a few translations from other users, which is great. Unfortunately, we don’t spend nearly as much time on it as we probably should.  We try to outline what features or bugs we want to resolve in the next release, then work towards that goal.  My biggest issues are the constantly changing API’s in Windows, and having to find out how to integrate them in when something breaks.

SF: If not or if so, why?

Tobin:  Time and resources are the biggest factors here.

SF: What are the key features from your most current release?

Tobin: As of v0.9, we support generating MD5 checksums for image verification (helpful for downloaded images), Drag and Drop images from Windows Explorer, and the ability to define a default directory for images through an environment variable (defaults to the user’s Downloads directory).  This works quite well in Windows XP, but we have seen issues in newer Windows releases due to API changes.

SF: What did the project team do to make sure these were completed in a timely manner?

Tobin:  Timely???  Due to our sporadic release cycle, just getting an updated release out was challenging enough.  :P

Justin: As a side note here the first release was dubbed the “Truck Stop” release since one of the guys debugging it was doing so from a truck stop since we had very little time to get the project ready for the initial release.

SF: What was the first big thing that happened for your project?

Tobin:  It wasn’t until mid-2010 when I had bought a Nook Color from Barnes and Noble that I discovered other interests in this program.  The guy selling the Nooks was trying to also sell a book on using the Nook. I told him I was a Linux developer and could pretty much figure it out on my own.  Then he showed me the chapter on “Rooting your Nook”. Glancing through it, I saw a screenshot of our program along with a url to the Wiki page instructions that I had written.

I immediately ran a Google search and found an entire community of users, mainly in the Android Hacker community, but also developers of embedded Linux systems and other types of devices.  There were also a large amount of open bugs.  Since Justin had moved on to other projects, I took over as lead maintainer, and along with Jeff, we have cleaned up all of the original bugs and added some new features along the way.

The other major event was moving the project to SourceForge (YEA!!!). This has helped out a lot, both in exposure and in the tools now available to us to make this project more noticeable. Since moving (and subsequently being targeted as a SF Project of the Week), our user base has grown a lot.  Last time I was at Barnes and Noble, I found 6 different publications recommending our tool to their target audiences.

SF: What helped make that happen?

Tobin:  For the first part, word of mouth, I guess.  I can definitely say that just being on SourceForge has been a big thing.

Justin: It’s quite interesting that this project had received such worldwide fame despite having zero forms of advertising on our part. I guess that’s what you call going viral.

SF: What was the net result for that event?

Tobin:  I recently received an email from a German magazine editor, saying they were going to write a feature on our project.  I have also seen countless reviews, blogs, and even several video tutorials on Youtube.  Downloads are continuously growing week over week (I check the stats daily while sipping my morning coffee).

SF: What is the next big thing for Win32 Disk Imager?

Tobin:  We have a lot planned for upcoming releases.  First and foremost is to move to either a newer release of mingw or something equivalent, as there are a lot of new API issues in Windows that aren’t addressed in the release we currently build against.  Once we get that resolved, we have a wish list of features we want to integrate, starting with image compression/decompression on the fly.

Justin: A couple things I’ve been experimenting with outside of the project was to possibly have the drop-down-box show not only the drive letter but also the label on the device (for example mine might show up as “F: TuxDrive”). This would help a lot of people I think since my own personal experience of safely removing the drive on XP where it only tells you the letter has been annoying when the computer has 3 or 4 different removable devices plugged in. Also, it would be nice to eventually support batch processing of multiple images since the program is now also being used a lot in major tech companies where they’re flashing dozens of cards all hooked up to one system.

SF: How long do you think that will take?

Tobin:  Hard to say.  We already missed our soft target of 1.0 for the end of 2013.  But we do have an installer in the tree now.  That was one of my goals for 1.0. Right now I am focusing on an updated tool base that supports the newer APIs for Windows 7/8.

Justin: As for the pieces I’d like to see, it might be difficult as I’m tiding up other projects, most notably my Open RPG Maker, before going off to college this fall. However, I may be able to squeeze enough time in there to get those two small parts easily done.

SF: Do you have the resources you need to make that happen?

Tobin:  We could definitely use more help.  We are always open to contributions. We have already received a few translations from users, along with some code contributions.  I would also like to thank Jeff B (skydvr68) for his contributions in both code and with the questions forum.

SF: If you had it to do over again, what would you do differently for Win32DiskImager?

Tobin:  I’ll let Justin answer the next few.

Justin: I don’t really think there is anything I’d do differently since the initial release, while a bit buggy, was still fully functional.

SF: Is there anything else I should know?

Tobin: If we can get our development environment issues resolved, 2014 will be a great year for new features.  Hopefully.

Justin: Really awesome to have this project recognized as project of the month, especially seeing some of the other projects that usually get nominated. Feels pretty awesome to have played a part in getting this project there.

Categories: Open Source


As a Model-Based Testing tool, MaTeLo (Markov Test Logic), offers opportunity to improve all the validation life cycle. This innovative solution, built on a mature process of validation, includes an association of models, traceability, evaluation and automatic generation of test artefacts (test cases and scripts).

Thanks to our Model Based Testing (MBT) tool MaTeLo, you can:

- create a usage model from functional requirements
- choose the right test strategy depending on the system maturity level
- automatically generate test scripts and test cases

Benefits: MaTeLo is a entire Test Framework in order to provide a model and control the test benches.

Categories: Open Source

LOGpulse - A Log viewer based on impulse

LOGpulse is a log viewer extension for impulse. It allows to analyse logs from pattern or xml based sources.

The logs can be presented along a time-line as well as in tabular form.

The log data can be read from a file, pipe, socket, the output from a process or as combination of multiple inputs.

Read this short howto to get started.

Version 0.6.x new and noteworthy

Please send me your comments !

log4j xml: Version 1.2
Pattern Log: Allows configurations of multiple regular patterns per file.

Sockets: Streams from Tcp socket.
Pipes: Get data from os pipe.
Process: Analyse the output of a process.
Combine multple sources: Combine the above inputs.

Multiple log signal and signal hierarchies: Readers organize the logs in various forms.
Tabular presentation: Select signals in the viewer and get the contents in tabular form (Value Table).
Overview: Get statistical information about a log signal (Signal Table).

This feature is licensed under the EPL. It is build on impulse that is deployed under a different license.

Categories: Open Source

Code Picker

It fetches Java code snippets from few websites based on your search query with the comfort of being within eclipse [Only java editor supported] and displays it as content assist, one press of enter the snippet will be inserted.

Latest version can be downloaded from

Categories: Open Source

Composite launcher

Plugin for create composite launch configurations.

Categories: Open Source

Teaching the next generation to code: Young Coders at PyTennessee 2014

Google Open Source Blog - Wed, 03/12/2014 - 20:00
The Google Open Source team recently sponsored the PyTennessee conference in Nashville. Adam Fletcher, an Engineer at Google and today's guest blogger, volunteered at the conference and helped introduce Python to an enthusiastic group of students. 

On February 23rd & 24th the first PyTennessee took place in Nashville, Tennessee, and brought hundreds of pythonistas from all over the nation to learn about a diverse set of Python-related topics. On Saturday the 24th, PyTennessee ran a Young Coders event, based on a similar event that took place at the 2013 US PyCon. Google was proud to sponsor this event, providing funding for the Raspberry Pi computers the coders used throughout the day.
 Mayor of Nashville, Karl Dean, with the students
The Young Coders event introduced 25 new programmers, aged 12-18, to the world of Python by providing each student with a Raspberry Pi running Linux and a day of instruction in the Python programming language. Students were taught about the basic data types and control flow in Python in the morning and then spent the afternoon making and modifying games. When the event wrapped up the students got to take home their Raspberry Pi computers to continue their programming exploration at home. Additionally, the students each got a copy of Python For Kids, an excellent introductory book.
Raspberry Pi, the compact computer the students used to learn Python
Earlier in the day the Mayor of Nashville, Karl Dean, stopped by to learn about the Young Coders event and to talk to the students. Mayor Dean was excited about Nashville as a technology center; Nashville is one of the cities being evaluated for Google Fiber, and Google has selected Nashville as one of the Google for Entrepreneurs Tech Hub Network cities.

Later, the students used their newfound Python knowledge to modify various games. Students altered the startup screen, changed the frame rates, modified the fundamental rules, and made other fun changes to games written in the PyGame framework.
Two students hard at work
Katie Cunningham (right) with two Young Coders
The Young Coders event would not have been successful without its excellent instructor, Katie Cunningham. Big thanks to her and to the entire PyTennessee team for for organizing such a wonderful event, and for providing the space to help train the next generation of computer scientists!

By Adam Fletcher, Google Site Reliability Engineer
Categories: Open Source

Continuous Delivery is for Open Source Too Front page news - Wed, 03/12/2014 - 16:34

This is a guest post from Stephen Connolly, CloudBees, Inc.


If you start to push for Continuous Delivery in the context of an open source project, you will often get push-back such as:

“One of the nice things about Open Source projects is that, well, it’s NOT work, it’s NOT a job.”


“[Open source projects] aren’t factories, churning out releases and code like widgets. We do that enough at our day-jobs.”

These are valid arguments. But they miss some key points.

  • People write commercial software for money.
  • People write open source software for passion.

There is still a transaction going on. It may not be one you can see or account for on a traditional balance sheet… but you can still measure it.

Passion is measured in engagement. When an open source project has lots of passion there are lots of contributors and a vibrant community is built up around it. When an open source project runs out of passion it becomes the tumbleweed of the open source forges: A repository with the last commit five years ago and nobody can checkout and build the code any more.

“If you have an apple and I have an apple and we exchange apples then you and I will still each have one apple. But if you have an idea and I have an idea and we exchange these ideas, then each of us will have two ideas.” – George Bernard Shaw

Passion does not work the same way as money does.

If I spend my passion developing a feature for an open source project and the community grows more passionate because of that feature, then my passion is restored and re-invigorated as part of the community… there is more passion after than before.

If I spend my passion developing a feature for an open source project and it gets dropped on the floor and ignored, however, my passion was wasted.

When you feel passionate for an open source project, then it is your responsibility to help grow the passion of that project’s community.

There are things we can do to help grow our project’s community and passion, one of those ways is to get releases out more often.

Leaving unreleased features / fixes in your source repository burns the passion of those members of the community who need those features / fixes – and of those who created them. The longer those changes stay unreleased, the more passion you are losing. To put it another way:

Continuous delivery – not just for your day job

Your day job wants continuous delivery because the new features / fixes are like inventory left half finished on the shop floor… it’s consumed resources but still cannot be sold. It’s overhead.

Your open source project wants continuous delivery because the new features / fixes are like inventory left half finished on the shop floor… it’s consumed community passion rather than growing it.

Now of course these the passion balance sheet works differently than a fiscal one… but there are some things that stay the same:

  • Continuous delivery is about making sure that improvements are delivered as efficiently as possible. Not as fast as possible because then you are cutting corners and perhaps lowering quality (which will cost you money / passion).
  • Continuous delivery becomes easier if you can automate – as much as possible – the early parts of the process. For most processes, the expensive parts are the human parts. In some sense the commercial projects have easier accounting here… it is easy to measure the fiscal cost of human processes, e.g. using time and motion studies. It is very difficult to measure the passion cost of human processes on volunteers in your community… but our intuition tells us that the cost is not small.
  • We maximise our return by getting new features / fixes out as early as possible.

The decision to run a release through your continuous delivery pipeline has a cost.

A good pipeline is almost completely automated with a few sanity manual checks at the penultimate step. These pipelines are therefore low cost… both in fiscal and in passion accounting terms.

A bad pipeline has lots of manual checks and steps scattered throughout. These pipelines are high cost… and if prone to failure, the cost can grow while you fight to get a release all the way through to the end.

You need to weigh the expected cost of executing your pipeline against the expected net gain you will get by having the new release delivered. Once that measure gives a net gain in your respective accounting metric… then it is time to cut a release.

Every situation is different, so it is no surprise that the balance will play out differently for different projects.


One of the projects I am involved with is the Jenkins CI project. When it started out initially there were releases as often as necessary. There were some occasions where the project got a new release several times during the same day as Kohsuke added a new feature and then people found critical bugs in the new feature. This very fast release cadence was great for getting people engaged with the project… but it came with a cost… people just could not keep up to date with the releases. After a while, Kohsuke settled down to a weekly release cadence. There may not be a release every single week (for example, Kohsuke may not have access to cut a release while travelling abroad) but on average about 48 weeks of the year there is a release.

Is that weekly release schedule right for every project? No, in fact it isn’t even right for everyone in the Jenkins community. If we look at the usage statistics there are a lot of people using the newer versions. There is also a significant group of people in the community who don’t want to live on the bleeding edge but still need bug fixes. The solution is a second, slower train of releases in what is called the Jenkins LTS release line.

The fact that there are regular releases with the Jenkins project has, in my view, helped to grow the community. If somebody finds a bug in Jenkins and provides a patch to fix that bug, there is a very strong possibility that the patch will be applied in the next week’s release.

★★★★★ Excellent: I would contribute again




★☆☆☆☆ Poor: I would discourage others from contributing

Part of what makes the weekly releases work for Jenkins is that Kohsuke has heavily automated the release process.


Another project I am involved with is Apache Maven. On the Maven project, our current release process has a lot of manual steps. If we count the steps for releasing Maven itself… I lost count after at least 26 steps. Another issue is that, for legal reasons, the Apache board requires that Apache projects have to vote on releases. So each PMC member casting a vote on releasing has to

“…download the signed source code package, compile it as provided, and test the resulting executable on their own platform, along with also verifying that the package meets the requirements of the ASF policy on releases.” –

In short, we burn a lot of passion getting a release out the door. The result of that is that it is probably not currently possible for Apache Maven to maintain a release cadence faster than about once every 4-8 weeks… so we are looking into automating as much of the process as we can. It may be that Apache Maven will never have a faster cadence than once every 4-8 weeks… but making it cheaper to release at that cadence can only help grow the community passion.

Continuous delivery is more a collective state of mind than any one, set process or technology. If a project releases at all then it is practicing delivery. To see the benefits of continuous delivery, you just need to up your cadence. Things to look out for are:

  • Manual tasks that can be moved later in the process
  • Automated tasks that can be moved earlier in the process
  • Automated checks that can be created / moved as early as possible in the process
  • Redundant tasks and checks that can be removed entirely


Upping your cadence will come with some pain. The point is to identify the causes of the pain and reduce or remove them. If, at a later time, you decide the higher cadence of continuous delivery is not for you, the reduced pain of releasing will still remain as a benefit.


One example is a set of Jenkins jobs that I set up to help cut releases of Apache Maven. They are:

  • There is an initial job. This job is responsible for determining if there are any changes to the code since the last release. If there are changes then it triggers an evaluation of those changes.
  • There is a build job. This job is responsible for determining if an exact GIT hash identified by the initial job builds and passes all the unit tests. If that job passes, then it triggers an integration test
  • Finally the test job takes the distribution of Maven built by the build job and runs that through the integration test suite.

If the downstream jobs are successful, they add a badge to the initial job that kicked them off. When a build has all the badges, then an email is sent to the Maven developers list to notify them that there is something that could be released. This actually removes about 10 of the 26+ steps from the current Maven core release process.

If you want to say you are doing continuous delivery I would suggest you aim for the following levels:

Level 0: A new feature / confirmed fix of a bug committed to source control waits no longer than 3 months before a release with that new feature / fix is available. If you cannot meet this target don’t even try to claim your processes are continuous delivery

Level 1: A new feature / confirmed fix of a bug committed to source control waits no longer than 1 month before a release with that new feature / fix is available.

Level 2: A new feature / confirmed fix of a bug committed to source control waits no longer than 1 week before a release with that new feature / fix is available.

Level 3: A new feature / confirmed fix of a bug committed to source control waits no longer than 1 day before a release with that new feature / fix is available. You are a continuous delivery evangelist, people may hate you. You may need processes to support those in your community who cannot handle such a fast cadence.


Many open source projects have explicitly moved to time-based mostly fixed cadence releases. It may not be right for your project, but you cannot know until you try.

Experimenting with continuous delivery can help your project and may significantly grow your community’s passion… even if you don’t end up using continuous delivery after an experiment!


—Stephen Connolly
CloudBees, Inc.


Stephen Connolly has over 20 years experience in software development. He currently works for CloudBees, Inc as an Elite developer and architect. He is involved in a number of open source projects, including Jenkins. Stephen was one of the first non-Sun committers to the Jenkins project and developed the weather icons. Stephen lives in Dublin, Ireland – where the weather icons are particularly useful. Follow Stephen on Twitter and on his blog.

Categories: Open Source

Survey: Is NetBeans IDE 8.0 Ready for Release?

NetBeans Highlights - Tue, 03/11/2014 - 20:55
If you have already downloaded and tested the latest Release Candidate build, we would like to know what you think about it. Take the NetBeans IDE 8.0 Community Acceptance Survey and tell us about your experience! The survey will be opened until March 11th. Thank you in advance for participating in the survey! Jiri Kovalsky NetBeans Community Manager
Categories: Java, Open Source


0   0

A leader in research, development and innovation, the CEA, French Alternative Energies and Atomic Energy Commission (Commissariat à l'énergie atomique et aux énergies alternatives), is active in four main areas: low-carbon energies, information technologies and health technologies, Large Research Instruments, defense and global security. In each of these domains, the CEA relies on a high-level fundamental research and ensures a role of support to the industry.
Within the CEA Technological Research Division, the CEA LIST institute carries out research on intelligent digital systems. Its R&D programs, all with potentially major economic and social implications, focus on advanced manufacturing (robotics, virtual & augmented reality, non destructive testing, vision), embedded systems (computing architectures, software and systems engineering, security & safety), and ambient intelligence (sensors, instrumentation & metrology, communication & sensory interfaces, data processing & multimedia). By developing cutting-edge technological research with applications in the industrial markets of transports, defense and security, manufacturing, energy and health, the CEA LIST helps its partners to enhance their industrial competitiveness thanks to innovation and technology transfer (

URL: Francevar at = "@";var t3 = "";var t1 = "sebastien.gerard"; document.write('Contact Provider')Please enable JavaScript to view CEA LIST contact information.Supported projects:  Project Name: PapyrusAll versions: Yes
Categories: Open Source

Safety Architect

Safety Architect is a tool achieving risk analysis of complex systems using functional or physical architectures from usual modeling tools (for example SysML or UML).

It provides support to the implementation of FMEA and automatically deducts the FTA corresponding to the identified feared events. Mains functionalities of the tool: import models, locally analyse the risk, spread to feared events, generate fault trees, export enriched models.

Main advantages of the approach: compliance with all engineering loops, automation, fats detection of critical parts, easy handling of corrections/evolutions.

Categories: Open Source

Get with the program: open source coding with Google Summer of Code

Google Open Source Blog - Mon, 03/10/2014 - 22:27
Cross Posted from the Official Google Blog

Tobi Mueller started coding when his grandfather, who works in IT, gave him access to a spare PC. It was a sweet 286 machine which Tobi learned to program with the then-popular teaching language Pascal. He eventually became interested in free and open source software, but it was Google Summer of Code (GSoC) that helped transform Tobi into the free software contributor he is today.

Tobi was a GSoC student in 2007 for GNOME, a free software desktop environment. He’s been a regular contributor to the GNOME community ever since—and in 2012, Tobi was elected to the GNOME Foundation board of directors.

Tobi is one of more than 7,500 students who have participated in Google Summer of Code program over the past nine years. Every summer, GSoC participants work with various organizations in the open source community, building important technical skills and gaining workplace experience. Students aren’t the only ones who benefit; their projects also give back to the open source community. Karen Sandler, GNOME’s executive director, told us how Google Summer of Code “encourages and empowers” new contributors and helps “invigorate projects.”
So if you’re a university student looking to earn real-world experience this summer, we hope you’ll consider coding for a cool open source project with Google Summer of Code. We’re celebrating the 10th year of the program in 2014, and we’d love to see more student applicants than ever before. In 2013 we accepted almost 1,200 students and we’re planning to accept 10 percent more this year.

You can submit proposals on our website starting now through Friday, March 21 at 12:00pm PDT. Get started by reviewing the ideas pages of the 190 open source projects in this year’s program, and decide which projects you’re interested in. There are a limited number of spots, and writing a great project proposal is essential to being selected to the program—so be sure to check out the Student Manual for advice. For ongoing information throughout the application period and beyond, see the Google Open Source blog.

Good luck to all the open source coders out there, and remember to submit your proposals early—you only have until March 21 to apply!

Posted by Carol Smith, Google Open Source team
Categories: Open Source