Archive by Author

Featured Projects of the Week, February 03, 2014

Hi folks,

This is week 2 of newly featured projects on our homepage that will enter the pool to be candidates for the March Project of the Month community vote. As always, we have an interesting set of projects to consider…

MSYS2

Development tools & pacman installer.

[ Download MSYS2 ]

Simplicity Linux

Simplicity Linux uses Puppy Linux and derivatives as a base, uses the XFCE window manager, and comes in 3 editions: Netbook, Desktop and Media. Netbook features cloud based software, Desktop features locally based software and Media edition is designed to allow people who want a lounge PC to access their media with ease.

[ Download Simplicity Linux ]

Pydio

Pydio is the mature open source alternative to dropbox and box.com, for the enterprise. Why building your own box? You need to access your documents across multiple devices, and regularly share documents (weblinks) and folders with your contacts and teams. Still, using a consumer SaaS box or drive service is neither practical nor safe. And enterprise SaaS box or drive services are expensive and come with Disk Storage that you already have on your servers or private cloud. How to build your own box with ajaXplorer? Easily install AjaXplorer on your servers or cloud of choice, Simply share documents and folders with your teams, Administrate your box with an Entreprise grade console (rights, groups, plug ins), Access documents with a Web Gui, Smartphones and tablet apps (iOS, Android), Sync folders on your computer (public beta, PC, Mac, Linux,Web,Tablets).

[ Download Pydio ]

Sky Chart / Cartes du Ciel

SkyChart is a software to draw chart of the night sky for the amateur astronomer from a bunch of stars and nebulae catalogs. See main web page for full download

[ Download Sky Chart / Cartes du Ciel ]

Endian Firewall Community

Endian Firewall Community (EFW) is a “turn-key” linux security distribution that makes your system a full featured security appliance with Unified Threat Management (UTM) functionalities. The software has been designed for the best usability: very easy to install, use and manage and still greatly flexible. The feature suite includes stateful packet inspection firewall, application-level proxies for various protocols (HTTP, FTP, POP3, SMTP) with antivirus support, virus and spam-filtering for email traffic (POP and SMTP), content filtering of Web traffic and a “hassle free” VPN solution (based on both OpenVPN and IPsec). The freshly released EFW 2.5.1 also features support for most modern UMTS/3G USB dongles, new configurable widgets for the dashboard, additional gateway options and several performance improvements.

[ Download Endian Firewall Community ]

thymeleaf

Thymeleaf is a java web template engine designed for XML/XHTML/HTML5.

[ Download thymeleaf ]

Semplice Linux

A non-innovative, lightweight, fast and simple GNU/Linux Distribution, based on Debian Sid.

[ Download Semplice Linux ]

TCPDF – PHP class for PDF

TCPDF is a PHP class for generating PDF documents without requiring external extensions. TCPDF Supports UTF-8, Unicode, RTL languages, XHTML, Javascript, digital signatures, barcodes and much more.

[ Download TCPDF – PHP class for PDF ]

PyDev for Eclipse

Please contribute to help keeping PyDev going: https://sw-brainwy.rhcloud.com/ PyDev is a Python Development Environment (Python IDE plugin for Eclipse). It features an editor with code completion, code analysis, refactoring, outline view, debugger, mark occurrences and other goodies – check http://pydev.org for more details)

[ Download PyDev for Eclipse ]

Announcements: Puerto Rico PIG, ApacheCon NA, CloudStack, & PyCon

We’re really happy to support those growing communities out there; OSS is big, growing, and busy getting it done for all of their groups interested in their work. Here are a few for you to consider today…

Puerto Rico Python Interest Group Celebrates First Anniversary, February 20, 2014

One year ago the Puerto Rico Python Interest Group (prPIG) was founded on one purpose; to create a sustainable user community based on software development in Puerto Rico; they are sponsored by the Internet Society through their Community Grant program. On February 20, 2014 prPIG will celebrate their first anniversary with an open format meeting including lightning talks from the community.

