Who pays developers of open-source software? [closed] - open-source

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 7 years ago.
Improve this question
We are facing a lot of open source software.
But someone needs to write that software. How are they payed?
Do you know a good article about the open source politics and economy?
Sometimes the big companies themselves release open source because they have some benefits.
Then they sell support, advices ...
My question is what is the real economy about open software?
No professional will work for nothing. This software are couple of classes but thousand or may be millions of classes. If you are really a pro you will write software for money, because you have life, wife, kids, taxes, you must earn.
Please do not tell me that they are doing this for pleasure or hobby!

On Stack Overflow, we get a lot of good quality answers (and questions).
But somebody needs to write the answers. How are they paid? Surely no professional would spend time hanging out here and answering questions for nothing.
...
This, of course, is not how it works: people get pleasure from contributing to something, from testing and extending their knowledge, from being part of a community. Thus they write for SO in their spare time, and enjoy doing so.
Free software is no different.

Eric S. Raymond wrote The Cathedral and the Bazaar and other essays about this, and these are probably the best place to start. There's also a Joel on Software essay somewhere with some good points.
Some people write free/open source software because it's something they personally want. Some do it as part of a reputation game, similar to academia. Some people get paid for it.
Companies pay for it because they make money off it somehow. O'Reilly Books makes money by selling books on using free software. Red Hat makes money by providing enterprise-quality support. Apple makes money by adapting it to their needs and selling computers using it. I think IBM is working on Linux so they can slowly move away from AIX. Some companies find it more economical to develop free software in conjunction with other companies, so everybody can use it and nobody has to pay too much.
Companies that make their money selling software, like Microsoft, will generally avoid free software. Companies that make their money on something related to software will want the software as cheap as possible, preferably free. In some cases, this means software the customers use, and in some cases this means software for internal use.

Most of what I've done on FOSS projects has been unpaid, either building a tool or some functionality that I need at the time - "scratching my own itch", as ESR puts it. This doesn't mean that it doesn't make me money. As a freelancer, the tool I build/improve today could help me land a project tomorrow or help me get an existing project done more quickly, either of which is good for my bank account.
Back when I was working as someone else's employee, there were also times when I developed code on the clock that would help with my job, or other employees' jobs, but my employer wasn't in the business of selling software anyhow, so they were willing to let me release it under a FOSS license.
Today, I offer clients a discount on work done for them which will be released under a FOSS license, in which case I would be getting paid directly for work on FOSS code. Nobody's actually taken me up on it yet, but a current client has asked whether certain parts of their project would be suitable for open sourcing, so they're clearly open to such arrangements and looking for an opportunity to get that discount.
Edited to add: Freelancing has not been kind to me in the six months since I originally posted this answer (too hard to find paying clients for my language of choice), so I have accepted a full-time job with the local university's library, where I will be helping to clean up their in-house collection management application so that it can be released under a FOSS license sometime next year.
So, yes, there are jobs out there where writing FOSS is the primary job responsibility. I suspect that they're mostly in the public sector or at educational institutions, but there are also some private corporations (like, say, Red Hat) where such jobs can be found.

When you say "professional", by definition you are establishing the value and compensation context of your question/statement. But software is not just created as an outcome of the fruits of a profession. Software is art. Some writers have to write, some painters have to paint. Coders need to code. We all acknowledge that it would be nice to be paid for doing what we are. Some are better at it than others is all.

Look at Linux, MySql and many others. There are huge corporations behind the most successful projects, so people will work there as they'd do for any other employer.
A detailed discussion here: http://news.slashdot.org/story/10/04/27/0048250/Why-Making-Money-From-Free-Software-Matters

Most open source software work is done completely unpaid.
Some open source software is useful enough that a company that would benefit from the software being better will "donate" developers to work on it. For example, RedHat - who markets a paid version of linux - may pay for developers to improve certain parts of GNU Linux.
Some open source software has paid support, or paid consultants. So, MySQL was free, but also offered professional consulting based around the software they were already experts on.
But most open source work? Unpaid. Normally, it's a great thing to put on a resume to get you a paying gig.

I am currently working on several open source (GPL) projects. Pay comes from various government grants via the local university.

I found a good article: The simple econimics of open source by Josh Lerner:

