Slashdot Mirror

PalmOS - once a closed-source winner... soon to be an open-source loser as the Linux-based OS supposedly in development is not adopted. Palm could dominate the market again if they pulled their heads out of their asses (not very likely).

I couldn't agree more. This has, unfortunately, bit me right on the ass, in a very topical manner, being the Lead Developer and Project Administrator for the jSyncManager Project, a SourceForge hosted project that provides a 100% pure Java protocol stack, synchronization framework, and full development kit for PalmOS-based devices. The project started in 1997, and at the time Palm even sent me a Palm III to aid in development (and Borland sent me a full suite of Java development tools as well, although as I wasn't developing on Windows I donated it to a good cause). In September 2002, I made the code OSS under the GPL/LGPL, and put it all up on SourceForge.

For a time, we were a big success. As the code ran identically on all platforms, it actually became very popular with German banks and insurance companies. IBM Germany even offered me a pathetic amount of money ($5000 US!) to buy the whole project (I turned them down, but as I was working for IBM at the time we did let it out with a new UI through IBM's alphaWorks as "ManplatoSync for Java"). Many corporations used it for synchronizing and managing their handheld devices, and it even got a write-up in JavaPro, and several other magazines. I even started going on the speaking circuit to talk about the technology behind the jSyncManager (the biggest one being the Wrox Wireless Professional Developers Conference, a series of three conferences which was cancelled after the first due to low pre-registration sales).

The ride was pretty good for a while, but Palm's complete and total lack-lustre record in this decade has caused the project to slide. I did get hired out to consult on integrating it into a medical health record system for hospitals that the Province of British Columbia was developing, but with the death of the PalmOS as a platform, demand for the project stagnated, and I could no longer afford to commit time to it.

So is the jSyncManager a winner, or a loser? At one point, we were in the top 5% of all SourceForge.net projects. We're still ranked rather highly, but in the life of the project on SourceForge we've only had just over 20 000 downloads. Activity is now virtually nil. The project is fortunately quite stable, but as the platform it relied upon is now pretty much a dead duck, and as interest has waned in Java-based projects that aren't web-service related, interest in the project has died as well. I've received perhaps two e-mails in the last 4 months on it.

It also hasn't helped that JSR-080 hasn't made much of a dent, and that it's availability is pretty much limited to Linux only (JSR-080 is the standard for communicating with USB devices in Java). We rely on this API for communicating with the more modern USB-based PalmOS devices, but it's poor availability on Windows and Mac OS X makes the jSyncManager less attractive. And Palm's slowness in introducing decent WiFi into their devices is also a problem (the fastest way to sync a PalmOS device is via WiFi, using HotSync over TCP/IP, which the jSyncManager supports on all Java installations).

The scope of the project always meant that we would probably never reach the Top 10 on SourceForge -- it was a tool that filled a specific niche. Windows users running the Palm Desktop software weren't about to convert en-masse to the Java-based jSyncManager. Users of other platforms, and organizations with mixed platforms loved it as it is easy for them to administer, and it works the same everywhere (including on platforms where they may have no other options). But in the end it's been Palm's poor record of advancing their platform that has done the project in, and now I'm happy to just put it into maintenence mode, and deal with problems if anyone cares to report them.

Yaz.

Things I !@$!@$!$@!@ hate about java: $CLASSPATH. It's slow. Memory Frigging Pig. Jsp (hint: slow, memory pig). Zealots who point to benchmarks to point out how fast it is. It's not. It's slow, go ask your users.

I have asked my users, and they tend to be surprised at how fast the jSyncManager is. At one time it was measurably faster than Palm's own HotSync Manager for Windows -- nearly 50% faster in some tests. And the jSyncManager is 100% pure Java. And the parsing code for the protocol stacks and data types is pretty complex. We've had users running this code on old Pentium-class systems, and the execution speed is still on par with native solutions.

So yes, I've asked my users, and they're typically surprised that Java can be so fast. The key is having a developer who knows how to optimize code, with a sound design. Doing a lot of the heavy lifting work yourself doesn't hurt either (i.e.: not relying on a lot of external frameworks), as does using as much parallelization as possible.

Hav eyou tried Jake2, the pure Java version of Quake 2? I have no speed issues playing it on my 1.33Ghz PowerBook -- it works like a champ.

Sorry, but Java speed complaints are mostly bunk. Swing does have some performance issues (although this can differ from platform to platform), but Java as a whole is quite fast. You simply have to have developers who know what they're doing when it comes to optimization and overall program design to make the most of it.

Yaz.

I don't think it is fair to use the swing memory argument anymore. It is really something that has been worked on.

I agree that there have been improvements, but I'm sorry -- I do think it's fair to continue to take Sun to task for this still.

A quick example -- the jSyncManager, my most popular OSS application. It can be run in either GUI or console mode. In both, the engine code is identical -- only the user interface differs. Firing it up in GUI mode uses about 35MB of RAM on my Mac OS X 10.4.5 based PowerBook. Firing it up in console mode uses ~15MB of memory.

That's a 20MB difference, and that is just after start-up. The GUI has a single window, with three menus, and a total of 11 menu items. There are NO widgets in the window -- instead it just has a graphic (it's meant to be run minimized -- the menus allow access to help, configuration items, and the log window). And yet that uses 20MB.

Activating every menu item that bring up a GUI dialog once, with the exception of the Help subsystem (which uses JavaHelp) brings it up to ~45MB of memory usage. Bringing up everything including JavaHelp once causes it to use ~55MB of memory. That is 40MB of GUI, and it is all absolutely trivial stuff -- excluding JavaHelp, it's probably less than 50 widgets all together.

True -- I have 1.25GB of RAM in my system, so 40MB is barely even noticed. Still, this is an absolutely trivial GUI (the complexity is in the data synchronization engine -- again, this application is meant to be a "fire-and-forget", run it in the background program which handles PalmOS data synchronization, and doesn't typically require any user input other than configuration).

For a more complex comparison, I fired up "Tapear", a clinical document management system that is part of another Open Source project I work on known as OpenTAPAS. It has only one window, but has hundreds of widgets of all types in it, with multiple tabs for a whole variety of different view types. It doesn't have much of anything in terms of an "engine", as it retreives all of its data from a remote database. After loading it up and opening up a single patient, it uses 80MB of RAM -- more than even my entire IDE (Xcode) uses by 25MB.

(I should note that all the above tests were done with the latest release version of Java 1.5 for Mac OS X (PPC)).

One more example -- Limewire 4.9 uses ~75MB of RAM with no transfers.

Sorry, but Swing is still quite memory hungry. Can you imagine running all of your applications as Java applications? Improvements are being made, but I think there is room for further improvements in this regard.

Yaz.

I'm curious why you released the source under GPL, and whether that worked out as you expected.

There were a few factors which played in this decision:

• I was fresh out of work, and needed a project to keep me busy,
• I didn't want to wind up in a similar situation with my next employer. By releasing the code as GPL/LGPL, and putting it on SourceForge, at least it couldn't be buried in a filing cabinet somewhere, even if I weren't permitted to work on it anymore (and with more and more employers in the computer industry permitting their employees to work on OSS projects on their own time, I was hoping that by being OSS when joining any such company I could potentially continue to work on the project under such a framework),
• Perhaps most importantly, the project was getting too big for just one person to work on. I needed outside help, but didn't have the money to pay people to work on it. Nor did I think it would be feasible to make it into a commercial product (although corporations are our biggest base of users, the jSyncManager is a tool that only a small fraction of a percentage of corporations have a need for, so finding customers would have been extremely difficult and expensive. The corporations which use the jSyncManager are spread all around the globe, with the majority of them overseas. Being Open Source made it easy for them to find us and try out our code with no layout of funding from me -- under the closed source model I would have had to spend a pile of money on all sorts of advertising just to find these customers in the first place)

How has it worked out for me? As with anything, there have been upsides and downsides. On the upside, in the end I have made some money from the project, through being hired as a developer and consultant in implementing it for a medical data system. I'm not making anywhere near what I did as a developer at IBM, but it's sufficient to live off. It's also allowed me to make some contacts and open some doors -- it's quite easy for me to show an organization my experiences in managing a diverse, dispersed team developing a fairly large project, and they can also see the overall project (and code) quality.

On the down side, I know what it's like for a project to have more users than contributors. I'm still the largest contributor to the project, and do the vast majority of the work (although this itself has increased and decreased over time -- some contributors come and go, while others have become too busy with their professional lives to contribute on a regular basis, but still follow the project). External contributions are very rare (but are greatly appreciated whenever they are given!). I can pretty much always use more help -- as it is right now, I do the vast majority of coding, administration, technical support, releases, and documentation. And as I do have responsibilities outside the jSyncManager Project, this often means that development appears to be very slow (it has been more than 2 years now since our last "final" release, although we have had a number of alpha and beta releases since that time (part of the delay being due to some time I served in the Navy and was unable to do any development)).

It also doesn't completely help that the very devices they project is designed to communicate with (PalmOS based handhelds) have been seeing a diminishing market share. It's always easier to find contributors and users when your target audience is increasing, rather than when it is decreasing (although a decreasing share can have an interesting bubble-effect, as those who are still embracing such a technology look for groups they can partner with for a reliable, medium-to-long term solution. Open Source is very attractive in this area, as you never know when a commercial, closed source partner might go out of business, or stop offering the product or support your organization needs).

So, as with anything, you have to take the good with the bad. My eperiences seem to have tended towards the good, although the benefits aren't always immediately tangible.

Yaz.

But even one segment of code from an outside author, released to them under GPL, would require the release of their SW's source under the included code's GPL.

The simple solution to which is simply to remove the contributed code completely, and independently re-implement its functionality (if having that functionality is desired and/or necessary).

I had to do something similar (but for a release in the opposite direction -- from closed source to OSS) for the jSyncManager Project. The version 1.0 series was coded entirely by myself, and was only ever released as closed source software (albeit as 100% free-as-in-beer software via the web; I completed v1.0 of this project as a thesis project, and felt that getting outside help by allowing others to inspect and comment on the code might have been considered "cheating" by some). A few weeks after v1.0 was released, I was hired by IBM Canada as a software developer.

The problem then became that nasty contract provision you have to sign when you join a company like IBM: the "what's yours is ours, and what's ours is ours" agreement, which basically states that anything you develop while employed by the company, even if it is completely on your own time and uses nothing learned from your employment at the company, belongs to the company. Fortunately, I was able to list existing technologies I had developed prior to joining IBM on said contract -- they were exempt so long as I stopped working on them while employed by the company.

There was, however, significant interest in the technology within IBM, and an IBM branded version called "ManplatoSync for Java" eventually made its way to IBM's alphaWorks website. It included a significant rewrite of the GUI code, along with some new functionality, parts of which were contributed by other IBM employees. The intention was always to release the sources under the IBM Public License -- but the legal eagles who had continuing discussions (which I wasn't part of), and kept holding off on a source release (the whole discussion of which apparantly died once I was released from the company).