During their first year, the Puerto Rico Python user group hosted 18 events, and established an active community online. According to founder Kevin Shockey, “prPIG has successfully established an online network that is helping to sustain our software development user group in Puerto Rico. We’ve gained many new partners and collaborators in our first year. They have really helped us and we look forward to more collaborative opportunities.”

If you live in Puerto Rico or will be there and want to visit, or if you just want to know more about them, visit their homepage: www.prpig.org.

ApacheCon, North America 2014 – April 7 – 11, 2014 (Denver)

The Apache Foundation has announced their annual conference, ApacheCon, North America 2014, which is being held in conjunction with the Linux Foundation this year. We’ve been watching the organizer traffic since ApacheCon was announced and things are shaping up for an excellent conference this year. If you are looking to attend, the details are all there. Get on it early and beat the rush!

CloudStack Collaboration Conference – April 9 – 11, 2014 (Denver)

You also have a chance to double your fun and learning opportunities; running in parallel at the same location as ApacheCon, is the CloudStack Collaboration Conference, also in conjunction with the LInux Foundation; there is some schedule overlap with ApacheCon, so take advantage of your visit and catch them both. The CloudStack Conference website has a schedule of events so that you can plan accordingly.

PyCon 2014 – April 9 – 17, 2014 (Montreal)

Our developers are looking forward to this year’s PyCon, held in Montreal on the heels of ApacheCon (see above).

What we think makes PyCon different from some conferences is how they are organized; there are tutorials on Apr. 9 & 10, then the body of the conference from Apr. 11 through Apr. 13. Finally, they have sprints from Apr. 14 through the 17th. Check out what PyCon is all about so that you can decide what make the most sense for your professional growth interests.

This is a developers’ conference. If you are looking to learn Python, this would be the place to get started. If you are deep in Python already, this is of course the place to be. Check it out and make your plans now.

Project of the month voting in progress

We don’t generally write about an ongoing project of the month voting process. But, since we are doing our first vote since we re-launched the PoTM community vote process, it’s great to see how many folks are out there supporting their favorites.

It’s also cool to see how each individual project has built a strong community. One of the things we will start asking projects when we interview them is how they built such a robust community that supports them the way they did. It is our hope that in so doing, other projects looking to grow can learn from these experiences.

Remember, in the vote post, below the “Vote: <project_name>” line, folks can add commentary as to why they voted for the project.

Go vote for your favorite project on the list!

January 2014 Project of the Month, Minsky

SourceForge: Tell us about the Minsky project please…

Minsky Team: Bizarre as it may seem, mainstream economic theory ignores banks, debt and money completely, and imagines that the dynamic, innovative and crisis-prone social system we call capitalism can be modelled as if it is almost always in equilibrium. It’s little wonder therefore that most economists didn’t see the financial crisis coming back in 2007.

The designer of Minsky, Dr. Steve Keen, did anticipate the crisis, based on a dynamic monetary model of a possible financial crisis that he developed back in 1992.

 The model put into mathematical form the economic approach of the rebel American economist Hyman Minsky, and the program Minsky was named in his honor.  Minsky was designed to make a different approach to economic modeling possible: one in which banks, debt and money are indispensible, and in which the economy is always changing. To do that, we built on the established tradition of system dynamics embodied in programs like Xcos, which use flowcharts to build dynamic models of real-world processes.

The flowchart paradigm is fine for physical flows but problematic for financial flows, because the same transaction—say buying goods from a store when its deposit account is in a different bank—has to be recorded in at least four different places: once as a deduction from your account, once as an addition to the store’s, and twice more as a transfer of reserves from your bank to the seller’s bank. 

Because of the multiple entries needed to properly represent financial flows, modeling using the flowchart paradigm rapidly generates a “spaghetti code” of intersecting wires that is effectively unintelligible.  Minsky solves this problem by adding a second method to generate dynamic equations for financial flows. This is a spreadsheet-like double entry bookkeeping system, which we call them “Godley Tables” in honor of a pioneer in monetary economics Wynne Godley.