My guess:
60% of open source development is
done by developers payed by
corporations
20% is done by developers which like to learn and improve (also having in mind their day jobs)
10% is done by students to learn, or as assigned works for university projects
5% is done for a better world (open source corporations like Firefox)
5% is done for games and fun

Usually nobody unless you work for Mozilla, Google, Yahoo, etc.

Related

How to retain the rights to sell an open-source project at a later date? [closed]

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 7 years ago.
Improve this question
I'm in the process of starting an open-source project aimed at digitising a whole bunch of forms provided by a government department. Basically at the moment if people need to fill out the forms they need to do so on paper, and I'd like to change that so that it can be done on the computer.
At present, the project has no official affiliation with the government and I'd like to set it up in such a way that the public can help contribute to digitising the forms as there are a large number of forms. At some point in the future, the forms may come to be of a standard where it would be feasible that they could be used officially by the government. If this were to be the case, it would be ideal if there was some kind of remuneration, rather than the forms being handed over to the government free of charge.
In such a case, how do you retain authority over where the money goes, given that the project could potentially have had many contributors? Obviously I would like to pass on remuneration to contributors that is based on how much they have each contributed, but is there any legal provisions or statements I would need to have in place to retain the authority to be the person that makes the decisions about who gets what? Is it a simple case of "person that starts the project gets to decide", or would this be in breach of any laws surrounding intellectual property or copyright, given that part of what is sold would be other peoples contributions?
A case (on a much larger scale) similar to mine that I can think of is with Sun buying MySQL - who got to decide where the money from the sale went to, and what did they have to do to retain the authority to make such a decision? As an asides, what did Sun actually get out of purchasing MySQL that they could not have had by simply downloading it, given that it was open source?
Sun, I'm sure, had lawyers. I really suggest you talk to one. They would be able to sort out how to retain some kind of rights over the money so that you (and your contributors) could get remuneration later.
Even open source projects have the concept of copyright.
The code of the project may be open-source but the copyright belongs to someone.
For example most GNU programs belong to the FSF. If you make non-trivial contributions (more than simple patches) they will ask you to give them the copyright of the code.
I suspect this also happens with other big open-source applications (e.g. Mozilla, Eclipse e.t.c).
The controller of the code (and where the money goes to) is the owner of the copyright.
To solve your problem you just ask all contributors to sign papers that assign the copyright of the code to you.
If you later decide to do something else with result you are free to do as you wish since you will be the soler owner of everything.
InterBase is a database system that was branched to an open-source version. Today, it's closed-source again but other developers are continuing to develop the open-source version. The two products are becoming very different nowadays but they have been very similar in the past.
The problem is that the open-source license will stay with that specific source version forever and ever. You can continue to develop your product, adding new features and changing it back to a commercial product again but you would be competing with other developers who might continue to develop on your open-source version. And they hold the copyrights of the modifications they're adding to your project.
Your main problem with turning back your open-source project to a commercial version again are the contributions from other open-source developers. If they gave you feedback and added code to fix certain issues then those changes are copyrighted by them and you can't add them to your commercial version, unless your commercial version continues to be open-source.
Still, a product can be open-source and commercial! Several Linux vendors make big profits doing just this. The profit is from the support they give to users, who are willing to pay for this support. They're not really selling Linux, they're selling support and their services to create an easy-to-install Linux version.In your example, you can't turn the project back to closed-source since you're accepting contributions from others. Those would all fall under the open-source license. But you own the copyright and the (trademarked) name, thus you can determine if people can offer commercial support for your product or not. They might have to pay you to use your trademark! The value is not in the code but in the name...
To contribute to OpenJDK, you have to sign a paper that transfers ownership of your code to Sun.
Providing an infrastructure for signing such a form would be a nice start for your digital form management project ;-).

