Dia is a program for doing diagrams such as flow charts, organization structure, etc., similar to the Visio tool from Microsoft.
It has versions for Windows and Linux and a FAQ file said it could be used on Mac with a special compile from source code (not for the faint of heart). There does not appear to be a simple Mac install.
Like much FOSS (Free/Open Source Software), Dia has a three piece version number. It is at version 0.96.1 but that is far enough along to be highly usable. It isn’t uncommon for the version numbering of FOSS programs to advance slowly. I am the happy user of several programs with version numbers well below that. Developers work steadily to advance from alpha stage numbers like 0.1.1 when the software may “work” but have very limited features and hasn’t been extensively tested for crash problems. The higher the middle number goes, the more “beta” it becomes with more features and an accumulation of loyal, and supportive users who contribute their comments, suggestions and complaints back to the developers. The middle numbers can go on for a while, not rising just to 9. There is no force to 1.0.0, since the middle number can rise gracefully to show versions like 0.12.5 while developers round off the sharp edges and add the final feature tweaks before the first “official release” of 1.0.0.
One program I use regularly is only at version 0.1.5 and works well. The developers have plans for much more improvement. What they have done works, and, typically, versions 1.0 and beyond represent more ambitious goals. FOSS software doesn’t need to wait for a 1.0 release. The philosophy is to get some initial working features. Implement them effectively. Advance from there. Set goals you can reach with the development team “staff” you have.
The tradition of FOSS flows out of the programming style of Unix. Around the original operating system, software developers created small, often single-purpose tools. If they needed a new “feature” they typically made a new small utility program instead of adding more features to another one. The idea was that you could string several utilities together to accomplish a more complex task. As a result, each “Unix style” program does just what it needs to. Over time, the simple program can be made more efficient, effective, elegant, etc. without taking on new features. The Unix style also usually produces fast programs.
Taking a huge jump from Unix utilities, we go to to the other extreme. Sometimes, you will even hear pundits and software reviewers talk about the feature glut of large programs, sometimes citing Microsoft Office as an example. As such programs grow, they often become “bloated” and become slower. In fact, these days, large programs are segmented, using overlay “libraries” (think files with the DLL extension) so they can fit in the RAM of typical computers. For commercial software, there isn’t a significant expanding market for common programs, such as Office. To make money from Office, Microsoft must sell new copies somehow. Of course, selling a new version of any software requires that it be worth buying and typically that means adding features. Very few end users notice incremental improvements in efficiency or speed. When there are competing commercial programs, you will often hear about “feature wars” and such as two or more similar programs try to leapfrog over their opponents. Word Perfect and Word were an example for a while.
Unfortunately, added features can cause their own problems. Again, using Office as the example, I understand that the new file format is a feature. It probably is better, but older Office versions cannot open the format. Users certainly must feel the pressure to upgrade, and to upgrade commercial software, that means spending money, too. In a school district the money isn’t insignificant. Schools with hundreds of computers must get hundreds of copies of Office…and pay for them.
FOSS development frequently has a small core of programming contributors, a wider core of dedicated users who participate through regular feedback of bug reports and recommendations. Some projects are “supported” by corporations who give employees time to contribute during the regular work day. Some of the bigger FOSS programs are projects that have full corporate support. OpenOffice.org is an example. Sun Microsystems did most of the original development and continues to offer a version called StarOffice which has commercial support. Open Office is a “community” project that Sun Microsystems continues to support, but has released it as FOSS and allowed its development to be a shared effort with contributions and leadership from people from outside the Sun corporate walls. Open Office is a competitor of Microsoft Office and has used the file format as a battleground. Do a Web search for ODF if you are interested.
Much FOSS has no big sponsor. Just as often, the development team is small. It may be just a few programmers, and occasionally a single dedicated coder. Small projects are often eager for contributions and advance when they get positive feedback from early users and grow to meet the needs of many users. Remember, a key to FOSS is source code access. That means a core of good code can be examined and enhanced, extended and improved by others beyond the small start. The first World Wide Web server/browser was such a project. Just look where that has gone!
The upshot of this discussion is that you shouldn’t hesitate to try a program because it isn’t version 1.5.0 or more. Even better, check the site where the developer(s) discuss the project and send them supportive suggestions that would make your use of the program better. If you don’t do programming yourself, you could write usage notes or tutorials or pages of a manual…You are entitled to make a contribution, after all you are a part of the FOSS community by participating at any level.
And, yes, you can be a community member just by using a FOSS program. Downloads from the developers site stimulate developers to keep going. They know they have a user base that way and feel their effort is appreciated.