When I was later let go from the company, and free from their restrictions as to what I could and couldn't work on, I decided I wanted to release the jSyncManager as Open Source Software. But I couldn't just take ManplatoSync for Java and re-brand it back to the jSyncManager -- it was encumbered with IBM copyrights. I couldn't even retain functionality since jSyncManager v1.0 which I myself had written in those intervening 2.5 years, because it too was considered IBM property (nevermind the fact that I wrote it and didn't get paid one single red cent by IBM for any of it. Indeed, when I was later invited to speak on the technology at various conferences, the company forced me to use my own vacation time to do so).

At that point, I had two choices: give up and find something else to work on, or suck it up and go back to the pre-IBM sources and work from there. And that's what in the end I decided to do: I took my pre-IBM sources, made them Open Source, and then worked my ass off to re-implement all of the lost functionality (along with a lot of functionality that the IBM releases never had, like USB device support and network data synchronization), and released it all as GPL/LGPL software.

The Nessus team could very well have elected to do something similar -- just strip out any external contributions, and then work from there. The unfortunate thing about going from Openn Source to Closed Source, however, is that contributors are now forced to take the teams word for it that they stripped out any such contributions (assuming that they didn't re-assign copyright to the Nessus project when they were submitted -- something I've never asked any of my contributors to do), as you can't look at the source to see if your code is still in it (i

Let's face it, blogs are vanity projects. You could just as simply write in your paper diary and keep it under your pillow like a little girl. Instead, you choose to put your diary on the web and open it up for criticism and comments. This is just another way of demanding attention.

I think you're over-generalizing. Yes, many blogs are indeed vanity projects where people say whatever they feel like about subjects nobody cares about, but there are good, worth-while blogs out there which have nothing to do about vanity.

Developer blogs are one such style of blog, which can be very useful. You can use these types of blogs to get "inside knowledge" on development projects, and get some insight into the developers themselves, while peerhaps learning some interesting tricks and techniques along the way.

Unfortunately, that is pretty time consuming and troublesome. Having to come up with original content every day to keep people coming back to your blog is pretty difficult.

You know, I've never understood why some people feel the need to post in their blogs every single day. It's like back in Grade 3, when the teacher insisted we write something in our journals every freaking day (I remember telling my teachers that I had nothing to say. They'd always say that I should write about my morning. But how many times can an 8-year-old kid write "I ate breakfast, brushed my teeth, and then came to this dump"??? But I digress).

I run a small developer blog that nobody ever visits (well, so far as I know :) ) here, where I talk about Open Source development projects I'm working on, example code in various languages/APIs, comment on tradde shows I attend, etc. But if I have nothing to say for three weeks, I won't post anything for three weeks. If people want to find out when I have something to say, that's what the RSS feed is for. If they want to know what I'm up to between times, they can e-mail me.

So I agree with you on this point. I think that blogs can serve a useful purpose, but if you're writing in your blog just for the sake of writing in your blog, and have nothing useful to say, you should probably take up a new hobby.

Yaz.

As you're a doctor, take a look at OpenTAPAS and the jSyncManager:

• OpenTAPAS
• The jSyncManager

OpenTAPAS is the Open Source Technology Assisted Practice Application Suite, which is designed specifically for physicians in clinical settings, and includes calendaring, messaging, and document storage, using both a web interface and PalmOS 5-based handheld systems. The messaging system in completely encrypted. OpenTAPAS is developed by the EGADSS Team at the University of British Columbia, and is headed by a family physician who is currently in clinical practice, and is backed up by the Vancouver Costal Health Service. Not only is it actively developed and maintained, but the project output is used by about 25 physicians in their day-to-day operations.

The document storage/retrieval system uses Plucker, a standard PalmOS document format and reader for offline hyperlinked document storage and viewing.

The jSyncManager is a pure Java, Open Source data synchronization system for PalmOS-based handhelds. It is completely platform portable, and provides a multi-port synchronization server which can synchronize hundreds of handhelds simultaneously through a single process. It is very highly optimized, and supports the jConduit plug-in architecture (it can also run conduits written for Palm's Conduit Development Kit for Java (aka "jsync", but no relation to the jSyncManager, which predates Palm's use of the name), if you're so inclined). Adding new synchronization routines is easier than other Linux-based PalmOS synchronization solutions, is easier for end-users to use (no "press HotSync first then start your application" junk like with some other systems...just drop your handheld into the dock and press the HotSync button as you would on Windows), and provides a security authentication module (which currently uses 4-factor security to identify users and handhelds, to ensure outsiders can't synchronize to your system).

And it's all Open Source software, licensed under the GPL/LGPL.

If you're interested, let me know and I'll get you in touch with the leader of the OpenTAPAS project personally. The project is evolving (Phase II of development is set to start very soon, implementing an encrypted patient record system which will synchronize with standard eHealth record formats so you can carrry patient summaries and mark up patient records on your Palm), so there is a lot of good stuff coming down the pipe. And as it's Open Source, as they say, the more the merrier!

(Disclaimer: I'm a paid member of the OpenTAPAS project, and the originator, administrator, and lead developer of the jSyncManager Project).

Brad BARCLAY

As you're a doctor, take a look at OpenTAPAS and the jSyncManager:

• OpenTAPAS
• The jSyncManager

OpenTAPAS is the Open Source Technology Assisted Practice Application Suite, which is designed specifically for physicians in clinical settings, and includes calendaring, messaging, and document storage, using both a web interface and PalmOS 5-based handheld systems. The messaging system in completely encrypted. OpenTAPAS is developed by the EGADSS Team at the University of British Columbia, and is headed by a family physician who is currently in clinical practice, and is backed up by the Vancouver Costal Health Service. Not only is it actively developed and maintained, but the project output is used by about 25 physicians in their day-to-day operations.

The document storage/retrieval system uses Plucker, a standard PalmOS document format and reader for offline hyperlinked document storage and viewing.

The jSyncManager is a pure Java, Open Source data synchronization system for PalmOS-based handhelds. It is completely platform portable, and provides a multi-port synchronization server which can synchronize hundreds of handhelds simultaneously through a single process. It is very highly optimized, and supports the jConduit plug-in architecture (it can also run conduits written for Palm's Conduit Development Kit for Java (aka "jsync", but no relation to the jSyncManager, which predates Palm's use of the name), if you're so inclined). Adding new synchronization routines is easier than other Linux-based PalmOS synchronization solutions, is easier for end-users to use (no "press HotSync first then start your application" junk like with some other systems...just drop your handheld into the dock and press the HotSync button as you would on Windows), and provides a security authentication module (which currently uses 4-factor security to identify users and handhelds, to ensure outsiders can't synchronize to your system).

And it's all Open Source software, licensed under the GPL/LGPL.

