I'm inheriting a project that has, until now, had all its artifacts maintained in CVS and FogBugz. There's a ton of old and new documentation in MS Office format that needs to be reconciled.
I've seen some presentations on IBM Rational DOORS and think it would solve the lack of traceability across all these different documents and systems. My (possibly incorrect) understanding is that I could, for example, highlight a phrase in a Word document and mark that as a requirement, then create bi-directional links between that phrase and other artifacts, such as tasks in a bug-tracking system or entries in the changelog and user guide, to show that the requirement has been satisfied.
Unfortunately, if I want to use DOORS, I would probably have to install and maintain it myself. I found an open-source product for requirements management called rmtoo, but it looks like it would require me to rewrite all the documents document into a bunch of specially-formatted text files--which, for me, defeats the whole purpose. If DOORs is overkill, are there any low-overhead alternatives to DOORS?
DOORS has bidirectional links, but they are only from "DOORS objects" in a "DOORS module" to another "DOORS object" in the same or another "DOORS module".
A DOORS object is a little like a row in a spreadsheet file, and a DOORS module is a little like a spreadsheet file.
You have to import all of your material into DOORS to work with it -- DOORS can't work with documents or generally communicate with the outside world very well. Importing and exporting Word documents into DOORS is incredibly breaky.
DOORS is really dated and limited.
Update 2022: As a commenter rightly pointed out, the answer is dated due to changes in the tool ecosystem.
One of my frustrations is that there are many expensive tools (the main players are DOORS Next, Jama Connect, Codebeamer and Polarion).
For developers with a low budget, I often recommend R4J, which is a Jira Plugin. I find the installation and configuration process a little cumbersome, but other than that, it provides basic functions, especially traceability. As of this writing, it was $100/year for up to 10 people.
Original Answer
Do I understand correctly that you're trying to trace elements in DOORS, Word, Tracker-entry, etc.? I don't think what you saw is possible with DOORS out of the box. I think you need a tool like agosense for that, and tons of customization for adapters to the tools you need. If you really want to know, I'd talk to an IBM Sales Rep. But a DOORS-based solution will be really expensive.
It's unclear from your description how much control you have over the tool chain. If you have full control and are looking for a cheap solution, you may want to check out something like Trac. It's free and integrates bug tracking and Wiki (so essentially, for this to work you'd have to migrate your documentation from Office to the Wiki, and bugs from FogBugz to Trac - not sure whether your users will accept this, and it creates the same problem that rmtoo does).
Last, you could look into Requisite Pro, an IBM product that is cheaper than DOORS. It has the advantage that your requirements are managed directly in Word.
Hope this helps!
If DOORs is overkill, are there any low-overhead alternatives to
DOORS?
From experience, there are easily over 20 software tools (often ALM) that support the means of 'Requirements Engineering'.
Here is a short list:
Siemens Polarion
Cradle by 3SL
Perforce ALM
Jama
Intland
...and further IBM DOORS NG "Next Gen", SAP, MKS/PTC Integrity with RE Addon, etc.
As for architecture, I'd recommend EA, Rhapsody, NoMagic, Visual Paradigm.
We have also projects that manage requirements with Confluence. Apparently Gitlab is planning a RE feature.
DOORS is still in actively in use depending on your industry. And there is good reason why.
Related
I recently contributed some code to an open source library/tool just before I realized that I'd like to re-write this project myself (different programming language and design choices). However, some aspects of the project are just like I would have done them myself or are simply worth "copying". Even if I tried really hard to forget about the original code -- most class names, constants and other stuff just are naturally named the same. The original project's license is AGPL.
Can I use a different license (e.g. MIT)? Which ones?
Will I have to mention the original project somewhere?
If so, where? And will I ever be allowed to remove the notice (maybe after the two projects have truly diverged after a few years of development)?
I am not a lawyer and this is probably not the correct venue for soliciting legal advice.
However, this is my take, as one FOSS contributor to another.
Generally speaking when you contribute to open source projects, you retain the copyright over the code that you wrote, and you release it under a license that permits everyone to use modify and distribute it.
Thus, you retain the right to relicense code that you so contributed under MIT or another license. That doesn't count as "stealing" the code and erasing the GPL license -- you were the original source and you retain the right to release what was originally yours again under a different license.
In some projects, the leaders may request that people DO transfer copyright, although its pretty rare I think. You should check the licensing statement to be sure. Unless there is something in writing somewhere saying that you explicitly agree to transfer copyright to them, then most likely you retained it.
You do not have the right to relicense other peoples work though. In cases where you modified someone elses code, contributing some changes to their class or something, you probably become joint owners, and at least I would not feel comfortable copying the part that they made and relicensing it without permission.
That's just the text of the code though. If you want to rewrite another program from scratch, using a similar high level plan but different execution, I don't think copyright will encumber you. Intellectual property law can still encumber you if some technique or method in the code is covered by a software patent. But it doesn't sound like that's the case here.
To avoid legal issues, sometimes companies / groups of people will use "clean room design" (https://en.wikipedia.org/wiki/Clean_room_design). But iiuc this is just done as a precaution to unambiguously head off any possible lawsuit -- the law does not require that you use such techniques just because you once looked at GPL code, iiuc.
For an example of this playing out, you can look at the history of the MinGW cross compiler project, and the mingw-w64 spin-off of it, which originally began because a private company wanted a version of mingw which supported 64-bit processors and other things, and so used clean room design to reverse engineer the project. The result of this was eventually made fully open source, but was not accepted back into the original mingw project and so there are now two projects. (Hope that this is a fair and impartial summary of the history.)
https://en.wikipedia.org/wiki/MinGW#History
UML Round-Trip Engineering tools with seamless synchronization?
The Rational suite purports to do it. But it's so pricey and clunky at drawing (worse than the Rose days) that it's not in the reach of most departments.
What’s amazing is that the free Bouml seems to do a fantastic job. It’s just feels too clunky to use. It has a great deal of functionality, is free (!), very fast, and reverse-engineers complex C++ very well. It also has some nice diagram support, including a very nice sequence diagram. Although the interface is unpolished (and constantly opens dialogs on the rightmost monitor), it does have the beginnings of a very capable product. It's a shame that the interface is so bare-bones and requires the expenditure of a lot of effort. Maybe it's because the author puts most of his time into the actual functionality. Does anyone have experience using Bouml throughout the product lifecycle?
That leaves the pricey MagicDraw, the very-capable yet reasonably-priced Enterprise Architect, and the slick-looking Visual Paradigm. Of these, only Visual Paradigm had an issue reverse-engineering my project's C++ headers.
MagicDraw has a strange, old feel. It does a good job at reverse-engineering on its own, although it remains to be seen whether round-trip engineering of complex C++ projects is seamless. They want over $1800 for the multi-language version, so it's priced similarly to Rational tools.
Enterprise Architect, although far less expensive than most, seems like it may be the most feature complete. It parses and generates C++ flawlessly. Even the comments and formatting are left intact. There are great training materials. But it doesn't handle Objective-C, so less useful for iOS and Mac OS X mixed code projects. The automatic Sequence Diagram generation sounds awesome, but sounds like it only works on Windows .NET projects.
Visual Architect (>$800 for multi-language 2-way) is bar far the best-looking software modeling tool I've come across. Although it may have some round-trip issues remaining, it is a pleasure to use for building the models by hand. It's even nicer than Rose was in some ways. It has an intuitive way of bringing up the tools you need right at the cursor. Yet as I mentioned, it currently falls short of the goal to keep the model in sync with the source. And it often doesn't even give notification that the import didn't fully work, or that duplicate classes have been created (with the same names). It also makes entry of message parameters difficult, using dialogs, whereas others allow the parameters to be changed right on the diagram. (The free Bouml excels at this, as does MagicDraw and others.)
Has anyone found a multi-language (Java, C++, C#, ObjC++, Python, Ruby, SQL) round-trip engineering tool that will hold up to real world projects, where customizations are handled (like custom parameters on messages), yet are not wiped out by the next source code import?
And where all the formatting and comments are completely preserved on generation. Close is not really good enough. If the tools mess up the source code formatting, no developer is going to want the tool run on his source.
Peter Coad's Together-J used to have diagrams and an editor together in one IDE (hence the name). Change a diagram and the code changes; same for the other way as well.
The UML tool and editor were both a bit slow. I think machines of the day were underpowered and didn't show it off to best advantage.
I believe Peter Coad sold it to Borland. Looks like Borland is out of the IDE business. You can still get it here.
I think IntelliJ is the best Java IDE there is. You can generate some nice UML diagrams using it.
The real question is: Why is UML so important? I'd rather have code. I usually do enough UML to get the idea across, write the code with unit tests, and then reverse engineer it for documentation. You can't debug or unit test UML diagrams. Better to have working code.
Bouml ... constantly opens dialogs on the rightmost monitor
in a multiple monitor configuration the best is to indicate to Bouml which monitor must be used by default, else for Bouml you have just a very large monitor including all your monitors. Of course to indicate a default monitor doesn't means you can't use the other one(s), and it is possible to move the dialogs/main window where you want. The definition of the default monitor to use is done through the environment dialog.
Enterprise Architect seems to do a good job at this. As you point out, it's reasonably-priced. And it will also generate diagrams and documentation, as well as import/export source code.
Later this year I want to release a PHP framework that I've been working on as open source. I do use source control (SVN), but it's on an extremely limited basis. I'm self-taught, I develop by myself and don't have the experience of working with large teams. I have some ideas about what can help make a project successful, but I'm fuzzy on some of the details. Since it's not yet released, I want to do everything I can to set up the right infrastructure from the beginning. What do I need to know in order to setup and manage a successful project?
Some ideas that I have to make it successful (beyond marketing it):
Good documentation and tutorials
Automated unit tests and builds to
push update to the website
A clear roadmap
Bug Tracking integrated with the
source control
A style guide to keep the code
consistent
A forum for the community to get
support, share ideas, etc.
A good example application built with
the framework
A blog to keep the community informed
Maintaining backwards compatibility
wherever possible
Some of my questions:
How do I setup and automate a one
step submit-test-commit-generate API
docs-push update to website process? Edit: Would Ant or Maven be good candidates for this? If so, do you know of any resources for setting up a PHP project using them?
How do I handle (technically)
submissions from other users? How can
I ensure that those submissions must
be approved before being integrated?
What are some of the pitfalls that
can be avoided in terms of the
project community? I'd prefer to have
it be as friendly and helpful as
possible without a lot of drama.
I'd love to learn from your experience on any of these points. If you think I'm missing anything big, please share that as well. Any resources (preferably geared toward a beginner) that you could point me towards would also be greatly appreciated.
I'm just getting started in community projects, but I'll give you some advice on what I know.
How do I setup and automate a one step submit-test-commit-generate API docs-push update to website process?
I've never implemented it as one process. You could just have a checklist, and possibly even create some scripts to do certain tasks. I've never worked with any source control that automates the uploading and such to be done by a script. Most of the time, there is some web interaction to be involved.
You don't want to push API changes until it's an official release.
EDIT: Working Environment
For PHP, most of the time, I either edit directly on the server and test it there, using a beta.example.com, or similar, before pushing to example.com. You could also set up an web environment on your home PC (using XAMPP for Windows, or the standard LAMP installation on Linux). You would probably just use a mirror of your repository here, so you'd do svn commit, or whichever is appropriate for the VCS or DVCS you choose.
The fun part is testing this with different PHP versions. I've not done this myself, but you could probably use a .htaccess file to run a different PHP binary in order to test it out. I'm not really sure what the best option is for this is.
I've not done much with API, as I've never created a library, but just doing a quick search I found http://www.phpdoc.org/. It looks like a mature project, so that might be a starting point.
As far as creating releases go, I generally create a script that only includes the files that are part of the distribution (it will filter out any VCS files, and anything that you don't want in the distributed file). You could write a script around find on linux (which is what I do most of the time), or there may be other better options.
How do I handle (technically) submissions from other users? How can I ensure that those submissions must be approved before being integrated?
This is mostly handled by the bug tracker, and limited access in the Version Control System. Usually, you, and the people you allow, can commit to the VCS. Other users can submit patches, but then you might have someone review the patch, test the patch, and commit. You could split these tasks up as a team, or assign a patch to one person and have them do it all.
What are some of the pitfalls that can be avoided in terms of the project community? I'd prefer to have it be as friendly and helpful as possible without a lot of drama.
I would just make sure to keep it as positive as possible with the project members and community. There's going to be some disagreements, and it will drive a few people away, but as long as you have a stable product that meets the needs of most people, I think that's all that anyone can expect.
One minor suggestion that's worked well for me: start using first-person plural pronouns, rather than singular ones. That is, talk about "we" and "us" rather than "I" and "me." It encourages other people to participate when they feel like part of team, rather than when they feel like they're contributing your own self-aggrandizement.
The most important thing you have to do is to attract users. Without users, you won't get any contributions and developers helping you out. Because developers are users first, and then they decide to extend/fix something they use and might become contributors.
So to get users, you should consider
describe what your framework does in one or two sentences at the top of your project page
mention how your framework can be used and for what, what situations it is most useful for
add a lot of examples on how to use it
mention whether your framework is stable, beta or alpha. That's important because user need to know that before they start using it
also mention whether you want to keep improving it and keep working on it - most users don't want to use a framework that's abandoned (also keep in mind that a lot of users check your commits to see whether you really are working on it - if your last commit to the repository was months ago then you're not really working on it, so cheating isn't possible)
If you got all this, and people start submitting patches, you can use a patch tool to apply those to your source. Depending on your version control system, you can either use the GNU patch, a diff/patch tool that comes with your version control or maybe even a GUI tool that helps you with this. SVN doesn't have a patch tool (yet), but 'svn diff' will create a patchfile which you can then apply with the GNU patch tool, or in case you're using TortoiseSVN, right-drag the patchfile to your working copy and have TortoiseMerge apply it for you.
And on how to best deal with the community:
answer questions in time, don't wait more than two or three days to answer questions
try to be nice, even with upset and angry people. Only if they keep bothering tell them to (still in a nice way if possible) go elsewhere
always keep discussions about the project on a mailing list. You don't want to repeat the same discussions over and over again - if you have a mailing list, just point users to the archives before the discussion starts all over again
And you should watch the talk "How Open Source Projects Survive Poisonous People (And You Can Too)" - it's really good and tells you a lot on how to deal not just with 'poisonous people' but also how to deal with all people involved in your project.
I'd like to add that you should make it as easy as possible for your users to get the whole thing running and modify the code - these 'power users' can be 'converted' into developers or at least people who send smaller patches.
Don't try to do it all yourself - for open source projects there are several hosting providers that solve most of the problems. I recommend codeplex or google code.
Setting up build scripts will depend a certain amount on what platform you set up, but in general it's easy to add any tool you want into the script once you start using any sort of build script.
If you really need the one step process you describe, you need a build server. I use TeamCity, which I have set up to watch for any changes in svn and trigger build/test whenever something is checked in. The build server will generally be able to perform any steps that you put into the build script.
Read up on Git as an alternative to SVN
free public repository/bug tracker/wiki/fork-enabled community in Github (which hosts symfony and PHPUnit amongst others)
"How do I handle (technically) submissions from other users? How can I ensure that those submissions must be approved before being integrated?" - with Git, pull what you/your closest team finds most interesting to the master branch
Consistent API
be inspired of other public API:s
only change in major versions
guessable
Interesting for both users & developers
clear goal (your roadmap - excellent)
useful, contra everything else available
easy to use, but still not easy-enough-to-write/maintain-yourself
You could check out either Ant or Phing to build your project. Include CodeSniffer in the build and you'll save time checking for basic formatting errors/differences.
These are all technical tips, about the soft part... treat humans with respect, a lot of interest and be overly excited about their contributions and make them feel that they're not wasting their time. That would appeal to me.
Take a look at Karl Fogel's book on Producing Open Source Software. It probably has everything that you asked.
You should also plan for engaging the community. I'd recommend reading Jono Bacon's The Art of Community [http://www.artofcommunityonline.org/].
You have a great set of ideas to start. You might have to start by trimming them down! Ask yourself what's necessary for a first release.
For automating the builds and tests, the scripting can be done with ant, maven or phing for PHP projects.
You'll probably need a host so you can demo the product. For PHP that is pretty easy to find.
You need an open source hosting provider-- especially github (but also google code, source forge, etc). Github provides bug tracking, default licenses, blog and great mechanisms for accepting changes from the community. Built on git, it facilitates distributed projects quite well.
Although it's good to have a one-step build and install in place, automating integration of others changes probably isn't important (or desirable) off the bat.
Good luck!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this 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.
"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.
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.
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.
In short: go for it. I doubt there's little to lose, but much to gain.
The pros:
**Good karma*
never a bad thing to have.
**More attention to our website*
possibly a con if your code is really bad :)
**Perhaps getting fixes and improvements from others*
this is possibly the best thing you get from open-sourcing your code. Its all about sharing and helping each other, you get to use other's code, they get to use yours and everyone's gained from the trade.
The cons:
**Without investing more development, the tools might make us look bad*
I'd search through to remove dodgy/rude/stupid comments, tidy up the formatting etc.
**Publishing of the code requires some effort*
requires barely any effort - set up an account in Sourceforge, create a SVN repo there and import your code. Then create a binary package (a zip file will do) and release it using the website. Might take you an hour, if you stop to read all the documentation.
**Some of the tools might be too specialized for our needs*
You could set the whole lot up as a group - eg PowerBuilder Tools, then people who see the really specialised tools won't have wasted their time getting them, they'll still have the 'more readily useful' tools.
**The whole effort might go unnoticed given the shrinking community*
Possibly, but then there's really no reason not to release the code. If you don't it may get completely lost to everyone when/if you change development tools.
Publishing your source is a great way to get feedback. If you look bad because of it, that's ok. Just be willing to fix the problem. If you want help with your improvements I can't think of a better way than asking for help.
By the way, plenty of open source projects can be credited with the growth of communities that were previously shrinking.
I think you've done a good job of identifying the pros and cons. And it's probably true that the pros will outweigh the cons. If no one likes the utilities and does nothing to or with them, then you've lost nothing really; bad code shouldn't scare experienced developers (most experienced developers, especially PB ones, have seen their share of legacy code). If even one person benefits, then you get the karma, eh?
If you proceed to submit your tools to the open source community, do as you have here, and admit up front that the tools are not polished. This may deter some from even looking at them, however, if they are at least functional and can be easily modified, then they still represent a head-start for any prospective beneficiaries. As a PB user myself, I would be curious to know more about free tools that can give us an edge in productivity.
Have you looked into Sybase CodeExchange? They have some open-source PB things there, including the PowerBuilder Foundation Class framework.
I just saw your response to my question - amazing that you have developed something similiar already. :-)
Regarding your question: the company I work for has a specific section on the web site where tools which we used internally and/or simple solutions (or code snippets) which customers frequently ask for are published. The license of these offerings is very liberal as well, I think it qualifies as open source.
In your particular case, I'm fairly interested in the Spy++-like application you talked about since I was looking for (and/or trying to develop) something like that myself.
I'm aiming for something which doesn't require any infrastructure in the target application, but so far I'd be happy to play with anything which works, even if it requires modifications to the applications. I'm just not familiar enough with the PowerBuilder API yet to make a judgement on whether this is possible without modifiying the target application.
As I mentioned, I already developed similiar Spy-like applications for ordinary Windows applications as well as managed code applications (which require interaction with the VM to query the state of the object tree), so my hope is that I'll be able to find a solution which does not require any target infrastructure.
Do you have the source code up somewhere already? It doesn't need to be compileable, I'd just be happy to look how you did it in principle so that I can (hopefully) derive something from it which solves my particular problem. In case you didn't upload the source code yet, maybe you can provide some email address which I can use to contact you privately? I tried looking for something on your profile, but so far - no luck. :-)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Contributing to open source can have many forms: working with issue trackers, patches, further development, documenting, funding, etc. Assuming your company uses open source projects, what is the single most important reason why you're not contributing back to the community?
Developers cost us money. Open source does not cost us money. Hence, if we start giving developers time to work on open source software then open source loses its competitive advantage and we may as well give MS a call since at least we can define how much money they cost us upfront.
We do, we're founded on Open Source - but I guess we're special ;)
Anyway, this is not like a true answer to your question, but rather an answer to the "questions" in the other answers I guess. There are many ways to contribute to Open Source. Sure you can contribute code, but the other thing you can contribute is money by donating. Jeff Atwood (one of the founders of SO) did this a couple of months ago to a wiki system system I know.
When I worked for my previous startup we gave WatiN $300. This is a contribution, and probably a both a better (and at least cheaper) contribution then having one of our coders trying to figure out the code model and coding standard etc behind WatiN and then fix some bug and supply a patch.
But the THIRD way to "contribute" to your favorite Open Source project is more subtle, but often the definitive best way you can contribute which is by giving it attention like I just did with WatiN through that link.
I am willing to be $100 on that someone reading this answer will check out the link to WatiN, read about the project and download it and start using it in their own test suites. And they should since WatiN is a great Open Source project and Jeroen the guy behind it is truly helpful!
That is also contributing. Helping your favorite Open Source project get some attention by telling others how great it is!
We do contribute back to open source in the one situation where it would be pure insanity not to. When we fix bugs, we always ensure that they are pushed upstream.
As I say, it would be really insane to not do that, and have the alternative of maintaining a fork.
Our management doesn't understand open source. I'm not sure that our boss understands that we are using OSS for development.
In the last time, our boss wanted to release some stuff as open source, but the package should be bundled with a support-contract, so I don't believe he really knows what Open-Source means.
So in one sentence: we don't give back to open source because our management doesn't understand the concept behind open source.
Update: Now we have an OS-product, but our management do not understand it until today. Actually we did it, because some of our customers talked about open-source (and really meant for free).
We contribute back patches and bugfixes.
We don't generally start new projects, though. We don't really have the overhead to support such a project. Unfortunately, you can't just post a tarball on a website and expect strangers to add features to your code. It takes work to build a community.
Developer time/team resources, and the "appropriateness" of contributing code back.
Meaning that, if we make modifications to an OSS project, sometimes the changes aren't necessarily appropriate to contribute back to the project. This may be because of IP rights, but actually, the most common reason is that we simply don't anticipate that other people would require such specific modifications to the software in the way that we've made it. So generally speaking, such patches don't make sense to send back to the team developing the OSS project.
In other cases, these changes could be sent as a patch to the OSS project developers, but this would require cleaning up/reformatting the code, separating out private company data from the patch, etc. Usually, if we're using OSS software in the beginning, we don't care about such things, because most OSS software is somewhat dirty in terms of code quality anyways (ie, no test cases, coding standards, documentation, etc.). Therefore, the time required to clean up our dirty fixes to already dirty code is usually more time than we want to spend for the altruism factor here.
That said, I have worked at companies that did contribute back to OSS projects when necessary, and those that did not made monetary contributions to some OSS projects or distributions.
In my opinion the biggest problem is that most companies are doing development for projects. If a project develops something that is worthwhile to be published as open source the commitment for maintenance can only be given till the project is finished. After that no more resources are available for further developments, support of the community, bug fixes etc. This usually means a slow death for the open source "product".
Also, some companies are very eager to look at the PR for things they publish, and this usually means to go through all the processes for publications. This is something which in general overwhelms engineers and programmers.
Getting it through legal. Seriously, even as a huge contributer to open source software, as a large company the bureaucracy is a killer. (Hope Legal don't read this:)
The company I work for produces software that is proprietary and our software is highly specialized and is our major competitive advantage over all the other companies in our industry. Can't imagine why Open Source isn't something we encourage.
What about a company that doesn't have developers? Maybe they're not a software group, and are using OSS to save money, a la a web-based group that uses LAMP, but never modifies any of the components?
In our case, we produce extremely customized software for the specific circumstances of a state office. Because of that, our software has no utility for anyone else. Being a state office, we aren't at liberty to "donate" time or money, either.
In theory, we could open-source some of our documentation, but again a lack of demand would make it nothing more than an empty gesture.
Business logic.
If I start building a project where I use the source code for a FLOSS project rather than just a library then I need to develop with an awareness of two factors: the changes to the code to make it do what I want and those aspects that I would be allowed to release to the world.
Generally it's not that difficult to do this, but if deadlines are tight then I'm not going to 'waste' time stripping out our proprietary extensions.
Programmers cost us money, but contributing to open source doesn't generate a cent of revenue.
We do contribute and are very proud of it !
http://hg.nuxeo.org/opensocial is all about our contribution to Nuxeo from Leroy Merlin.
Ok, i doesn't generate a cent of revenue, but it doesn't really costs more. And when people will contribute to our code (patches, bug fixes, extension), this will be code that will cost us nothing.
Moreover, our contribution is now included in the core feature of Nuxeo, so now we will benefit of a vendor certified integration of our code.
I am not sure contributing with money is the best way to help OpenSource software. When Jeff Atwood gave some $5000 to an OpenSource project the lead of the project was grateful... but if I recall correctly he was not too sure about what to do with it.
Developers who contribute to OpenSource projects are not paid to do so. They do it because they like it, want to prove something to themselves, etc... but money is never the cause since they know that they won't probably earn a dime. At best, they might attract attention which may then generate revenues (think new employer, more traffic to their blog, etc...)
Now, I don't say that one should not contribute, but I think that monetary contributions are not as efficient as one might think, companies have a tendency to think that their model (capitalist) naturally extend to everything around them :/
In my opinion, an OpenSource project benefit more from patches/bug reports than from direct monetary contribution, exceptions being hosting the website / repository of the project or financing meetings for the top contributors so that they can discuss face to face when the need arise, but though this cost money, this is not directly giving money.
Even though we do give back to open source as code patches, and releasing open source software I can understand why other companies don't. Because "it doesn't make any profit" :)