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.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
Looking for an issue tracker for a medium-sized web application open project with a distributed team. We are planning to run this on our own server. It must be very easy for new users to submit new issues, and it must integrate well with other software.
Our major requirements, in descending order of importance:
open source
capable of very new-user-friendly bug submit
submitting new issue must be as easy as possible, with only a single screen to fill out (after registration), and few fields visible (e.g. just "summary" and "description" would be good)
Google Code is an example of the sort of interface we like; Bugzilla's Bugzilla instance (https://bugzilla.mozilla.org/enter_bug.cgi) is an example of the sort of new bug submit interface that we would NOT like
it's fine if the default submit interface is not new-user-friendly as long as this is easily modifiable using templates/skins. It would be great to have an "advanced view" for bug editing with additional fields (such as who the issue is assigned to), in addition to the simple view for new user bug submission
has API; or, supports other applications concurrently accessing its db backend (we want to query and modify the issues from other, separate software running on another server)
Other desirable criteria, in descending order of importance:
not frustrating in daily use
has a relatively large community
integrates well with hg (mercurial)
amenable to integration with external:
support desk/request tracking software
project management software
auth systems (and/or supports OpenID login)
modular; if we modify the issue tracker, we want to release those improvements as a module that is easy for others to install
amenable to having some sort of simple, easy-to-use issue importance voting system, e.g. stars on Google code; we intend create or modify such a component to plugin to our own external voting system
amenable to integration with SugarCRM
When I say "amenable to", I mean that we are willing to code an extension to the issue tracker ourselves if necessary, however, the issue tracker's architecture should be amenable to that sort of extension.
Issue trackers which also include support desk or project management features are a plus provided that we can choose to integrate external software instead of using the included stuff. We don't need another wiki (we already have one that we like).
According to Google searches (see the comments), the most popular open source issue trackers are trac, bugzilla, mantis, RT (and possibly Launchpad's). I've also included Redmine because I've never seen a recent comparison between any of these issue trackers and Redmine in which someone had something bad to say about Redmine, and on polls Redmine sometimes beats these others. Feel free to suggest others (bearing in mind that one of the criteria is "relatively large community").
There are undoubtedly multiple good issue trackers out there; many of those listed above claim to be extensible and integrable with other software. What would be most helpful would be direct comparisons between issue trackers by people who have used more than one.
How do these compare to each other on extensibility, integratability, and skinnability?
If you have used more than one of these, which of them would you recommend, and which others have you used?
Which of these are already integrated with a large number of auth systems/support desk systems/etc?
Comments explaining why a particular popular open-source issue tracker (especially one of those listed above) is NOT suitable for our situation are very welcome; this will save me time.
thanks!
Redmine. Been using for a while. Simply excellent.
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.
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.
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
Say I had an open-source project which I wanted to try and generate some exposure for. Would it be considered unethical to set up a project entry for it on several sites such at github, sourceforge and google code, for example?
This would be purely for giving it greater exposure. I realise there might be some practical reasons for doing this, such as wanting to use github for source control, and sourceforge for issue tracking, forums and such. For the sake if this question I'm wanting to focus more on the case where you use one of the sites as the main site for the project, and make "stub" projects on the other sites that point back to the main site.
My gut feeling is that while it may not be outrightly unethical, it might be bordering on the sleezy side...
Stick with one provider. "If you build it, they will come" :)
Besides, once people do start coming, they'll just google the project name anyway. Finding the same project on Sourceforge, Github and Google Code is just going to annoy the hell out of people.
I don't know about the ethics, but consider the practicalities:
you will have to do multiple repeated
uploads to several different sites,
doing it to a single site can be a
pain
users won't know which site to report
bugs at
if you use the SVN/CVS/git
repositories, you will have multiple
copies of your code in different
repositories - a very bad idea
I'm sure there are other problems. So stick to one site - I've been using Google Code for a small project I've just started (CSVfix, if anyone is interesed) and I can recommend Google as being very easy to set up.
I think this is fine, for the reason that each provider may have something you want. You should pick the services that are best for your project. For example:
Google code has file hosting, but the issue management is terrible, so
Launchpad has great bug tracking, but no wiki, and we use Mercurial, so
Bitbucket.org has mercurial hosting etc..
So it might be reasonable to use Launchpad for bug tracking, and Google code for hosting files and wiki, and Bitbucket.org for hosting source.
I would suggest choose your preferred host for your project. You can publish about your project on many forums. Exposure will come via search engines.
I don't know why you think it would be unethical or sleezy. Maybe you can say more about that so people could address your concerns directly. To measure that, consider if you are intentionally breaking the rules of the service, lying to anyone about how you are using the service, and being deceptive in some other way. If you are using multiple services, I don't think you have anything to hide.
Consider the Perl community, which is the one I deal with. Several projects are hosted on one of the source control services, such as SourceForge, Google Code, or Github. The main distribution for most Perl stuff is CPAN, though. Other people may distribute through Freshmeat or some other service. The main issue tracker comes from Best Practical, which hosts a free RT for every Perl module on CPAN. Most of the people I know use the best from more than one service. Indeed, the Web 2.0 way is to create applications by cobbling together services from multiple vendors. :)
You should also think about the social construction of these free sites. Places like SourceForge and Github give out free accounts, but they also sell services. They get the buzz through the free stuff that allows them to sell the premium services. I don't see anything wrong with that. If you're using the free services, just realize that in return for your free use, they get to use you as free tester, advertiser, and so on. Again, I don't see anything wrong with that. It's just part of the deal. You aren't just taking from them, you are also giving to them. There's an exchange between consenting parties.
What would be unethical, I think, is any service that forbids you to use another service or intentionally sets up a situation which would make it hard for you to use another service by not being compatible with common tools or not giving you access to your data (e.g. somehow disallowing git-svn, and so on).
Services spanning these various hosts will be inconvenient and difficult to maintain. For the above mentioned reliance on search engines to generate traffic take care to chose a name that differentiates your project from the web noise. A clear indication that traffic will not arrive is if your project first gets a re-recommendation on spelling. Take for example the people who brought you the chattr project from GNU. Immediately chatr is suggested as the proper search and your traffic will suffer accordingly.
as i has already been said having to maintain the code on several hosts will make it more trouble then it is worth. What you have to think is you would need to make sure that it uploads properly over several hosts, it would more then likely cause confusion to some over if one copy is legit and the others aren't which in turn could cause a bad name for the project before you even start.
End of the day there are much more, better ways to spread the word of your project, social networking sites, specific related forums are two main ones for you to consider, either way you would be better off spending your time posting to several sites then you would uploading and maintaining code on several sites.
I consider having several (independent) mirrors to be a benefit for the community, because such distributedness assures more reliable accessibility of your public work, now and in future (it will survive the failure of any single hosting site).
That's why I want to keep track of the available diffeent options to publicly host open-source projects:
Which public hosting sites for darcs projects are there?
Which public Git hosting sites are there that are free software?
I believe it's rather ethical (or moral) to put some effort into ensuring that your public work is published in the most accessible way (well documented, and with some guarantees about it being accessible at any moment when someone is interested).
The effort for you to push your work to several places independently (I mean, they won't depend on each other) and manage all this is probably not really a nightmare (as suggested in some other answers here), especially with a DVCS. For example, one can even set up Git so that one pushes to several places with just one command.
I feel that unless you are forcing someone to read something done by you, but you are rather just putting your stuff somewhere for it to be findable and accessible if someone is interested, you are not egoistic or ego-whatever.
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.