If you're interested, let me know and I'll get you in touch with the leader of the OpenTAPAS project personally. The project is evolving (Phase II of development is set to start very soon, implementing an encrypted patient record system which will synchronize with standard eHealth record formats so you can carrry patient summaries and mark up patient records on your Palm), so there is a lot of good stuff coming down the pipe. And as it's Open Source, as they say, the more the merrier!

(Disclaimer: I'm a paid member of the OpenTAPAS project, and the originator, administrator, and lead developer of the jSyncManager Project).

Brad BARCLAY

I think this is a very grand move by Google, so don't take this the wrong way, but what about trying to provide some money to people who are already coding Open Souce Software, and who do so purely for the love of it, and who could otherwise really use the money?

There are a lot of "starving coders" out there who are working in Open Source. Indeed, in several of my projects I tend to find that some of the better developers are those who have lost their jobs, or who have had to take some other job, and who want to keep their coding skills fresh by working on a project, doing the type of coding they really want to do.

These are the people I'd send money to first. They're already producing Open Source code, and for the vasst majority of them, nobody is lining up to throw money at them like this.

Think about this: how many of these students who receive this stipend will wind up continuing to contribute to the Open Source community after they graduate? I'm willing to bet that the ones who are likely to willingly participate in an Open Source project and who have an aptitude for it are already doing so, and are already somewhat aware of what Open Source means, and how Open Source projects are administered and maintained. For the others, what guaranteee is it that the money is well spent? What if they get their money, fulfill the requirements of the award, and then never produce or contribute to an Open Source project again?

I think Google's gesture is grand -- but maybe they should start rewarding some of the existing foot soldiers of Open Source before offering OSS "recruitment bonuses" to people who may never contribute anything useful to the OSS movement/codebase.

Brad BARCLAY
Lead Developer & Project Administrator,
The jSyncManager Project (and several others).

It's always great to hear from the /. peanut gallery of people who don't develop Open Source, who use lots of Open Source, but who don't generally donate any time, effort, or money to Open Source sound off on subjects like this, but maybe you'd like to hear from someone who is running an Open Source software project which does have a sponsor.

My project, the jSyncManager, has had a (somewhat indirect) sponsor for the past six months. Basically, this sponsor (who runs a department at a large University) needed an Open Source, platform neutral solution for synchronizing PalmOS-based handheld systems in the healthcare field, and decided to use the jSyncManager. In turn, they hired me on as a consultant to the project, doing Open Source software development.

This has been useful, as I've been doing Open Source development full time for the past year. It gives me a chance to work on my projects. The output I create for them is Open Source (GPL). And I have some funds I can now use towards the jSyncManager Project. They have also donated resources back to the jSyncManager Project.

I'm not going to get rich off their funding and the resources they've donated (sending me new handheld hardware was a huge boost, for example) -- but it's more than enough to support the needs of the project.

So please take a moment to take a look at their project (TAPAS). I would have continued jSyncManager development even without them, but their support has been a huge help, and has allowed me to do things like eat on a regular basis :).

Brad BARCLAY
Lead Developer & Project Administrator,
The jSyncManager Project.

So does someone have the answer? What the hell do these terms mean, and are they useful any more?

I've always had a (slightly) different definition (and number of letters) for the various "greek letter" status elements (which I use in my Open Source project, the jSyncManager):

1. alpha - A work in progress which is feature incomplete.
2. beta - the product is now feature complete, and requires rigourous testing.
3. gamma - All bugs found in the beta phase have been fixed, with a last opportunity to detect any problems with the fixes themselves (effectively what others call the "Release Candidate").
4. final - Done like dinner. Package it up and get it into the hands of customers.

The problem I run into isn't the never-ending beta -- it's the never-ending alpha stage :P. A big part of this tends to have to do with trying to fit in user requests for enhancement, and simply not having the time nor manpower to get it all done in a timely manner (as we're not a project that attracts a lot of developers willing to contribute to the core). Our beta phases tend to be fairly short, in large part because once we hit beta, we've typically hit a feature freeze as well, and are only going to fix bugs.

IMO, if it's not feature complete, you have no right calling it a "beta", as much of your high-level testing is going to be useless if you're going to be adding code during the beta phase. Adding new features effectively "resets" the status back to the beginning of "beta" -- making the term effectively meaningless.

But I guess I'm just old fashioned that way...

Yaz.

As an Open Source developer myself, who likewise has their project hosted on SourceForge, maybe I can help somewhat.

This can be a really hard question to answer. Ideally you'd like to find yourself a maintainer to work with you on this sort of thing, but finding one is a different matter. Such a maintainer will either worm their own way out of the woodwork, or they won't. Recruiting one yourself will probably be a lengthy and fruitless prospect.

In the more than two years my project has been Open Source (it was closed source freeware for 5 years), recruiting more people to work on the project has been nearly useless. In that time, after lots of recruitment campaigns, I've found only 4 or 5 people who have actually made any significant contributions to the project and all of its sub-projects (the last time I tried to run a recruitment campaign a few weeks ago I got about 50 responses, virtually all from India, who somehow interpreted "looking for a volunteer developer" to mean I was looking to hire someone for a job :P).

Depends completely on your project. SourceForge is a good general place to host your project if nothing else fits -- they provide a good service IMO -- but they also host any project which is Open Source. If you can find one, you might be better off using something which is a more targeted community for your type of project, whether it be by language/develpment environment used, target OS, application type, etc. That is, if you're developing a Java-based project, java.net is a good choice, as everyone there is working in Java. If you're developing on OS/2, netlabs.org is where you'll find other OS/2 developers (what few there still are). If you're coding for Linux on the PlayStation 2, playstation2-linux.com is the place for you.

Don't forget -- nothing really prevents you from registering your project on every project site that suits your project, although maintaining all of those active communities might prove very time consuming!

Create your own. Typically what I do is credit the user by name and e-mail address during the CVS check-in. As I use the CVS log as the basis of the changelog for each release, this information also becomes part of the changelog. I also try to add an entry for them to my "Special Thanks" section of my Release Notes, and sometimes a comment crediting their fix/addition right in the source code. If the contribution is really significant, they usually also get a credit in the copyright statement.

One thing you should do, however, (something that I try to do at least), is to ask them if they want credit. Some people won't (and I've had a few contributions like this) for various reasons. Maybe they don't want to be bothered with questions, or maybe their employer has a draconian policy against this sort of thing (although in the latter case, you probably don't want to accept anything new from them so as to CYA. A minor fix that won't be subject to any copyright problems should be fine, however (ie: someone pointing out that an "i--" should be "i++", etc.).

Well, there used to be a standard, but far too many projects have v

As an Open Source developer myself, who likewise has their project hosted on SourceForge, maybe I can help somewhat.

This can be a really hard question to answer. Ideally you'd like to find yourself a maintainer to work with you on this sort of thing, but finding one is a different matter. Such a maintainer will either worm their own way out of the woodwork, or they won't. Recruiting one yourself will probably be a lengthy and fruitless prospect.

In the more than two years my project has been Open Source (it was closed source freeware for 5 years), recruiting more people to work on the project has been nearly useless. In that time, after lots of recruitment campaigns, I've found only 4 or 5 people who have actually made any significant contributions to the project and all of its sub-projects (the last time I tried to run a recruitment campaign a few weeks ago I got about 50 responses, virtually all from India, who somehow interpreted "looking for a volunteer developer" to mean I was looking to hire someone for a job :P).

Depends completely on your project. SourceForge is a good general place to host your project if nothing else fits -- they provide a good service IMO -- but they also host any project which is Open Source. If you can find one, you might be better off using something which is a more targeted community for your type of project, whether it be by language/develpment environment used, target OS, application type, etc. That is, if you're developing a Java-based project, java.net is a good choice, as everyone there is working in Java. If you're developing on OS/2, netlabs.org is where you'll find other OS/2 developers (what few there still are). If you're coding for Linux on the PlayStation 2, playstation2-linux.com is the place for you.

Don't forget -- nothing really prevents you from registering your project on every project site that suits your project, although maintaining all of those active communities might prove very time consuming!

Create your own. Typically what I do is credit the user by name and e-mail address during the CVS check-in. As I use the CVS log as the basis of the changelog for each release, this information also becomes part of the changelog. I also try to add an entry for them to my "Special Thanks" section of my Release Notes, and sometimes a comment crediting their fix/addition right in the source code. If the contribution is really significant, they usually also get a credit in the copyright statement.

One thing you should do, however, (something that I try to do at least), is to ask them if they want credit. Some people won't (and I've had a few contributions like this) for various reasons. Maybe they don't want to be bothered with questions, or maybe their employer has a draconian policy against this sort of thing (although in the latter case, you probably don't want to accept anything new from them so as to CYA. A minor fix that won't be subject to any copyright problems should be fine, however (ie: someone pointing out that an "i--" should be "i++", etc.).

Well, there used to be a standard, but far too many projects have v

