Is contributing internal tools to open source worth the effort? [closed]

Question

I know this is a general question, but I'd like to hear other people's opinion about our case:

I work in a small company. Our main development tool is PowerBuilder, which is a very limited IDE with a shrinking community. We've created some tools, which we use internally to solve a certain needs. They have neither been properly designed nor properly tested, and are not in production quality. OTOH, they do save us quite some time, and might help others as well. I'm sure other companies have the same kind of tools, and was wondering how common a practice is it to share them with others. As I see it -

The pros:

• Good karma
• More attention to our website
• Perhaps getting fixes and improvements from others

The cons:

• Without investing more development, the tools might make us look bad
• Publishing of the code requires some effort
• Some of the tools might be too specialized for our needs
• The whole effort might go unnoticed given the shrinking community

Have you or your company ever contributed such tools, or used such tools developed by others? Is it worth the effort?

EDIT:

For those how wondered, the tools I had in mind include -

• A tool that makes using SourceSafe easier, by listing objects that are checked out to the current user or others, backing up checked-out objects, and reconstructing PBGs.
• A tool that recognizes PB controls at runtime, like Spy++ does (requires some infrastructure at the target app).
• PBNI wrapper for SQLite (in-process access, no ODBC).
• An SQL client, text measurement tool etc.

Answer 1

"Open source" originally meant you published a tool, and you made the source available. Because of some projects that expected, and in some cases through licenses demanded that changes to the source code be resubmitted for sharing, "open source" now quite often adds the concept of collaborative development to the mix. I did (or attempt to do) the latter; allow me to share.

There are magnitudes of difference between the effort associated with source available and collaborative development open source.

Leadership: You need to tell people the who, what, where, when, why and how of changes. And very possibly, you'll need to diplomatically poke and prod your volunteers. You may need to define the vision and prioritize goals of the project, and then enforce them when someone tries to take things another way. And, unless you only want people to come across your tool through serendipity, you'll have to advertise, running that very thin line (even thinner on the Internet) between attention-getting and gaudy. If the project is going to implement the concept of meritocracy, as many open source proponents say should happen, then someone will have to judge people's accomplishments and dole out the rights and responsibilities appropriately.

Work flow: I haven't done an exhaustive search by any stretch of the imagination, but I have yet to see a collaborative development platform that did all the things I needed. Part of the point of open source collaborative development is that the quantity involved in code review will cover any potential issues in quality of code submissions; I haven't seen a free tool integrated into a collaborative development platform that helped manage that cleanly yet (e.g. counting code reviews; auto-promoting after x reviews). We had to handle that, hacking manual methods into the existing tools. Probably at some point you'll have to define a version and create a build. Then there's the grunt tasks like documentation. (Ever try to release a new version of something free without release notes? The furor!! grin)

PB-specific issues: PowerBuilder is a commercial tool, and while there are cheap versions available, there are not free versions. The DRM added to PB11 has probably reduced or eliminated piracy that developers were probably doing to take copies of their office PB home, and while PB11 and later have a dual license policy that would allow developers to take home a copy legally (with permission and cooperation of the original license owners to create a second license), I don't see a lot doing it. (No scientific study, that's just what I see.) That cuts down a lot of potential collaboration, even from enthusiasts. Issues of compatibility of code between versions of PowerBuilder, plus the fact that very few people will own every version, will limit again your list of potential contributors.

Don't get me wrong. I'd love to see more collaborative development open source in the PowerBuilder community. I'd love to know how to work out the issues myself, and I have an effort in the works to see if I can make a new model work. (My first effort to follow the popular model failed miserably, IMHO.)

Is there a reason to feel badly about firing a ZIP file up to the web and forgetting it? I don't know. Is there any more pride or embarrassment in a 4 year old ZIP file as opposed to a SourceForge project whose last contribution 3 1/2 years ago was a post "Where the heck is everyone?" There is a reason why Sybase CodeXchange devolved from a collaborative development platform to a source available platform: next to no one was using the collaborative development features. If you source available open source your code, you'll have plenty of company.

BTW, CodeXchange may be an answer to your concern about visibility to the PowerBuilder community, although you'll lose the web site traffic. The PowerBuilder Web Ring is another, significantly less effective, method to help your visibility that keeps traffic on your web site, but it demands a navigation bar on the target page on your site. CodeXchange may also be a way to get over your concerns about code quality and narrowness of purpose of what you have to share. grin

What should you do? Don't underestimate the effort with a collaborative development sharing, but don't let it stop you from a source available sharing.

Good luck,

Terry.

Answer 2

You can probably discount one of your cons: Anyone interested enough in this kind of tool to be evaluating your offering is unlikely to be writing Company X are teh suxors on your feedback form; rather if they find some deficiency in what you have put out there, you are likely to get helpful bug reports or even patches.

Answer 3

If you can get your company to buy off on contributing to the community then I would go for it. it is always worth the effort to give back a little bit and this would definitely be a good way to get some of your tools out to the public and improved upon by the community.

As far as the cons go, I wouldn't worry too much about the criticism, it can only help you guys improve the next product you deliver and people will respect you from learning from your mistakes, nobody is perfect.

Even if your effort goes unnoticed by your shrinking community, future employees and clients will see that you are contributing outside of the company and may help with your reputation with them.

I think the pros far outweigh the cons on this one.