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" :)
Related
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
A year ago I was a big fan of .NET. I was developing custom applications on demand and it was not hard to understand how you can live by doing this kind of job - the customer asks you to make a custom application, you arrange the price, do the job and earn money.
Now I hear more and more people talking about open source projects and collective intelligence which seems a great concept to contribute something to the innovation. But of course as a full-time employee it is hard to find time to work for free and I don't understand what are other benefits of contributing to open source projects beside personal satisfaction.
I would be very thankful if you could explain how the contribution to the open source project could be paid off.
Thanks.
There are a few benefits to working on open source projects. I'll be brief here and allow you to work out the detail as you go.
Experience. You'll get to use some stuff you probably won't get to use in your day job.
Fun. It will be a project you've chosen, so you can enjoy it a bit more.
Freedom. There will probably be less rules about what you can use and how funky you can make things (within reason)
You Need It! You'll probably choose a product that you have some need for but you want to contribute to the features.
Just because something is open source, doesn't mean it isn't "commercially viable". For example, you might charge for the service of installing, configuring and guiding a client who uses the application and the fact that the software is open source is a big selling point. You don't make money from license fees, you make money from consultancy.
As far as employability is concern? Street cred.
Peer-interviewers often take (varying degrees of) stock in a fellow programmer's contribution to open source projects, especially if you're at a junior level. It shows self-motivation, proactive-ness, ability to work in distributed teams, proof that you've actually used some sort of version control, etc.
One other reason: Suppose you use version 1.4 of an open source product and want a feature added to it. You add it on your own copy and do not contribute back to the open source version. When version 1.5 is released with a lot of other goodies that you would love to have, you will again need to patch up 1.5 with your required feature. If you had contributed back and it went into the open source version, you will not have this maintenance problem.
For me to work as in open source projects has the following advantages:
Make you learn more
Shows to the world your development skills
Make you a reference in a specific subject or for a group of people
Give a good impression about you that you work with development because you love it. Love enough to spend your free time on a free project
It can become a product in the future or with a "key module" or plugins that a user must pay for it
One more time: make you learn more, specially if you are doing a project without relation with your "daily job"
For personal use, many people want to contribute to the open source because they use so much themselves. And the only way they can use open source is if people contribute to it. Also if people want a feature added, they can help others by giving it away.
For many companies, creating open source software means they can benefit largely from additions made by other people, while still getting the software they need.
Also there is the great amount of personal experience, and a good item on your CV that helps.
However, in the end, most open source projects are run/created by people that do it make the software they work on better, to help others.
Contributing to open source shows that you like software development, not just the salary - that can make you more interesting to a prospective employer.
Here's my reasons:
Why I spend so much time working on an Opensource project
And my views about the differences between paid jobs and working on open source projects might also be interesting here.
You might also ask, what are the benefits of giving or volunteering for a charity?
In terms of getting paid, some companies employ people to work on open source projects, full time. But the vast majority of minor contributions will see no direct monetary payback, apart from knowing that the software has been improved for everyone using it. Of course, things such as reputation can be built, you learn more skills and potential employers can see your work, but these in themselves will not necessary equal a monetary payback.
If you write you own software and open-source is you can still sell it, and sell support services for it (e.g. helplines, support, paper manuals, custom programming) This is a common business model for open source companies.
Help to improve code
You can get all updates to you software. You can find out pitfalls and defects in your code if someone else edited some functionality in your code.
Added functionality
Any one can add functionality to your software. By this you will be aware of what all things you missed in the design and can contribute to your future software development.
You might like to try reading The Cathedral and the Bazaar, by Eric S Raymond (a big open source contributor). It's a very good overview of the history of the open source movement, how it works and where it might be going, written in an informal and approachable style. I'm pretty familiar with the ins and outs of open source (my husband's last two jobs have been in open source based companies) but I still learnt a lot from it.
you will be listed as contributors in the project website (if any) and this is great because you can tell your clients that you are the contributor of that open source product. It would add value to you.
it would be good for your portofolio/resume if you are involved in open source project in the past / present.
for fun. you help eagerly to make a better software for yourself and others. it also fun to see your open source project grows and being used by many companies.
experience that you would have for being work together as team. also you can learn from others how to code.
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 does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
I've got a framework for PHP that I've developed for about 3 weeks total, but it's quite ready to be released ... if I choose to do so. In this economy I cannot just take what I have done and release it for free and feel just (because I need the money it could garner), and yet I am torn by my appreciation for open source projects. I want to eat and I want to share as open source. I'm sure some understand my conundrum right off the bat.
As an example of the pros and cons of my project, here's a very quick comparison against CodeIgniter. My framework is 10x faster at the base speed (blank CI versus the basic demo of mine) and gets upto 20-30x faster elsewhere. Yet, my framework lacks many things that CI has like advanced routing (with regex, or named parameters) and ORM. If I was to compare it to a similar framework in another language, I'd call my work the Sinatra, or Ramaze, of PHP.
I need some extra income. This is a flat-out fact, and yet I don't want it to be a strictly commercial project.
I like open source, and I want to contribute my own work. Yes, I know frameworks for PHP are a dime a dozen, but I think I might have something here. So, I don't want to let my work go entirely.
So I remain torn. Licensing can help, but only when people are honest. I don't believe in putting "DRM" into my software. Yet, I don't have enough features to say, "If you donate/pay you'll get X other features!" and make a benefit to this.
How do I (can I) sell this? How do I promote it and release it as open-source for free uses? How do I license my work adequately for these purposes?
What is your general policy or tips for projects like this? Especially when you want a cut of the profit someone would get using your project commercially. What licenses, restrictions, etc, do you think would work in this model?
I appreciate any answers which might help me to figure out what to do.
Edit:
To clarify on what I'm thinking, let me add this: this is my pet project. It's something that I made because I felt its lack in the market of PHP frameworks, and have been maintaining it for my own works. But, unlike most my work, I would really like to make this public. I want people to see it, try it, use it, and work with it.
However, I've put in enough off-hours time into this for it to be just given away. I appreciate the open source model, but I don't see how I can just donate some 80+ hours of work for free for a speculative increase in my "reputation" within the software world. PHP frameworks are a dime a dozen and I think I've made a good one, but I'm sure there are just as many others who've done the same. Mine may be better, but it's got an equal or greater chance of being average to poor.
I'd love to release my pet project to the world under an open source license. But, I'd rather someone not take my work and make software that nets some $30k in profits, and not give me a small slice of it. I'm not being greedy--I wouldn't care if it were only $100 for a profit that large.
I am simply trying to figure out how, when, or if I even should, monetize the work that I've done for myself.
I feel that if you actually believe you have started something big, release it to the open source world. If it get's adopted and becomes a standard for many, this in itself will open many more profit making opportunities for you as the creator/inventor. The biggest potential for you to make big money (in my opinion) is to be a major player/founder of a big initiative.
To be absolutely frank, you probably have an overinflated idea of how good your framework is and how ready it is to be released (in any form).
Firstly, you said it took you three weeks to develop. Well if you can do it in three weeks, so can a bunch of other people and that's a fact.
Secondly, release of a commercial product would require having a license (count on a lawyer for this one), writing documentation, building a Website to promote the product, having some means of payment, getting a suitable legal structure to sell software, insurances (generally speaking you'd need some sort of professional indemnity--open source is generally provided without indemnity; commercial software is different), bookkeeping, accounting and so on.
Third, it's PHP so source code protection will be an issue. My advice would be to treat this as a social rather than technical problem, meaning if someone is going to steal your software, there's not a whole lot you can do. More to the point, don't hurt (or even inconvenience) your legitimate users for fear of pirates and thieves.
Lastly, one of the advantages of open source is that you can get community effort in development. You lose that as soon as you go commercial. Even if you go dual license, you can't take someone's GPLed (for example) code contribution and release it under a commercial license.
You may need money but selling software is generally a terrible way of doing it. A longer term view would be to have you build a profile and a name for yourself by people adopting your framework and the best way to make that happen is for it to be open source. Linux may be free but I can guarantee you Linus Torvalds earns a healthy income from his efforts.
If the framework is indeed good, and sees a minimum adoption after it is released, you might be able to land some PHP consulting work.
For me the main problem with new software is credibility - it might be the best software yet, but if no one is using it and if reviews are nowhere to be found, I don't want to be a guinea pig. Making money from commercial software can be very hard if you don't find customers early on...
You could try the QT model: Dual-license you framework with a free copyleft license (you'll have to check which one is appropriate) and a paid-for commercial license.
You better choose dual licence.
Its similer to MySQL.
The best way may be to ask for donations. I would definitely donate if I liked your framework.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I was always wondering about this seemingly utopic world of open source.
Assuming the vast majority of users here are professional software engineers which need some sort of income source, I assume most of us hold stable, money-making jobs.
So who are the key players in the open source community? Who are the people which devote their precious time to these projects? What is their benefit? Are the majority just people who see a bug, fix it, submit, and forget about the project? Or are they people constantly involved in the process of building the product?
How do you find yourself contributing to open source projects?
I earn my living doing professional projects that are based on either open source frameworks or commercial products, and quite often a combination of both.
A lot of the commercial products I have used over the years end up being really very expensive in the end. Let's say you buy a Single-Sign-On solution for web apps. By the time you're finished with what you have to do, I and a lot of others have experienced that you end up re-implementing 2/3ds of it, and sometimes there's almost nothing left of the commercial product you thought you were going to use.
So the problem with buying stuff is that it never fits, and quite often the purchase decision is based upon function-matrices that compare features whilst not actually considering the suitability of those features in your own environment.
What I'm trying to get at is that mature organizations understand that there's no such thing as a free lunch, even after you paid for the product license. The fact that you spent $1M for a content management system does not mean you're not going to spend another $2M doing 50% planned and 50% unplanned activities related to that.
So we can, will and do write patches for all OSS projects we're involved with. Sometimes we rework subsystems, and most of the time we submit it back. Sometimes we decide we only want 50% of the framework and we just fork of the rest for ourself. But we still want to stay with the framework for that 50% which we use. Try doing that with a commercial product ;) In general we try to stay on the "developers " mailing list, but we seldom bother to get commit rights for the projects.
My greatest contribution to open source projects has not been by contributing code to them, but by just actually using them.
Philosophically speaking, that is probably just as nearly as important to the health and utility of the project, actual users who submit feedback and leave suggestions and comments in daily conversation or in sites like this.
Are the majority just people who see a bug, fix it, submit, and
forget about the project? Or are they people constantly involved
in the process of building the product?
I definitely fall in the first category (focusing on a long term project is just not my thing) but there are plenty of people that are part of the second one. Without them we wouldn't have much of a viable Free Software ecosystem. A significant portion of these people are paid to write and maintain Open Source software but there are still a lot of hobbyists who do it just for fun. In fact, most people I know who are paid to work on Open Source software would still contribute if they had to do it for free (I certainly would). Contributions would just be less frequent.
How do you find yourself contributing to open source projects?
When I was a student I played with internals of various free/open source softwares (including gdb, OpenSSH, arping, some IRC clients, Snort, various Perl modules, some Debian specific packages things,...) and fixed some bugs as well as implementing a few features while doing so. Nothing big in term of SLOC and some of these contributions were rejected but it was still fun and interesting.
I co-founded a Free Software Users Group which has been running for over 4 years now. At meetings I sometimes give technical presentations about free softwares. We also try to regularly attend external events were LUG/FSUG are invited.
I also often buy T-shirts, sweaters and fluffs from projects I like as a mean to give them some financial contribution.
I am now doing technical support at an Open Source company and as such I report bugs and write fixes routinely. And they actually pay me for that. Why choose between contributing to Open Source and having a real job when you can do both?
It's a lot about pride in something you do. Also gaining the confidence when code you do is accepted by peers.
After that initial phase, is a lot about being able to manage code builds and releases, suggesting new ideas and practicing your skills.
Some people in open source projects do them because they feel the freedom they do not get from work is liberating.
I personally try to contribute as much as i can, from documentation to bug fixes. That isn't to say i do much, but i like it when i can.
I have started my project because at that time I couldn't find any application that was what I had in mind. I have made it open source beacuse Sourceforge had an excellent infrastructure I was not willing to cope personally with.
I barely make enough with Google adsense to pay for the domain name and hosting, apart from that it was a lot of fun over the years. And a refreshing experience being in complete control of what you do, which is certainly not the case in my day job.
I earn all my living doing professional projects based on open source web framework (Aida/Web) which author and active contributor I am. The same goes more and more for others in our community as well. They are earning money and at the same time contributing back to the tool which actually enables them earning that money. The loop is therefore closed, to the benefit of all. I'm quite sure that such a model is the best for the open source and many other open source guys are following it as well.
All my OS projects started as real business needs that needed to be satisfied. Once the job is done, I can release the applet or whatever to the public via Google Code. I haven't had anyone submit a bug report so far, and I doubt I ever will. Most of the things I post are fairly small but, hopefully, useful. Personally I don't beleive people who use OS software submit bug reports at all: they just go and donwnload something that actually works.
I do both.
I am not a "major player", but if I can help a little in improving a project that interest me, I do what I can, from adding a bit to the documentation, pointing out some possible improvements, fixing a bug, providing a patch.
I helped a bit to improve a PHP framework, for example. Sometime I provide or improve French translations.
There is at least a project in which I was (still am, although devoting much less time now) quite involved, Scintilla and SciTE (I am near the top of the chronological list of contributors in the SciTE credits). Of course, my main interest is to have an editor fitting my needs and tastes. That's the spirit of open source, to get contributions of people with a strong interest in the project.
I helped, but in the same time, I learned a lot, so it is a good deal for everybody.
I've been working exclusively on Open Source now for three years, in addition before that I did FOSS as "hobby projects". We're using our own Ra-Ajax to get consultancy gigs. This first of all makes it possible for us to create OSS which is very rewarding and fun! Second of all it create better tools for ourselves in addition to that we since we know the tools in and out often can charge better prices then if we were working with some "random thing" which "someone else made"...
How do you find yourself contributing to open source projects?
I think that, like programming itself, it has a lot to do with your passion and interests. If you are working on a project, or are interested in a topic, and find yourself needing a tool or a module that does X, go search it out. Chances are that there is at least one other person who has released an open source project that does it already. Depending on what you find you can:
Use a product and help the owner make it better via bug reports/fixes and feedback.
Improve on the product and submit your changes back to the owner.
Make your own product and release it as open source for others to do the first two with.
Chances are good that when you are first starting out that you won't become and overnight open source rockstar. Like the internet itself there is so much out there that you probably won't be noticed right away. However, just going through the process will teach you enough to make it worth while.
That is where I am. I have not made a name for myself in the open source community. I have learned the names of a handful of key players through reading blogs and just using the code, but that is really missing the point of open source. I have found some really great tools and have improved my knowledge and coding significantly, which is what is important to me.
In my experience, many people I have talked to see open source in one or more of the following ways:
A hobby for super hackers.
Something that people do for charity.
A source of free code examples.
A human right.
A place to find temporary solutions.
I see it as a great opportunity to learn, add tools to your toolbox, find out more about your industry and others in it and have fun all at the same time.
Well, I've started off an OS project on my blog to address some of the perceived shortcomings/process speedups in the Visual Studio XAML process. It's not 100% open source at the moment because I'm the only active developer on the project, but I have had people contribute source to the project which has been a fantastic incentive for me to continue developing it.
On a slightly different note, I've written applications and articles that have been posted on Code Project, so people are free to download them and use them as they see fit. My theory - if I've put it into the public domain, then it's free for you to use as you see fit; I don't want any money for it - that's not why I wrote the article.
Contributing to open source projects is a great way to hone skills that may not be in your main development set, so this is a really good way to improve your CV.
Reported bugs. Written articles. Answered questions on forums/IRC. Even started up my own OSS Project (Which I've handed over to someone else since)
I would really like to contribute to OS projects, however with three kids and a full-time job I never find myself with enough time to do anything but consume OS. Hopefully that will change sometime soon, but I do believe there are at least more than a handful of developers that are in the same boat with me.
Honest answer: Not much.
I've written a lot on my own, but I don't really consider that contribution. The most I've given to other projects is a few bug reports.
Using it.
Promoting it.
Creating a tiny open source project (Natural CLI).
I pretty much active in an open source project named :
JStock - Free Stock Market Software
I can improve my $ncome (by using JStock to perform investment) and write code at the same time :)
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
We have a series of closed source applications and libraries, for which we think it would make sense opening up the source code.
What has been blocking us, so far, is the effort needed to clean up the code base and documenting the source before opening up.
We want to open up the source only if we have a reasonable chance of the projects being successful -- i.e. having contributors. We are convinced that the code would be interesting to a large base of developers.
Which factors, excluding the "interestingness" and "usefulness" of the project, determine the success of an open source project?
Examples:
Cleanliness of code
Availability of source code comments
Fully or partially documented APIs
Choice of license (GPL vs. LGPL vs. BSD, etc...)
Choice of public repository
Investment in a public website
There are a several things which dominate the successfulness of code. All of these must be achieved for the slightest chance of adoption.
Market - There must be a market for your open source project. If your project is a orange juicer in space, I doubt that you'll be very successful. You must make sure your project gets a large adoption amongst users and developers. It is twice as likely to succeed if you can get other corporations to adopt it as well.
Documentation - As you touched on earlier documentation is key. Amongst this documentation is commented code, architectural decisions, and API notes. Even if your documentation contains bugs, or bugs about your software it is ok. Remember, transparency is key.
Freedom - You must allow your code to be "free" - by this I mean free as in speech, not as in beer. If you have a feeling your market is being a library for other corporations a BSD license is optimal. If your piece of software is going to run on desktops then GPL is your choice.
Transparency - You must write software in a transparent environment. Once you go open source there is no hidden secrets. You must explain everything you do, and what you are doing. This will piss off developers like no other
Developer Community - A strong developer community is required. This must be existing. Only about 5% of users contribute back to the project. If someone notices there haven't been any releases for a year they wont think "Wow, this piece of software is done," they will think "developers must of dumped it." Keep your developers working on it, even if it means they are costing you money.
Communications - You must make sure you community is able to communicate. They must be able to file bugs, discuss workarounds, and publish patches. Without feedback, it is pointless to opensource the project
Availability - Making your code easy to get is necessary, even if it means pissing off lawyers. You have to make sure your project is easy to download, and utilize. You don't want the user to have to jump through 18 nag screens and sign a contract in order to do this. You have to make things simple, and clean
I think that the single most important factor is the number of users that are using your project.
Otherwise its just a really well written, usefull and well documented bunch of stuff that sits on a server not doing very much...
To acquire contributors, you first need users, then you need some incompleteness. You need to trigger the "This is cool, but I really wish it had this or was different in this way." If you are missing an obvious feature, it's extremely likely a user will become a contributor to add it.
The most important thing is that the program be good. If its not good, nobody will use it. You cannot hope that the chicken-and-egg will reverse and that people will take it for granted until it becomes good.
Of course, "good" merely means "better than any other practical option for a significant number of people," it doesn't mean that its strictly the best, only that it has some features that make it, for many people, better than other options. Sometimes the program has no equivalent anywhere else, in which case there's almost no requirement in this regard.
When a program is good, people will use it. Obviously, it has to have a market among users--a good program that does something nobody wants isn't really good no matter how well its designed. One could make a point about marketing, but truly good products, up to a point, have a tendency to market themselves. Its much harder to promote something that isn't good, so clearly one's first priority should be the product itself, not promoting the product.
The real question then is--how do you make it good? And the answer to that is a dedicated, skilled development team. One person can rarely create a good product on their own; even if they're far better than the other developers, multiple perspectives has an incredibly useful effect on the project. This is why having corporate sponsors is so useful--it puts other developers' (from the corporation) minds on the problem to give their own opinion. This is especially useful in the case that developing the program requires significant expertise that isn't commonly available in the community.
Of course, I'm saying this all from experience. I'm one of the main developers on x264 (currently the most active one), one of the most popular video encoders. We have two main developers, various minor developers in the community that contribute patches, and corporate sponsorship from Joost (Gabriel Bouvigne, who maintains ratecontrol algorithms), from Avail Media (who I work for sometimes on contract and who are currently hiring coders on contract to add MBAFF interlacing support), and from a few others that pop up from time to time.
One good developer doesn't make a project--many good developers do. And the end result of this is a program that encodes video faster and at a far better quality than most commercial competitors, hardware or software, even those with utterly enormous development budgets.
In looking at these issues you might be interested in checking out the online version of a course on open source at UC Berkeley, called Open Source Development and Distribution of Digital Information: Technical, Economic, Social, and Legal Perspectives. It’s co-taught by Mitch Kapur (Lotus founder) and Paula Samuelson, a law school professor. I have a long commute and put the audio of the course on my iPod last year – they talk a lot about what works, what doesn’t and why, from a very broad (though obviously academic) perspective.
Books have been written on the subject. In fact, you can find a free book here: producing open source software
Really, I think the answer is 'how you run the project'.
All of your examples matter, yes, but the key things are how the interaction between developers is managed, how patches etc are handled/accepted, who's 'in charge' and how they handle that responsibility, and so on and so forth.
Compare and contrast (the history isn't hard to track down!) the management of the development of Class::DBI and DBIx::Class in Perl.
I was just reading tonight an excellent post on the usability aspect of successful vs unsuccessful open source projects.
Excerpt:
A lot of bandwidth has been wasted arguing over the lack of usability in open-source software/free software (henceforth “OSS”). The debate continues at this moment on blogs, forums, and Slashdot comment threads. Some people say that bad usability is endemic to the entire OSS world, while others say that OSS usability is great but that the real problem is the closed-minded users who expect every program to clone Microsoft. Some people contend that UI problems are temporary growing pains, while others say that the OSS development model systematically produces bad UI. Some people even argue that the GPL indirectly rewards software that’s difficult to use! (For the record, I disagree.)
http://humanized.com/weblog/2007/10/05/make_oss_humane/
Just open-source it. Most probably, nobody will start contributing yet. But at least you can write on the press-releases that your product is GPL or whatever.
The first step is that people start using it...
And maybe then, after users get comfortable, they will start contributing.
Everyone's answers have been good so far, but there's one thing missing and that's good oversight. Nothing kills an open source project faster than not having some sort of project management. Not to tell people what to do so much as to just add some structure and tasking for the developers you are hoping to attract.
Disorganized projects fall apart fast. It's not a bird you just let go and watch it fly away.