Take a look at the Technology Assisted Practice Application Suite, which is based on Zope/Plone (written in Python), the jSyncManager (a pure Java (J2SE) synchronization protocol stack and toolkit for PalmOS-based handhelds), and some custom applications.

This project is geared towards two areas: online access for medical offices, hospitals, retirements homes, etc., and handheld access using Palm Tungsten C handhelds. It uses open tools and open standards, and is released completely as Open Source. Phase One, currently under development, is implementing handheld management systems, security (both validation and encryption) calendaring, and messaging. Phase Two, starting Spring 2005, will be implementing patient data.

Being open and using languages like Python and Java, the suite runs virtually anywhere. The prototype systems are running Debian, however I often do development and testing against a similar setup on Mac OS X (as I develop all of the handheld synchronization and management routines).

Before you go out there and start writing soething similar from scratch, you might want to see if there are Open Source tools you can build upon and extend for your purposes first.

TAPAS is, BTW, being developed in conjunction with a major university, a major hospital, a group of doctors, and a provincial Ministry of Health here in Canada. You might want to take a look at what we're doing before jumping in and starting from scratch yourselves.

If you'd like more information, please feel free to drop me a line. In particular, if your company hasn't even considered the handheld side of your system, let me know as I have a lot of expertise in this area.

Brad BARCLAY
Lead Developer & Project Administrator,
The jSyncManager Project.

That would be great but could you please come up with full support for syncing with Linux as well?

There is already an excellent cross platform, Open Source PalmOS synchronization solution that runs on Linux (and Mac OSX and Windows and OS/2 and Solaris and everywhere else) called the jSyncManager.

It has all of the necessary APIs for synchronizing calendars and accessing the handheld Expansion Manager and Virtual File System.

What it needs it some more jConduit plug-ins written for accessing popular Linux applications. However, it has an extensive API and is licensed under the GPL/LGPL, so Palm (or anyone else) could very easily create a Linux-integrated synchronization tool if they so desired.

Brad BARCLAY
Lead Developer & Project Administrator,
The jSyncManager Project.

I guess where I'm going is that, MOL doesn't work here, because all this crap she bought is for Windows, and I don't need to continue this paragraph...

Hey, sounds like it's time for me to start my own Linux distro - M-O-L (Mom-On-Linux) ;).

(And if it wasn't for the fact I already run an Open Source Project and may soon be starting another one, I might seriously consider it).

Yaz.

Why didn't I think of that?

I don't know, but now that you know, feel free to use it in your own projects :).

Actually, for anyone interested in how I typically write easy-to-read code, check out this PDF document (or the HTML version). These are the coding guidelines I wrote up (and follow) for the jSyncManager Project. And yes, they're enforced (albeit not in a draconian manner -- if another developer misses something, I usually just fix it for them as opposed to nailing them to the wall :) ).

Good Open Source code needs to be readable and easy to work with IMO. If you want to attract more developers to your project, and/or want third-party developers to use your Open Source APIs, you need to make sure when they grab your code they can get working with it with an absolute minimum of hassle, and as much information as they need. The last thing you want to make them do is go through all your code with a fine-toothed comb trying to figure out what it's doing. They want to write code, not try to figure out what the existing code is doing manually.

Just as nobody likes to read a novel with no paragraph breaks/indentation, no chapter breaks, and no formatting, nobody should have to read messy code. Writing elegant looking code with useful comments takes very little time (particularily if you're a fast typer), and is always worth the extra effort, especially in an Open Source project that is close to your heart.

Speaking of which, if anyone out there is interested in developing code for an Open Source, pure Java data synchronization solution for Palm OS-based handhelds, or using such code in one of their own projects, send me an e-mail :) ).

Yaz.

Or, perhaps not read this...

Okay, I know that there are a lot of professional developers out there who follow some of the "rules" in the article, especially those involving ignoring warnings. I've been in professional programming environments, and I've seen this sort of thing excused all too often (personally, my code isn't done until it compiles 100% cleanly). However, for good or bad, this is typically hidden in closed-source projects -- how many compilation warnings does Microsoft get in its nightly Windows builds? I have no idea.

Unfortunately, in Open Source Software everyone gets to see where the developers ignore warnings, and IMO there isn't much excuse for it. Honestly, there are far too many Open Source projects which seem to do the things this article "advocates". And everyone gets to see it.

I remember all of the warning messages I get when building the Linux 2.4 series kernels. And I recently looked into forking the recently cancelled JPluck, but its near complete lack of code commenting makes the effort exceedingly difficult.

This has long bothered me. If you're going to release your code as Open Source so others can work with it, it should at least have some comments in it (even just simple things like the expected input.output values for procedures, functions, or methods, expected use for variables/fields, etc.), and it should generally build without a single warning [1], in order to make it easier for others to work with the code, and to ensure them that there aren't going to be any unexpected results due to ignored warnings.

Yaz.

------------

[1] Okay, I know someone is going to call me a hipocrite when they go and grab the sources for the Open Source project I administer (the jSyncManager), build it, and find well over 100 warnings. I just want to preempt this by stating that these deprecation warnings occur because I've specified parts of the jSyncManager API to be deprecated to ensure developers currently using these deprecated classes move their code over to their replacements.

(Caveat: looks like there might be 3rd party support, but a friend of mine told me MarkSpace leaves something to be desired.)

Once Apple releases their iSync development kit I'm planning on writing the necessary jConduit(s) to synchronize the OS X calendar and address book via my Open Source jSyncManager.

The jSyncManager already has an OS X disk image, but what's currently missing is the ability to connect to a USB port through Java on the Mac. Once javax.usb is ported to OS X, this limitation will be removed, and you'll be able to run the jSyncManager like any other OS X application.

And with an iSync jConduit, the jSyncManager will be just as good as, if not better than, Palm's HotSync Manager for the Mac.

Brad BARCLAY
Lead Developer & Project Administrator,
The jSyncManager Project.

If you have a variable name or package name called "enum" anywhere in your source code you'll have to replace every instance of it with something other than "enum."

Yup -- I ran into this test building the jSyncManager yesterday.

Thankfully it was only four instances, all within the same source file. I fixed the latest CVS copy accordingly, alerted the developer mailing list, and posted a new item about it to our project page on SourceForge.

Otherwise, so far, so good. I'm looking forward to this release getting much wider availability (ie: on more platforms) in order to use the typesafe collection mechanisms.

Yaz.

If you have a variable name or package name called "enum" anywhere in your source code you'll have to replace every instance of it with something other than "enum."

Yup -- I ran into this test building the jSyncManager yesterday.

Thankfully it was only four instances, all within the same source file. I fixed the latest CVS copy accordingly, alerted the developer mailing list, and posted a new item about it to our project page on SourceForge.

Otherwise, so far, so good. I'm looking forward to this release getting much wider availability (ie: on more platforms) in order to use the typesafe collection mechanisms.

Yaz.

You had to post this just as I got mod points, and was going to start using them in this forum...:).

I find what you have to say very topical, because I was in talks earlier today with an MD who holds a chair at a west-coast University who is interested in contracting me out to write Open Source code based on my Open Source, pure-Java jSyncManager Project.

Oh the parallels :). This project is receiving some public funding, so the doctors and developers currently involved are striving to use as much OSS as possible, and to release their custom code pieces as Open Source software. They want to contract my services to help them integrate handheld systems into their groupware/messaging applications they're building.

As such, it looks like I'm about to start getting paid to write Open Source Java code for the medical field. Yay for me!

Yaz.

I like Java. I maintain an Open Source project coded in Java. I particularily apperciate the fact that Java applications can be easily made completely portable across platforms.

Here's what concerns me. Open Source has never really shown that it's terribly interested in ensuring API and binary compatibility across releases. Native binaries tend to be somewhat tightly compiled for their specific distro. To get around this, many packages are distributed as source so you can compile them specifically against your platform of choice.

All well and good, but take a look at how the sources accomplish this: via pre-compiler directives to ensure things compile correctly on different platforms, or via complex makefiles to build specific sources on specific platforms.

Currently, I don't typically have to worry about such things with Java. There are no pre-compiler directives, and there is no need to use them: one codebase compiles on every platform.

Here's where my concern comes in. As soon as you Open Source Java, someone is going to want to put in pre-compiler directives because they're used to them from the C/C++ world. Around the same time, someone is going to create a Java fork which isn't 100% compitable in some area.