How to leverage an Open Source Project commercially? [closed]

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 7 years ago.
Improve this question
Assuming you have been involved in an open source project (GPL'ed) that has been around for as long as 5-10 years, during this time it has been fairly successful - despite a good handful of commercial/proprietary alternatives.
Now, you've come to realize that the long term contributors would like to leverage the project commercially, possibly even in order to make a living or start a company based on it. So that they can exclusively work on it, without depending on other, unrelated, work.
So, what are some of the viable and recommended steps to turn an open source/GPL project into a commercial "success" (in the sense of self-sufficiency), so that long term contributors may preferably be paid to work on the project, without affecting the open source nature of the project itself?
In other words, what are generally some of the more common revenue-creating mechanisms for open source software, and how can these be successfully introduced/implemented - also, what prerequisites/conditions apply?
I saw a company a few years back that took a handful of OSS spam and virus filters, built a web interface to administer them all at once, put it on a 1U server, and sold it as a network security appliance.
It was a nice product for mid sized companies that wanted a single solution for all spam and virus filtering, that auto-updated itself and was easy to administer.
Technically they were just selling the server, and the web admin tool, all the OSS components were freely available, if you wanted to spend the time setting them all up individually.
You should think in terms of the "product halo," which refers to all of the related items and services surrounding a product that are not the product itself. For example, MySQL is open source and freely downloadable, but its product halo could include services like installation, customization, consulting, training, etc. Or Zend contributes heavily to PHP and offers Zend framework, but they also have a number of commercial products surrounding those offerings. Active State creates the Komodo IDE and has an open source version and then a commercial version that extends the open source version. Or take Linux...or any other number of examples. A book that you might find interesting on the topic is Wikinomics.
I think the main issue is the business model adopted by the project owners and the ones who want to turn it into revenue. It will depen on what kind of project is it, such as end-user product or as software API. In the case of end-user projects, Software as a Service seems a very good choice as a business model.
Look out for examples, and case studies on successful projects, such as apache, firefox, sugarCRM...
Focusing on specific niches is also a very important thing.

what public service project would you create

if you had
4 software developers
any open source software
server hardware
internet connection for hosting
100 person days in which to do it?
How about a site equivalent to Rent-a-Coder but for non-profits to solicit volunteer or low-cost developers for public service projects (i.e. make your question easy for the next guy in an equivalent situation). Given the current economic troubles, there are likely to be both a lot of unemployed developers and a lot of troubled non-profits (and a lot of demand for the various kinds of help those non-profits provide). Let's put them together.
Add a point system like StackOverflow so you can earn points by helping out non-profits with their web applications or whatever. Then go get some corporate sponsorship so that you can turn your points into credits at Amazon.com or some such.
Something to replace diebold software?
Duke Nukem Forever? :P

How do I spread awareness of my open source project? [closed]

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've got a couple open-source projects on Codeplex (I'll link if someone asks, but otherwise, I'm not quite that shameless ;)), but I'm not really sure how to go about spreading the word or getting people to take notice. Any suggestions for attracting users/contributors?
See also:
How to get users to your Open Source project
How do you promote/advertise/evangelize your open source project?
How to persuade people to contribute to an open source project?
Blog about them. Release often. If you can, use them in a higher-profile project. Contribute to other projects to build up your reputation. Be very responsive to bugs/feature requests/etc. Keep your issue tracker up to date.
Here are my 10 suggestions:
Interact with the community through forums, mailing lists, uservoice.com, bug tracker, IRC (server / client), etc. Communicate through blog, twitter, and mailing lists.
Give users the feel that the project is actively maintained through quick turn around for bug fixes, frequent releases, and ideally more than one developer.
Solicit user feedback as early as possible before implementing bigger features.
Reduce the friction through good documentation, easy installation, low bar to entry with less requirements (e.g. don't require latest version of .NET just because it is fun).
Maintain development / stable releases, let people trust that stable releases are releases stable.
Integrate with related projects - work with related projects to provide a better end to end experience. Working with other open source teams will eventually get you a reference on their site driving more traffic towards you.
Spend some SEO / analytics time, make sure than when people search for a software package that does X, then yours show up relatively high. Also understand your audience.
Build a testimonials page where you can capture positive community feedback.
Spot people who are contributing patches and invite them to join your team.
Localize your project where appropriate. There are some projects that specialize in providing translations for open source projects (e.g. Betawiki)
This isn't exactly spreading the word, but it will help your projects gain stature: provide good documentation -- well-written, detailed, complete, and above all up-to-date. Producing docs like that is a time-consuming pain in the ass, but it will help your projects enormously and lack of it will make people not want to use them. Given two projects, one carefully-documented and one with nothing but the docs generated by the language's automatic doc generator a lot of people will prefer the former even if it isn't quite as good.

Adopting Open Source Software in an organization [closed]

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 7 years ago.
Improve this question
What are the pros and cons of adopting Open Source software for an organisation? Is there anybody out there who has done this and how well has it been working out with some examples of the softwares they adopted and how it has been in use?
Usually contributions come because people do it as a hobby, then how can we make sure that there will be continued support for it? IMHO, in case of proprietary software there is an incentive for the organisation (money), and they will keep hiring people to keep it under development as long as the software is profitable. Correct me if I am wrong. What are the arguments I might expect from a Manager who might oppose the suggestion to use Open Source softwares?
The term "Open Source" only describes a licensing model. Strictly speaking, the only pro that you are guaranteed to have are the freedoms given by the license, and there are no cons that you are guaranteed to have.
There are many Open Source products that are also commercial, created, maintained, and supported by a company for a profit. There are also many Open Source products that are maintained by volunteers but also supported commercially. For example, if you buy Red Hat Enterprise Linux, then Red Hat will support you on all of the products that come with it, even the ones that are maintained by volunteers.
As for how to be sure that there will be continued support, you can't. Not with Open Source, not with proprietary software, not with anything. With Open Source, if the community is large enough, you can be reasonably confident that the community will continue to maintain it (maybe under a new name) even if the current maintainers abandon it, and you have the option of maintaining it yourself or hiring someone else to do it. Maintaining it yourself may not be an attractive option, but it can be a life saver in a pinch.
With proprietary software, if the author decides to stop maintaining it, you are just plain out of luck. Consider, for example, the thousands of users of Visual Basic 6.
The main pro of Open Source software is illustrated by your comment:
[In the] case of proprietary software, there is an incentive for the organisation (money), and they will keep hiring people to keep it under development as long as the software is profitable.
The trouble is that if it ceases to be profitable (for example, because the code is so stable that people buy it and continue using it without needing upgrades), then the users of that software can be stranded with their nice stable product running on increasingly ancient machines until, one day, the machines crash, or must be upgraded to a new version of the operating system so that they can run some other system, but because the proprietary software is no longer maintained, you have to give up on the application. Indeed, it is not unheard of for companies that sell proprietary software to go out of business. And, if you did not ensure that there was a code escrow account for the software to protect you against the possibility of the vendor going out of business, then you are stuck.
If the code was Open Source and you were sensible (you obtained the source when you obtained the product), then you can take the old product and port it to the new system. How hard that will be depends on the nature and quality of the code - but it is possible. If the software was proprietary, you may never have the option.
The question is: what do you mean with "adopting open-source software". if you are planning to radically exchange every piece of closed-source software (CSS) with Open-Source Software (OSS), you will fail horribly.
I can guarantee you that your organisation is already using OSS in key parts of it's IT-infrastructure.
In my point of view, you only need to formalize how OSS may enter the company and if (and in which form) the company contributes back to OSS. Most companies require a support contract for mission-critical software and mandate that OSS needs to be bought through vendors which provide support.
In many cases, contributing back to OSS-projects is explicitly forbidden and only allowed after the CTO/CIO signs of on a specific contribution.
Simply make sure that your policies are flexible enough to allow what the IT-department currently runs.
It doesn't matter what Manager opposing Open Source is saying.
You have to know well Open Source product you are about to use.
You have to be sure that it right solution for company.
You have to be confident that you can find people on market who know or can learn to use that product.
You have to know TCO for that product.
Then you can argue with manager and give him good reasons how company can benefit from Open Source.
Keep in mind that cheapest solution is not best solution. Companies need to earn money not to save money.
Depends on the situation, but usually, for a, internal, non-critical, no need to secure system, like most of what is done in enterprise, open source is like Halloween and you don't really need to care as long as you follow enterprise policy.
For the other big, important, need to be secured projects, its really simple. You need to have a part in the projects you use and have an internal repository hosting the project (so you have an internal branch that is kept in sync with the external branch). The thing is that those apps are the ones that take a shit long time to make and are supported for thousands of years. The teams tends to change a lot and there's a lot of people involved. Somebody needs and can be assigned to repository/build management.
Now if its only about the manager, then its just about communication and argumentation. Usually they are scared about support because its the long term cost. They tend to like to hear about best practices, well tell them that's what the big companies do (and examples) and that they also tend to participate in the projects and other times they even or its possible to find support for it.
Also, any contractor will be glad to give support of an OSS. Who would say no to money and the ability to develop an OSS.