SF: What made you start this?

Minsky Team: The Godley table feature is new, so either needed to be implemented within an existing open source dynamic systems modelling tool, or we had to create the modelling tool de novo.  The main OSS system dynamics program Xcos is based on the commercial program Simulink, and even as experienced developers we found the user interface difficult (we became aware of another Open Source program—Insight Maker—after starting the Minsky project, and we’re exploring the possibility of sharing code and approaches here).

So we decided to implement Minsky from scratch in C++ and Tcl/Tk. By doing so we’ve been able to implement “best of breed” ideas from the spectrum of system dynamics tools, and introduce some of our own ideas too.  Similar to the commercial program Vissim, Minsky uses variable names as well as wires to pass values, and in addition we enable easy conversion between constants, parameters, variables and integral variables, so that a model can start simple and be made more complex and accurate over time.  We also can export a model’s equations to LaTeX, which is essential for academic publishing. To our knowledge, no other system dynamics program does this.

SF: Has your original vision been achieved?

Minsky Team: Yes, although the original vision is only a fraction of what we hope to implement with future development. The original objective was to make it possible to develop dynamic monetary macroeconomic models with both physical and financial flows. That has now been achieved, though some features—for example creating groups and local variables, graphics and data display—are still at an early stage.  Overall however we think it’s the easiest system dynamics program to use, and the only one that makes it feasible to model financial as well as physical flows.

SF: Who can benefit the most from Minsky?

Minsky Team: Anyone who has an interest in dynamical systems modelling—from chaos theory, to economics and biological modelling—can use and benefit from Minsky. We’ve easily implemented classic chaotic models in Minsky—the Lorenz attractor, Duffing Chaos etc.—and you can run them in real time, and change parameters as they run.

It would suit mathematics lecturers and students too, as a means to visualize dynamic models and mathematical functions in general.  Those who can benefit the most are people who want to understand the financial system and monetary flows. We hope in time that it will be adopted by universities as a teaching tool, and by Central Banks and Treasuries as a means to build realistic models of the economy in which finance and banking play integral roles—in contrast to existing “DSGE” models, 99% of which ignore banking completely.

SF: What’s the best way to get the most out of using Minsky?