Java developers, wanting to target as many platforms as possible, are going to start using the pre-compiler directives in order to work around implementation-specific bugs. Maintainers are going to start worrying less-and-less about API compatibility issues because developers are going to have pre-compiler directives to work around them (as we've already seen many times over the years in the C/C++ world). All of which is going to help reduce Java's platform neutrality, and make my job as a Java developer more complex than it is currently, reducing incentive to use it in the first place.

My biggest interest as a Java developer would be to ensure that all Java runtimes conform to a single, standardized testsuite as Sun seems to want. And I don't care that the testsuite could be buggy -- so long as any API bugs that do exist are consistant across platforms. At the same time, there are some amazing things the Open Source world could do with all the other parts of the Java Runtime Environment -- for example, making the HotSpot Compiler Open Source could allow for some pretty massive JIT research to be consolidated in one place for the benefit of everyone.

Much of this could be solved if Sun put the Java API and other technologies through an official standardization process, and then made their implementation Open Source. The former has worked well for other languages (Ada comes to mind), where a tight standardization process long helped to ensure source compatibility between platforms. The latter works extremely well for enhancing the adoption and development of a given technology. But to make it work, you couldn't just go with some form of defacto standard that most Open Source projects use/create/adopt. Unfortunately, I'm not quite sure what benefit Sun would see from doing something like this (not that I personally care anything about wether or not Sun were to get anything out of doing this -- I just realize they're going to need to see some sort of benefit before they ever decide to do such a thing).

Yaz.

I see no benefit to OSS. The bogus argument that flaws are discovered because more eyes look over the code has never been shown to be valid. Keep believing that if you'd like. The evidence shows there's no benefit (or else how do vulnerabilities exist in multiple versions?)

The vulnerabilities exist in the first place because at the core, Closed Source and Open Source developers work the same way: a human sits down at a console and types in the code. At this stage there is no difference between Open Source and Closed Source software development. As such, similar problems are going to occur in the production phase.

And there is never any guarantee that a problem is going to be discovered. Sommetimes it takes multiple revisions before a problem is found. I'm not arguing that Open Source magically makes all bugs and security issues disappear -- however, under Open Source they are vastly more likely to be found, and due to the open nature of the code, are going to allow for quicker fixes (as the person detecting the bug can in fact fix it themselves and contribute the fix back to the maintainers).

And in the case of Mozilla, this is exactly what has been happening. People find the problems. People with no connection whatsoever to Netscape/Mozilla.org have fixed the problems. And we're wound up with a much better product because of it.

I don't see anyone here claiming that OSS is 100% secure. It isn't. However, it does have benifits to getting problems detected and fixed quicker than closed source software does.

I see it firsthand all the time. I've worked in big closed-source software development projects (IBM). I've also worked in many Open Source Software development projects (and even administer a medium-sized project myself).

Open Source has tangible benifits over Closed Source software when it comes to the detection and fixing of bugs. Deal with it.

Yaz.

I think it is the developers of the little known OSS projects that are still being worked on simply due to the love they have for their projects that are the true unsung heroes of OSS.

I agree, and these are the people I was hoping would really be discussed here (and thankfully, in some cases, they are).

There have been lots of suggestions here for people who have developed major Open Source applications virtually everyone here on /. knows about -- and while these people have done some excellent work, many of them are already "well sung". But there are also people out there working on more esoteric projects which are exceedingly using to that 0.0001% of the software users out there who need it, but of whom we rarely ever hear anything about.

I'm going to use my project as an example (hey, I'm a shameless promoter :) ), the jSyncManager. Here is a project for synchronizing PalmOS devices in Java-based environments. It's only useful to a subset of Palm-based handheld device owners (which is already a small subset of all PC owners) -- those who need consistent synchronization services for their devices across a variety of platforms, with Java-based tools for the rapid development of data synchronization logic.

Most of our users aren't hard-core Open Source users that go around promoting our project -- it's corporations running mixed environments that aren't server by other solutions. The end-user with a few Linux boxes will probably run pilot-link or coldsync (because they're built into most distros and are native code). End users running Windows or OS X are probably running PalmSource's HotSync Manager.

We're a specialized tool which fits a niche no other tool fits into -- but because of this, our target user base isn't massive.

And yet we have a number of people who have taken time to contribute to our project, because they wanted a single sync solution that runs on all their platforms, because they want something better than what they're currently running (and yes, in my very biased opinion the jSyncManager is a vastly better API/framework/application base than pilot-link, coldsync, or Palm's HotSync Manager :) ).

So big props go out to David Bartmess, Ian Dallas, Anuj Agrawal, Steven Levine and Bob Yurkovic for everything they've contributed to the project. These guys have donated their time, and they've received for their hard work even less recognition than I have. Thanks guys -- you may be unknown to the /. masses, but you've all done an excellent job, and are my Open Source heroes.

Brad BARCLAY
Lead Developer & Project Administrator,
The jSyncManager Project.

Anyway, it's ridiculous that I currently have to manually update 2-3 address books on my windows laptop alone, not to mention trying to keep them up to date on my linux server or mac.

Things seem to be much better in this regard on the Mac, as the Mac has its built-in Address Book, iCal, iSync, and Safari which are nicely integrated both together and with the OS. Lots of OS X applications will rely on the built-in Address Book instead of re-inventing the wheel (the notable bad exception to this being the Palm Desktop for the Mac -- something I intend to remedy with my jSyncManager once I get my hands on the iSync SDK promised by Apple at the WWDC earlier this year).

As someone who deal with this sort of thing all the time, the thing that bugs me the most is that every application out there feels the need to re-invent the wheel and come up with its own way of storing address and calendar data, when the associated data rarely (if ever) changes. It's a waste. We need a standard database for storing these two data types that PIMs can simply share, and the problem will be completely solved. OS X comes close. Linux could do this easily. However, so long as each and every application using such data decides it needs to have its own databases/data files to store this information, and its own format for the information, we're going to be saddled with such problems.

Brad BARCLAY
Lead Developer & Project Administrator,
The jSyncManager Project.

How can you give away the source for free, yet also charge for the software? What stops people just downloading the source and compiling it, without paying? Or do you just rely on people/companies being good enough to CHOOSE to pay for it, when then don't actually have to?

If you're distributing an end-user product targeted towards non-techies, many of them simply don't want to be bothered with having to compile and set-up everything. They don't want to have to ensure they have a compiler installed (remember: other than Linux/*BSD/OSX, most consumer OS's of the last 10 years don't come with a compiler), and all of the necessary pre-reqs to do the build. They want something that comes packaged inside a nice installer that just works, and in many cases couldn't care less if they could get it for free if "free" means having to go through a whole pile of complex mumbo-jumbo they don't care about.

That's the situation my project, the jSyncManager is in. To build everything, you need the Java2 SDK v1.3 or better, Apache Ant, the Java Communications API, the Java USB API, the jUSB API, jDOM, Java Help, Java Mail, and Java Activation. To run the jSyncManager, you need many of the same APIs installed (although we've coded things to make some of these packages optional -- if you don't have Java Help installed, for example, the Help option is simply greyed out). You can download the three JARs for the jSyncManager, and put them into the right directories and create the necessary desktop icons yourself if you want -- but many of our potential users get confused at "Java" -- nevermind all the rest.

We do have some bundles with all the right cross-platform APIs present and accounted for, and are hoping to put together some platform-specific bundles with nice installers and the platform-specific libraries (like javax.comm and javax.usb) -- but it's a lot of work. We have lots of users (and potential users) who would be happy to pay a small fee to have us put everything together in an easy-to-install package so they don't need to know the underlying magic incantations, and they don't have to go around to half a dozen (or more) different websites to download and set-up pre-reqs.

Sure, advanced users will simply download the parts and put things together themselves, paying nothing -- that's what I expect them to do. But there are people out there willing to pay for convienence as well. And why shouldn't I make a bit of money to give them what they want/need?

Brad BARCLAY
Lead Developer & Project Administrator,
The jSyncManager Project.

I'm considering doing just this with my jSyncManager Project, which is licensed under the GPL/LGPL (the API is LGPL'ed, the applications built on top of it are GPL'ed).

While I already provide the source for free online, along with binaries, it's a Java application, and it requires several pre-requisites which are platform-specific (like the Java Communications API, and/or the Java USB API). Users can go out and get all of the parts that are specific to their platform, but many of them find this too much of a hassle.

So I'm thinking of putting together some bundles with some platform-specific plug-ins for different platforms and charging a small fee for them (as I put a lot of effort and money into this project, and wouldn't mind making something back from it all), wrapped in platform-specific installers to make things really easy for end-users. Power users would still have the option of putting everything together themselves -- compiled binaries for the parts would still be made available for download -- but for those users who need a more traditional installable program that just works, I'd like to make the option available for them at a reasonable price, without changing the licenses at all.

Brad BARCLAY
Lead Developer & Project Adminsitrator,
The jSyncManager Project.

Would it really be so hard to sync to Palm Desktop AND Thunderbird at the same time?

Yes, in fact, it is. Three-way synchronization is exceedingly difficult to manage and get right. It's much better to simply have a single host-side database to synchronize against, and simply have each application use it for their data storage. Having three different calendar applications each with their own unique databases and ways to correlate their records with the records on the other PIMs and then trying to synchronize the three is often disasterous.

If all of the synchronizations are two-way, for N applications you need to run through N! synchronizations. And with each application having its own data format, and then having to correlate each record with its matching record (IF it's present) in the other application -- well, we're talking about quite a lot of complexity.

A simple two-way synchronization is difficult enough -- just take a look at how many existing conduits regularily get things wrong (it doesn't help that most calendars also have different mechanisms for handling repeating entries, but don't get me started on THAT subject...).

If anyone is interested in writing some decent Mozilla PalmOS sync code, go and take a look at the jSyncManager. It's an Open Source, pure Java PalmOS data synchronization solution which, as it has its own protocol stacks, runs on any Java-enabled platform, and has its own Java-based jConduit plug-in specification. A Mozilla jConduit set could run the same on Windows, MacOS, Linux, OS/2, and every other Mozilla supported environment with little (or no) code modification.

(We do have an outstanding RFE to add Mozilla sync facilities, but we don't have the developer resources to do this. The project has two developers who regularily work on the code base, and most of our time is spent working on the jSyncManager itself. So if there are any Open Source Java developers out there who want to tackle this problem, let me know -- we'd love to have you aboard).

Brad BARCLAY
Lead Developer & Project Administrator,
The jSyncManager Project

Old hardware rocks, I can't get enough of it :)

You said it. If you actually want some more details on what I have on my network, the systems involved are:

• A PIII-450 system with 384MB RAM running OS/2 WARP Server for e-business as my general workstation for running DOS, Java, OS/2, and X sessions,
• A Celeron 550 box with 128MB RAM running RedHat 8. This acts as my network fileserver, DNS (I'm starting to build up too many systems to want to worry about coordinating the hosts files between them all), and automated nightly build system for jSyncManager Project, running in headless mode,
• My 1.33Mhz PowerBook G4 laptop (which has been taking over most of the duties I used to use the OS/2 box for these last few months), networked wirelessly (everything else is wired),
• The P-133 with 32MB RAM acting as my own personal mail server, running RedHat 8 (a brutal install to pare it down to fit on the 1GB drive in that system, and yet still be semi-useful. :P), also running headless,
• An AMD K6-2 running at 450Mhz with 128MB RAM, an old CD-ROM drive, and absolutely NO hard drive, running Knoppix. I use this as a guest machine -- it has Mozilla and OpenOffice on it, so if a visitor wants to check their e-mail or surf the web or work on a document, they do it on this machine (as they can do whatever they want to it, and all I have to do to restore it is a reboot),
• A PlayStation 2 with Sony Linux for the PlayStation 2 installed. With the kits 40GB of hard drive space, this acts as both my file server and my media server (I did the first official port of Ogg Vorbis to the PS2 on this system) -- being able to do 48Khz output via optical cable to my home theatre makes this a wonderful media box,
• A SitePlayer Developers Kit. Not doing anything particularily useful, but I'm eventually going to get into the microcode and make this into a web-enabled controller for my homes X10 network,
• An IBM WorkPad c505 (mostly for jSyncManager network sync development).

I've had more systems, but that's what's currently running on my network. I've had a few people promise me some more systems -- I'm just trying to figure out what to do with them before accepting them (after all, have to put them to good use...;) ).

Yaz.

Most of the complaints about Graham are likely from people who are just barely programmers.

I call bullshit on you.

I'm complaining about Graham and other language-bigots, and over the last 20 years I've coded in:

• Java
• C
• C++
• REXX
• ObjectREXX
• Ada 83
• Ada 95
• Modula-2
• Pascal
• Basic
• x86 Assmebly
• VAX-VMS Assembly

...and have dabbled in many others (and I'm exccluding a whole slew of scripting languages from the above list). And I've written that code on and for the following platforms:

• Mac OS X
• Mac OS 7
• VMS
• OS/2
• AIX
• HP-UX
• Solaris
• Linux
• *BSD
• Dynix
• Windows (3.0 to 2000)
• DOS
• CP/M
• PalmOS
• S/390
• PlayStation 2

... and that list excludes older systems I started on like the Commodore 64 that didn't have an Operating System (per-se).

And much of this development hasn't been on small projects either. Indeed, a good portion of my platform development experience came about when I worked at the IBM Toronto Softwre Development Lab, doing DB2 development.

And I'm a Java developer. And not because I have to for job purposes (indeed, I generally refuse to work at jobs using Java, because most Java-related jobs suck), but because it's a language and environment with strengths not sufficiently matched elsewhere. I've programmed AI solutions in Java, protocol handlers in Java, and various other complex tasks beyond your usual "call a bunch of APIs" crap you seem to paint Java developers as doing.

Ok, for pure brainpower here is the competition I propose: Take a Python programmer and a Java programmer. They tackle the same problem in both Python and Java. I'm betting on the Python guy to present better solutions in both languages.

I'd take that bet, and then completely wipe the floor with whomever you pitted me against :).

Sorry, but this sort of language bigotism really gets to me. Yes, there are crappy Java developers out there. Yes, many organizations doing Java development are targeting mundane tasks. But same goes for every other language out there -- the only difference is in degree.

In my years of speaking at conferences and chairing workshops on topics in computer science research, I've met a whole pile of brilliant people working in Java to solve complex problems. I've seen it used for artificial intelligence, robotics, research operating systems, protocol stacks, and game development -- more compilcated projects than your typical Python developer is ever going to tackle (nevermind all of the VM research I've seen surrounding Java).

Brad BARCLAY
Lead Developer & Project Administrator,
The jSyncManager Project (Open Source Java at that).

A lot of people choose Java, but only a very small number for open source projects, especially if you discount projects that were initiated by corporations. If Java is so great, why don't they use it?

Because Java has quite unfairly been given a bad rap by people who don't understand it, coupled with the fact that most operating systems don't make it easy to run Java applications (until fairly recently).

And I speak as someone who administers an Open Source Java Project that wasn't initiated by a corporation.

Outside the Unix world you don't see a whole lot of Open Source Python projects either.

Yaz.

I just downloaded this myself.

Wasn't it iSync v1.5 that they promised at the WWDC they'd release the developers kit for? I'd love to be able to provide iSync access through the jSyncManager for syncing with iCal and Address Book, so I've eagerly been awaiting the iSync SDK.

I don't see any mention of this on the ADC or the iSync homepage, so perhaps I just need to patient for a while longer :).

Brad BARCLAY

For me it is difficult to put my finger on exactly what has hampered Java's uptake in the general open source community. Java certainly has an open source community (as is evident from Apache projects etc) but it seems almost completely disconnected from the general open source community.

As an Open Source Java developer (<shameless-plug>The jSyncManager</shameless-plug>), I'll tell you what the problem is: it's that end users don't like to run Java applications.

Here is my take on why this is so:

Some of these problems are admittedly problems of perception by the end users, however it still has the same effect -- many users shun Java applications. Not having a JVM standard with Windows is a big issue, but even more important has been a lack of a decent way to install and run Java applications on most platforms.

As a developer who runs several different OS's, I personally love Java. But as an Open Source project administrator, I've had a very hard time drumming up interest and support (and use) from end users outside of the corporate sphere, and the biggest reason for this is because the jSyncManager is written in Java.

(One of these days I'm going to get around to writing platform installers for it that include a JVM if the user doesn't already have one installed, and which can setup desktop icons and such -- but I'm only one man, and I'm still working on adding new features to the jSyncManager APIs, writing JNI bindings for libusb in order to provide Java USB access support on more platforms (another regular irritant for us -- part of the price you have to pay for pushing the boundries I suppose -- is that jUSB and JavaX USB are currently only functional on Linux, forcing users on other platforms to rely either on serial RS-232 connections, or TCP/IP connections), and the usual bug fixes and such -- it really is a fulltime job these

I'd like to rebut the major points of this article:

1. "If you're not willing to help fix it then you shouldn't complain about it": As an Open Source developer myself, I can understand the sentiment, even though I do disagree with the way some people state it.

   Most Open Source projects are the work of only a handful of people at best -- and not all of those people are coders. In my project (the jSyncManager), we have a total of TWO primary coders for the core project. And sometimes a user will suggest a feature or enhancement that, while useful or cool to do, is something we just don't have the time nor developer resources to complete.

   Two recent Requests For Enhancement illustrate this well. The first is a feature that would take a decent amount of work, and for which the end result, while interesting, would be useful to a very small minority of users, making it a very low priority item we may never get around to implementing. The second requires skills the existing developers don't possess (internationalizing into other languages. The code itself is already internationalized, but needs more translations).

   In these cases all I can do is tell the requestors that while I'd like to add the functionality they're requesting, we simply don't have the development capacity to consider them right now. However, if they're willing to offer any help, we'd be happy to accept it.

   The sentiment is analogous -- I just try to phrase it in a much less confrontational manner. Open Source developers don't have unlimited resources to implement everything -- any project of any significant size needs to ultimately rely on volunteers.

2. "Open Source software allows you to get under the hood and fix problems": The article author here is trying to extrapolate their experience as being universal, and I just don't buy it. I've tinkered with a number of Open Source projects. Anyone who has ever ported an Open Source project from one platform to another has had to go under the hood to tinker with it in order to get it to work on a system with a different set of assumptions and/or features.

   And just because you haven't done so yet doesn't mean you never will. Yes, it's sometimes better to get the core developers to implement a fix or change because you don't want to figure out their code (I often dispair the level of code commenting in OSS projects...), or to ensure that the modification becomes part of the default install of the subsystem. But what happens if you need an innocous modification to fit your special needs, and the core developers are unable or unwilling to implement it? Doesn't it make you feel better knowing that you can fix the software to suit your needs if absolutely necessary? Or of being able to hire anyone you choose to fix it for you?

3. "All software should be free": Okay, perhaps not all software should be free. However, the comparisons drawn to art are incorrect. Works of art are usually the efforts of single individuals, where each copy is either unique, or a licensed reprint. Software is different, in that any given project is usually the work of multiple developers anyhow. Van Gogh could afford to take his time painting sunflowers -- the end result would be a unique work that can be apperciated for centuries. Software doesn't have the benifit of taking its time -- the things we develop are the things we need TODAY, so speed is of the essence. You can't afford to take ten years to write and release your software, because by the time you're finished it may no longer be needed (in the case of the jSyncManager, if we were to take ten years to complete our software, we could wind up in the situation where the PalmOS-based hardware we synchronize

I'm prettty excited about the opening of the iSync APIs with Tiger -- I'll now be able to write a plug-in for the jSyncManager to integrate it with iSync.

Brad BARCLAY
Lead Developer & Project Administrator,
The jSyncManager Project.

To replace your HotSync software, take a look at the jSyncManager. It's an Open Source, pure Java, and will run on all your different operating systems. It features an Object-Oriented "jConduit" plug-in system to allow different applications to use it for their synchronization services.

The two downsides currently with running the jSyncManager on the desktop are:

• The jSyncManager relies upon external libraries to communicate with the hardware. For serial docks/cables it requires either the Java Communications API, or the Open Sourced jSerial API. For USB ports it requires jUSB. jUSB is currently only readily available on Linux, with a partial implementation available on Windows. TCP/IP sync support is available on all platforms.
• There aren't a whole lot of jConduit plug-ins available yet. The bundles ones provide generic functionality such as CSV and XML downloading of common PalmOS record types, the ability to upload PRC and PDB databases, the ability to export Zire 71 photos as JPG files, etc. However, if you're a Java-coder and want to write your own jConduit plug-in for your favorite PIM, documentation is available online, and support is readily available through the jSyncManager development community.

Brad BARCLAY
Lead Developer & Project Administrator,
The jSyncManager Project.

uh, getting people to pay for something free?

The jSyncManager core software may be free (as in both beer and speech), but it's really just an enabler technology. Sure it has the necessary protocol stack and such for performing data synchronizations, but the real value is in being able to connect it to your applications, databases, networks, and overall dataflow.

That part isn't free. Current users typically have to develop such plug-in connectors (we call them "jConduits") themselves.

My idea is to sell these integration services. Stand-alone, you can run the jSyncManager, but other than for the backup/restoration of data, and some basic functionality (installing PRC's and PDB's, syncing e-mail with a POP/SMTP server pair, dumping standard application records as text, and downloading photographs) the free part doesn't do a whole lot on its own.

As with many Open Source projects, the idea isn't to make money offf the core software, but off the necessary dupport and servicess required to actually make use of it.

Brad BARCLAY
Lead Developer & Project Amdinistrator,
The jSyncManager Project

It seems to me the real barrier is going to be that this is functionality people expect their *hardware vendor* to provide; so to turn it into a profitable business you need to do OEM licensing instead of GPL and target manufacturers of PalmOS devices.

This is something I've tentatively looked into. It is certainly going to require further investigation.

Currently our primary users are corporate environments that neeed synchronization services and support on non-Windows platforms. PalmSource does a fine job of providing synchronization software for Windows and MacOS, but that's it. If you want to run a large synchronization service from a Linux, Unix, OS/2, or other system, you're SOL.

Corporate users of the jSyncManager are those who need to be able to run it on their platform of choice, and to be able to change that underlying hardware/OS platform without needing to change their synchronization software, or any of the custom connector (jConduit) work they've done. Being pure Java, the jSyncManager is a natural at this -- if your organization is running Linux, FreeBSD, Solaris, OS/2, and Windows, you can run the jSyncManager on al of them, completely unchanged. jConduit plug-in development can be done completely in pure Java, making it easy to do and completely portable.

Bundling with a hardware vendor would be a dream, but I'm not going to hold me breath on that one.

Brad BARCLAY
Lead Developer & Project Administrator,
The jSyncManager Project

You picked a good time to ask -- I just spent the last few hours putting out a new alpha release of the jSyncManager (http://www.jsyncmanager.org) up on our project site at SourceForge (http://sf.jsyncmanager.org).

(The jSyncManager is a pure-Java data synchronization solution for PalmOS based handhelds that is completely platform-neutral, with an open API, easy extensibility, and its own jConduit plug-in architecture).

I started this project back in 1997, writing the jSerial API, and latest the jSyncManager itself. It saw its first release (free, but under a closed-source license) in May 1999. It's gone through several iterations (including an IBM released version called ManplatoSync for Java), finally being released under an Open Source license in September 2002.

I not only work on it daily still, but I'm in the process of setting up a software service/integration/development company around it.

My biggest challenges include trying to involve other developers in the project -- we have a small core, and users do occassionally submit patches, but attracting Open Source developers that actually make any contributions can be a real hassle. If your experience turns out to be like mine, you'll have lots of good intentioned people offer to help out, but will have a very difficult time finding people who will actually do any work, or make contributions without prodding. It can take a while to find developers who are real gems (although when you do, you'll invariably find yourself making some good friends and contacts -- your core developers are your biggest asset).

Some suggestions:

• Don't skimp on documentation. Good user and developer documentation can make or break your project. Complex projects that other developers can't easily get into because of poor API and developer documentation can slow development and developer acceptance of your project. Likewise, poor end-user documentation can likewise stymie uptake.
• Setup a discussion mailing list/online forum and post into it whenever you make an updatee or new release. When starting a new project, users are often leery of empty forums devoid of activity. So be sure when you start your project to generate your own activity until you attract users. Some users base their perceptions of the activity of a project on its public user community, so list/forum traffic is good.
• Release early, release often. Plan your "final" releases, then release various alpha/beta releases whenever you add something new. In this way, your project will be percieved as active by potential users. Daily updates to your CVS repository won't really matter if your last file release was three years ago -- not every user wants to get code from CVS.

As for licensing, I chose to release the API under the LGPL to allow developers to choose their own licensing for any plug-ins they develop that use the API, and the GPL for our applications and the core plug-ins that we've developed. In this way we can ensure that our applications and plug-ins can't be integrated into a closed-source project, and can't be modified and released as closed source by third parties, but they can develop closed-source applications that call our library (although any changes to the library sources must be released as Open Source). So far users appear to be very happy with this arrangement.

Brad BARCLAY
Lead Developer & Projet Administrator,
The jSyncManager Project.

You picked a good time to ask -- I just spent the last few hours putting out a new alpha release of the jSyncManager (http://www.jsyncmanager.org) up on our project site at SourceForge (http://sf.jsyncmanager.org).

(The jSyncManager is a pure-Java data synchronization solution for PalmOS based handhelds that is completely platform-neutral, with an open API, easy extensibility, and its own jConduit plug-in architecture).

I started this project back in 1997, writing the jSerial API, and latest the jSyncManager itself. It saw its first release (free, but under a closed-source license) in May 1999. It's gone through several iterations (including an IBM released version called ManplatoSync for Java), finally being released under an Open Source license in September 2002.

I not only work on it daily still, but I'm in the process of setting up a software service/integration/development company around it.

My biggest challenges include trying to involve other developers in the project -- we have a small core, and users do occassionally submit patches, but attracting Open Source developers that actually make any contributions can be a real hassle. If your experience turns out to be like mine, you'll have lots of good intentioned people offer to help out, but will have a very difficult time finding people who will actually do any work, or make contributions without prodding. It can take a while to find developers who are real gems (although when you do, you'll invariably find yourself making some good friends and contacts -- your core developers are your biggest asset).

Some suggestions:

• Don't skimp on documentation. Good user and developer documentation can make or break your project. Complex projects that other developers can't easily get into because of poor API and developer documentation can slow development and developer acceptance of your project. Likewise, poor end-user documentation can likewise stymie uptake.
• Setup a discussion mailing list/online forum and post into it whenever you make an updatee or new release. When starting a new project, users are often leery of empty forums devoid of activity. So be sure when you start your project to generate your own activity until you attract users. Some users base their perceptions of the activity of a project on its public user community, so list/forum traffic is good.
• Release early, release often. Plan your "final" releases, then release various alpha/beta releases whenever you add something new. In this way, your project will be percieved as active by potential users. Daily updates to your CVS repository won't really matter if your last file release was three years ago -- not every user wants to get code from CVS.

As for licensing, I chose to release the API under the LGPL to allow developers to choose their own licensing for any plug-ins they develop that use the API, and the GPL for our applications and the core plug-ins that we've developed. In this way we can ensure that our applications and plug-ins can't be integrated into a closed-source project, and can't be modified and released as closed source by third parties, but they can develop closed-source applications that call our library (although any changes to the library sources must be released as Open Source). So far users appear to be very happy with this arrangement.

Brad BARCLAY
Lead Developer & Projet Administrator,
The jSyncManager Project.

You picked a good time to ask -- I just spent the last few hours putting out a new alpha release of the jSyncManager (http://www.jsyncmanager.org) up on our project site at SourceForge (http://sf.jsyncmanager.org).

(The jSyncManager is a pure-Java data synchronization solution for PalmOS based handhelds that is completely platform-neutral, with an open API, easy extensibility, and its own jConduit plug-in architecture).

I started this project back in 1997, writing the jSerial API, and latest the jSyncManager itself. It saw its first release (free, but under a closed-source license) in May 1999. It's gone through several iterations (including an IBM released version called ManplatoSync for Java), finally being released under an Open Source license in September 2002.

I not only work on it daily still, but I'm in the process of setting up a software service/integration/development company around it.

My biggest challenges include trying to involve other developers in the project -- we have a small core, and users do occassionally submit patches, but attracting Open Source developers that actually make any contributions can be a real hassle. If your experience turns out to be like mine, you'll have lots of good intentioned people offer to help out, but will have a very difficult time finding people who will actually do any work, or make contributions without prodding. It can take a while to find developers who are real gems (although when you do, you'll invariably find yourself making some good friends and contacts -- your core developers are your biggest asset).

Some suggestions:

• Don't skimp on documentation. Good user and developer documentation can make or break your project. Complex projects that other developers can't easily get into because of poor API and developer documentation can slow development and developer acceptance of your project. Likewise, poor end-user documentation can likewise stymie uptake.
• Setup a discussion mailing list/online forum and post into it whenever you make an updatee or new release. When starting a new project, users are often leery of empty forums devoid of activity. So be sure when you start your project to generate your own activity until you attract users. Some users base their perceptions of the activity of a project on its public user community, so list/forum traffic is good.
• Release early, release often. Plan your "final" releases, then release various alpha/beta releases whenever you add something new. In this way, your project will be percieved as active by potential users. Daily updates to your CVS repository won't really matter if your last file release was three years ago -- not every user wants to get code from CVS.

As for licensing, I chose to release the API under the LGPL to allow developers to choose their own licensing for any plug-ins they develop that use the API, and the GPL for our applications and the core plug-ins that we've developed. In this way we can ensure that our applications and plug-ins can't be integrated into a closed-source project, and can't be modified and released as closed source by third parties, but they can develop closed-source applications that call our library (although any changes to the library sources must be released as Open Source). So far users appear to be very happy with this arrangement.

Brad BARCLAY
Lead Developer & Projet Administrator,
The jSyncManager Project.

My project recently celebrated its first year o being Open Source (http://www.jsyncmanager.org. While I've been working on this project for the last 6 years now, it's only been in the last year that I've had to deal with other people working with my code, and managing their efforts. A few things I've learned along the way which might be helpful:

• The people who work with you on your project are volunteers, so you have to treat them as such. Sometimes they'll have more important things to do than work on your project, which can, at times, make deadlines a difficult thing to enforce. It alos means you have to show appereciation for their efforts -- if they don;t feel they're getting something out of their time, they'll drop whatever they're working on and leave the project.
• Expect at least 75% of the people who offer to help to end up doing absolutely nothing. I've had lots of people with great ideas and apparant energy offer to help with my project. I'll take the time to get them setup with the various permissions and resources, and may then never hear from them again (some of the more polite ones will appologise for not being able to be active in the project). Don't take it personally -- when people aren;t getting paid, sometimes their excitement at joining an interesting project outweights their actual desire to do any work :).
• If someone leaves your project, regardles of wether they contributed anything or not, thank them for taking the time to join in the first place. Even non-contributors have their hearts in the right place.
• Try to build up a solid core of developers, and then delegate. If at all possible, put different people in charge of different areas, giving them as much creative control as possible. Make these people you "leiutenants". This is particularily important for those development areas you either aren;t good at, or simply aren't interested in.

  In my project, my core strengths are with the base synchronization protocol stack and engine -- the really low-level stuff. That's my domain. Some of the things that hold no interest to me include the user interface portions of the project. Thus, I put someone in charge of UI development, giving them full creative control (although I'n known to offer feedback :) ). I found someone who is an expert on UI design, and leave them to their task.

  Build a community, and build bridges to other development communities that may find your project useful in their own projects. You never know where it might take you, or who might discover your project through another project. The jSyncManager (my project), for example, has ties to the jUSB Project, and OpenOffice.org'q Glow Groupware Client. Scratch their backs, and they'll scratch yours (and if your project needs an open, platform-neutral Palm handheld data synchronization facility, let me know :) ).

• Become a shameless promoter of your project. Bring aboard someone who knows a thing or two about marketing. Write up press releases every time you meet a significant milestone, or make a significant release, and send them out into the wild through every channel you know (just don't abuse them -- no spamming via e-mail or newsgroups, as that just pisses people off),
• Write good documentation. Better yet, get a volunteer who can write good documentation :).
• Have fun, and make sure your volunteers are having fun as well. Share the credit and prestige with everyone who makes a contribution, no matter how small or insignificant. Make sure people are doing the types of work they want to do as much as possible.
• Have fun!

I hope this helps!

Yaz.

What about, ...

Hey -- are you the one spying on me from the adjacent building? :).

I lost my job (with a company often associated with the properties "blue" and "big", not necessarily in that order) nearly two years ago, back in January 2002. Since then, I've Open Sourced my PalmOS data synchronization project (v3.0 final is due out in the next two weeks, so go download it!!!), run about 20km per week, and do about 60 push-ups, 80 sit-ups, and 12 chin-ups a day. I completely kicked the caffiene habbit (switched from regular Coca Cola to caffiene free Coca Cola... :) ), and am eating quite a bit better (and a whole lot cheaper!).

The only things in your list I haven't done is any volunteering (unless you consider administrating and leading development on a large Open Source project every day to be volunteer work ;) ), or going to the library (I already have three bookshelves of books here, so I've been re-reading them all).

Oh, and I haven't kicked the beer habit -- having never picked it up in the first place, I haven't really seen the point of starting, just so I can quit.

Yup -- unemployment is the best thing that ever happened to me. More time to work on important projects, read, eat right, and get more excercise. If only I had an un-exhaustible source of money, things would be perfect (or, barring that, a decent job would do...).

Yaz.

Anyway, I think Yaztromo just solved his problem #1 - by getting his question posted on Slashdot, I don't think he'll have any trouble marketing his project now, assuming it's any good.

Just FYI, now that the SourceForge statistics for July 14th (the date this story was posted to /.) are available, I decided to look them up. According to them, our homepage views were a grand total of 83 for the day.

Perhaps the results for the first full day the article was online (July 15th) will be different, but thus far having this question posted to Slashdot hasn't caused the "slashdot effect" to occur to our website at http://www.jsyncmanager.org.

I'm not disappointed by any means -- getting my question posted wasn't intended to be a marketing gimmick in and of itself. Maybe the results for yesterday, the 15th, will be more suprising (one way or another :) ).