Minsky Team: Take a look at the examples, as well as the many videos Steve Keen has made on constructing models—which are available on his YouTube Channel (http://www.youtube.com/ProfSteveKeen).

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

Minsky Team: The project would not have been possible without an original grant of $128,000 from INET (the Institute for New Economic Thinking). This allowed us to create the first couple of releases of Minsky (named “Aristotle” and “Aquinas” after early thinkers on topics economic and philosophical) which resulted in a usable, but still pretty basic, program.  Then a successful Kickstarter campaign in February this year allowed the next two releases Petty and Mun, which improved the usability of the software, and allowed more complex systems to be simulated.

SF: What helped make that happen?

Minsky Team: Steve Keen, the chief designer of Minsky, was a Professor of Economics who is also a well-known critic of conventional economic theory, with a popular book Debunking Economics and an influential blog Steve Keen’s Debtwatch. INET respected his work and were happy to give the initial grant, while his public profile led to a substantial sum being raised from the public via Kickstarter.

SF: What was the net result for that event?

Minsky Team: The net result is that Minsky now fulfils its basic promise—to be able to build dynamic models in general, and in particular to build monetary models of the economy. There are still some rough edges at this level since less than 3000 hours of programming has gone into its development so far, but we’re confident that it is relatively bug-free and will work as intended right now—though we hope to add much more polish and far more modeling power in future releases.

SF: What is the next big thing for Minsky?

Minsky Team: This depends on getting substantial additional funding for programming, but after some more work refining the interface, we intend extending its ability to model the economy by enabling it to represent an economy as a number of industrial sectors, each of which buys inputs from and sells output to the others.

Then we will add the ability to model international trade and financial flows between different national economies.  We have already done proof-of-concept modeling of multi-sectoral monetary models in Mathcad and Mathematica, so we know this can be done.  Simultaneously we will add the capability to import economic data and to derive system parameters from data using nonlinear parameter estimation techniques.

We have some ideas on how to represent and manipulate statistical data that are also novel and we hope will give Minsky appeal to data analysts as well.  We also plan to add two additional ways to model dynamic systems: direct entry of equations in a TeX-like interface and what is known as a “Social Accounting Matrix” (SAM), which also ensures model consistency. There would be each-way conversion between these three design methods—so equations would be converted to flowchart diagrams and SAM entries automatically, and vice versa.

SF: How long do you think that will take?

Minsky Team: If we can get a team of about half a dozen programmers working full-time, it could be completed within 2-3 years.

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

Minsky Team: Not at present! Though there are some offers of funding that may come our way—we’ll let you know if they do! This is not your standard Open Source project where programmers with an innate interest in the topic are plentiful, or where corporations see it as in their interests to let their programmers develop a tool: very few economists have any skills in computing at all, and only a handful of economists are non-orthodox in their approach and therefore interested in dynamic monetary modeling. So we do rely on being able to hire programming talent.

Minsky has come so far so quickly because of the happenstance that the non-orthodox economist Steve Keen and the high-performance computing programmer Russell Standish have been friends and research collaborators for almost two decades. We have also been assisted by a volunteer programmer in the USA, and some capable freelancers in Russia and France.

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

Minsky Team: The only thing that might have been better would be to program in an environment that generated code for multiple platforms easily. TCL/Tk was chosen due to existing expertise, its inbuilt canvas functionality, and its ability to get something working quickly. But it has limitations in terms of platforms supported (basically Windows, MacOS Aqua and X11), when tablets and web browsers are desirable targets for the future.

SF: Why?

Minsky Team: A lot of time has been wasted writing specific routines to circumvent idiosyncracies in Windows and Mac for this cross-platform software, which is probably the case with any cross platform GUI framework. Moreover, substantial effort was required to get adequate graphics performance, which has not translated onto the Macintosh, because Tk is written using the old Quickdraw API, and not easily adapted to using the more modern Cocoa API.

Furthermore, some means of targetting Android, iOS and Web browsers is also desirable going forward, so investigating other GUI toolkits is desirable.

But apart from that we didn’t take any wrong turns that we later had to reverse. It’s been a pretty smooth development process so far.

SF: Any reason you can’t do that now?

Minsky Team: Mostly because user functionality on standard PCs/workstations has trumped porting the software to these other platforms.

SF: A significant portion of our community are interested in digital currencies such as Bitcoin. Is it possible to model such a currency in Minsky, and if so what interesting questions might be answered?

Minsky Team: Bitcoin is a peer-to-peer system, meaning that transfers from one individual to another don’t go through a bank. That would be easy to model in Minsky. And there’d be a reservoir of Bitcoins with 21 million in existence, a fraction of those in circulation, a variable but slow rate of extraction, and so on.

The exchanges would also be relatively easy to model—though you’d need to have a price for Bitcoin in relation to the local fiat currency. The volatility of this price could be simulated as well.

The issues that would be harder to capture involve things like whether competitors to Bitcoin would spring up because of Bitcoin’s success, whether its popularity might wane as a result, whether its penetration becomes universal (100% of people having a bitcoin account), or not. Overall we think that multi-agent models and contagion-oriented modeling might work better on those issues than Minsky.

With sufficient funding and programming support, multi-agent capabilities could be added to our current system dynamics toolkit. Much of Minsky was based on Russell Standish’s Ecolab project, which is a multi-agent modeling system, so the code base already exists.

SF: It seems that the economic models designed in Minsky can become quite complex, and can benefit from the features of open source – many eyes to identify bugs in the model, forking a model to bring more detail to a specific economic sector, and then sharing that fork back to a central model bank. Do you foresee one, or a few, detailed models evolving along those lines, and being shared among many users to do research? Or do you anticipate many independent, ad-hoc models being used?

Minsky Team: We want to develop a database for users and model development and sharing—and in fact one was developed by student programmers as part of a web-based version of Minsky. That part of the project is on hold given lack of funding, but the code for real-time simultaneous development of the same model on multiple computers works.

We expect to see a whole eco-system of models, some at quite basic levels for teaching or exploring specific issues, others which will be extremely sophisticated and will definitely need “many eyes” for both development and de-bugging.

SF: What’s the best example of “stability is destabilizing” that you’ve seen from the Minsky software so far?

Minsky Team: The best instance so far is a monetary version of Keen’s 1992 model in which price deflation amplifies the trend to instability. The final crisis is a downward collapse due to private debt falling less rapidly than GDP collapses due to no investment and deflation—which is what happened in the Great Depression. As with the 1992 model, the crisis is preceded by a decline in the volatility of employment, and also inflation—as happened in the real world—and workers’ share of income falls as well.

This model is incomplete—there are inconsistencies in the monetary and physical flow components—but it shows the capacity of genuinely monetary dynamic models of capitalism to capture its behavior in way that the standard non-monetary models cannot.

SF: Is there anything else we should know?

Minsky Team: Yes. We’d love to develop a substantial user community, and that community could help us develop both examples and a comprehensive help system. We’ve been deficient on this front because the development team is so small.

SF: Congratulations to you all on this excellent bit of work, not only for the OSS community, but for folks looking to utilize such modeling systems.

Usability in Open Source Software – Guest Blog post

From our friend Jim Hall of the FreeDos project…

Open source software developers have created an array of amazing programs that provide a great working environment with rich functionality. At work and at home, I routinely run Fedora Linux on my desktop, using Firefox and LibreOffice for most of my daily tasks. I’m sure you do, too. But as great as open source can be, we’re all aware of a few programs that just seem hard to use. Maybe it’s confusing, or has awkward menus, or has a steep learning curve. These are hallmarks of poor usability.

But what do we mean when we talk about usability? Usability is just a measure of how well people can use a piece of software. You may think that usability is an academic concept, not something that most open source software developers need to worry about, but I think that’s wrong. We all have a sense for usability – we can recognize when a program has poor usability, although we don’t often recognize when a program has good usability.

So how can you find good usability? When a problem has good usability, it just works. It is really easy to use. Things are obvious or seem intuitive.

But getting there, making sure your program has good usability, may take a little work. But not much. All it requires is taking a step back to do a quick usability test.

A usability test doesn’t require a lot of time. In fact, usability consultant Jakob Nielsen says that as few as 5 usability testers are enough to find the usability problems for a program. Here’s how to do it:

1. Figure out who are the target users for your program.

You probably already know this. Are you writing a program for general users with average computer knowledge? Or are you writing a specialized tool that will be used by experts? Take an honest look. For example, one open source software project I work on is the FreeDOSProject, and we figured out long ago that it wasn’t just DOS experts who wanted to use FreeDOS. We actually determined there were three different types of users: people who want to use FreeDOS to play DOS games, people who need to use FreeDOS to run work applications, and developers who need FreeDOS to create embedded systems.

2. Identify the typical tasks for your users.

What will these people use your program for? How will your users try to use your program? Come up with a list of typical activities that people would actually do. Don’t try to think of the steps they will use in the program, just the types of activities. For example, if you were working on a web browser, you’d want to list things like: visiting a website, bookmarking a website, or printing a web page.

3. Use these tasks to build a usability test scenario.

Write up each task in plain language that everyone can understand, with each task on its own page. Put a typical scenario behind the tasks, so that each step seems natural. You don’t have to build on each step – each task can be separate with its own scenario. But here’s the tricky part: be careful not to use terminology from your program in the scenario. Also avoid abbreviations, even if they seem common to you – they might not be common to someone else. For example, if you were writing a scenario for a simple text editor, and the editor has a “Font” menu, try to write your scenario without using the word “Font.” For example, instead of this: “To see the text more clearly, you decide to change the font size. Increase the font size to 14pt.” write your scenario like this: “To see the text more clearly, you decide to make the text bigger. Increase the size of the text to 14 point.”

Once you have your scenarios, it’s just a matter of sitting down with a few people to run through a usability test. Many developers find the usability test to be extremely valuable – there’s nothing quite like watching someone else try to use your program. You may know where to find all the options and functionality in your program, but will an average user with typical knowledge be able to?

A usability test is simply a matter of asking someone to do each of the scenarios that you wrote. The purpose of a usability test is not to determine if the program is working correctly, but to see how well real people can use the program. In this way, a usability test is not judging the user; it’s an evaluation of the program. So start your usability test by explaining that to each of your testers. The usability test isn’t about them; it’s about the program. It’s okay if they get frustrated during the test. If they hit a scenario that they just can’t figure out, give them some time to work it through, then move on to the next scenario.

Your job as the person running the usability test is actually the hardest of all. You are there to observe, not to make comments. There’s nothing tougher than watching a user struggle through your program, but that’s really the point of the usability test. Resist the temptation to to point out “It’s right there! That option there!”

Once all your usability testers have had their chance with the program, you’ll have lots of information to go on. You’ll be surprised how much you’ll learn just by watching people using the program.

But what if you don’t have time to do a usability test? Or maybe you aren’t able to get people together. What’s the shortcut?

While it’s best to do your own usability test, I find there are a few general guidelines for good usability, without having to do a usability test:

In general, I see Familiarity as a theme. When I did a usability test of several programs under the GNOME desktop, testers indicated that the programs seemed to operate more or less like their counterparts in Windows or Mac. For example, Gedit wasn’t too different from Windows Notepad, or even Word. Firefox is like other browsers. Nautilus is very similar to Windows Explorer. To some extent, these testers had been trained under Windows or Mac, so having functionality – and paths to that functionality – that was approximately equivalent to the Windows experience was an important part of their success.

Also, Consistency was a recurring theme in the feedback. For example, right-click menus worked in all programs, and the programs looked and acted the same.

Menus were also helpful. While some said that icons (such as in the toolbar) were helpful to them during the test, most testers did not actually use the quick-access toolbar in Gedit – except to use the Save button. Instead, they used the program’s drop-down menus: File, Edit, View, Tools, etc. In fact, testers experienced problems when the menus did not present possible actions clearly.

And finally, Obviousness. When an action produced an obvious result, or clearly indicated success – such as saving a file, creating a folder, opening a new tab, etc. – the testers were able to quickly move through the scenarios. When an action did not produce obvious feedback, the testers became confused. These problems were especially evident when trying to create a bookmark or shortcut in the Nautilus file manager, but the program did not provide feedback, and did not indicate whether or not the bookmark had been created.

Usability is important in all software – but especially open source software. People shouldn’t have to figure out how to use a program, aside from specialized tools. Typical users with average knowledge should be able to operate most programs. If a program is too hard to use, the problem is more likely with the program than with the user. Run your own usability test, and apply the four themes for good usability, and make your open source project even better!

Jim Hall is a long-time open source software developer, best known for his work on the FreeDOS Project, including many of the utilities and libraries. Jim also wrote GNU Robots, and has previously contributed to other open source software programs including CuteMouse, GTKPod, Atomic Tanks, GNU Emacs, and Freemacs. At work, Jim is Director of Information Technology at the University of Minnesota Morris. Jim is also working on his M.S. in Scientific & Technical Communication (Spring 2014); his thesis is “Usability in Open Source Software.”