Yaz.

He disparages both C++ and Java as open source development languages, and I agree with his comments on those.

I don't -- at least not his comments concerning Java.

At one time (before they were bundled) people had to download a web browser if they wanted to view a website. I don't recall any webmasters who felt that they shouldn't work in HTML because people had to go and download a browser in order to view it.

Every software project has prerequisites. Some projects require external libraries, others require external runtime environments. If you code an Open Source project is Perl, I'm not going to be able to run it on my OS/2 systems without downloading the Perl runtimes, for example. The only way to avoid this is to statically compile everything you need into a native executable which, once again, isn't going to work for people running on a different platform(s) than what you're building for. Now they have to go through the pain of installing (and possibly paying for...) a compiler, and then modifying the code to make it compile on their platform of choice.

If your application does something useful that people can't otherwise do, they'll take the one-time hit and download the Java Runtime (or any other project prerequisite).

I think this is a non-issue. As the administrator of a Java-based Open Source project that targets client-side Java (The jSyncManager Project), I can say that using Java hasn't inhibited the growth of my project significantly, as it provides value that people can't get elsewhere (namely, a single application and plug-in architecture that can run on any Java-enabled system, which allows organizations in heterogeneous environments to run the same application on all their platforms, reducing maintenence costs). As such, people who need this sort of value have no problem taking the one-time hit in installing the proper prerequisites.

Yaz.