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.
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 2 years ago.
Improve this question
I've found today in my inbox an email from google where they announce that CWS payments API is deprecated
I'm working to create a Chrome extension that I want to release with the in-app payments support to let the user purchase a license to unlock full features. I was oriented to the CWS native payments API, but Google's decision to deprecate the API is a very bad news.
At the moment I've found a nice Wordpress plugin that will manage licensing, I'm thinking of using it to create a licenses backend but I'm not sure about it because it's mainly focused to be used for wordpress themes or plugins, so to implement it on client side for an extension would require some workarounds.
How do you will manage your in app purchases and licensing for Chrome extensions or Electron apps?
Alright, so as I am in the same situation as you are, I did a little bit of research. Here is a summary of my findings and comments on the matter.
There are three things to think about before you get started with the implementation:
The type of payment processing service you want to use;
The way you want to limit features for the free version (and for multiple tiers of plans);
The security of your users information through your extension.
Let's go through each of these one at a time.
1. Type of payment processing
There are two main types of service providers that will allow you to collect payments in you extension. Payment processing platforms are the first type: they allow you to process payments and will generate receipts, but they won't manage the different taxes and regulations of different countries. If you operate solely in one country, or in a few countries where taxes and regulations are the same, this won't affect you.
However, if you have users around the world, especially in Europe, implementing the rules to handle all of the different taxes and regulations can get really complicated and messy. But you have to do it, otherwise you put yourself in a situation where you are at risk of getting fined. That is where the second type comes in: the merchants of record. These are companies that will charge the users on your behalf, removing all of the complexities of taxes and regulations from your plate. They're essentially acting as a reseller of your products. Of course, they take a small cut from your revenue to pay for the weight that they're taking off your shoulders and putting onto their own.
Payment processing platforms will be cheaper (ex.: 2.9% + 0.30$ per transaction for Stripe), while merchant of records take a bigger cut (ex.: 5% + 0.50$ for Paddle). However, if you deal internationally, the 2.1% higher price is likely more advantageous for you, just because it saves you a lot of time and development work.
It's important to note however that merchant of records are unlikely to take on a brand new project, especially for Chrome extensions. That's because the amount of revenue those extensions generate on average is pretty low, and often not really worth it for them. Still, I suggest you hit up a few of them before deciding do go the classic payment processing way, just in case you can get in touch with a salesperson who sees potential in your project and is willing to take you on.
Here are a few merchant of records:
Cleverbridge
2Checkout (offers both MoR and basic payment processing services)
Paddle (does not support new Chrome extensions at the moment)
FastSpring (does not support Chrome extensions anymore, as of 2021)
Here are a few payment processing platforms:
Stripe
Paypal (from my experience, Paypal is a lot less developer friendly than Stripe)
2. Limiting features for free or tiered plans
The way features are limited for non-paying users will differ from one extension to the other.
If the features you want to limit in your extension already rely on a backend, to fetch or process data for example, it would make sense to implement the limitations on the server side. You would simply pass the user's ID, which could be stored in chrome.storage, to each request made to the backend. In addition to that, you could also disable the related elements on the client side, such as hiding or greying out buttons, tabs or fields, to make it clear to the user that those features are locked. You'll want to make sure the limitations are in place on the backend as well however, because otherwise a user could just inspect your extension and enable premium features without paying.
If your extension mostly or only operates on the client-side, then you will have to render the interface conditionally, based on the user's plan. The scripts or interfaces that will be added will most likely have to be returned by a backend, as pretty much anything that is done only on the client-side could potentially be inspected and exploited. In that case, any backend technologies or platforms you are most familiar with can probably be used to set things up.
Keep in mind that most of the payment processing and MoR listed above have APIs and guides on how to implement them securely in apps and websites. However, if you know Wordpress well and can set up a secure communication between your Wordpress and your extension, go ahead. If you want to use an online service like Zapier to link existing authentication and licensing services together, go ahead and do that!
There could be a lot more details in this section - there is a ton of material to cover, so I suggest you look for articles and tutorials online to help guide you in this process if you don't have much experience in the matter.
3. Security
This section won't be long, but it is very important one. No matter which payment processing platform you decide on or how you limit access to features in your extension, it is crucial that you make sure that your users information can never fall into the hands of another user. That includes reverse engineering and exploits of your system.
The more things you decide to handle yourself, the more risk there is, especially if you are not experienced. Keep that in mind when making your decision(s).
That's all for me. I hope that helps a bit!
I know it's probably a lot of information without any detailed "how-to", but without having in-depth knowledge of your product and situation, it is impossible to say what you should do exactly.
P.S.
If that can offer any guidance, here's what I will be doing for my own extension. Seeing as it's already very reliant on a PHP backend, I will add a few features to the backend in order to communicate with the Paddle API. So all of the limitations will be implemented on the backend, and I will add messages and visual indicators on the frontend to inform the free users of what they can and cannot do.
[Edit]
I just received a message from Paddle indicating that they do not support new Chrome extensions at the moment. Sorry for the misleading there.
[Edit: June 2021]
After an update earlier this year, FastSpring has updated their security standards, which makes it unusable within Chrome extensions. After I enquired, their support agents informed me that they do not support Chrome extensions anymore (and that it was only "accidentally" supported before).
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 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 ;-).
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 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
This question has always been around my head.
Can someone create a new product based on an existing open source project?
Say you want to create an "Apaxe webserver" that is basically Apache with your some extra plugins ( say support for ASP or something similar )
Is this possible?
Would you be able to create a closed source product ( either free or licensed )
As for GPL seems clear it is not possible because the source should be open. But what about Apache license, BSD and others "corporate friendly"
Are the price ( free for most of the project ) , bug fixes and counting with the core development team the only thing that prevent from others to commercialize those OS products?
What about: Khrome a commercial product based on Chrome with ActiveX support ( who would dare to do such a thing :P )
EDIT
Thank you all you all for your answers.
So, again
What prevents from similar ( clone ) products from appearing in the market?
:)
NOTE: I know we are not lawyers, and we could read every OSS license here http://www.opensource.org/licenses.
Nothing prevents clone products appearing on the market. Look at all the various linux distributions, for example. The X.org project was forked from XFree86. And so on.
It happens relatively infrequently, though, for a couple of reasons:
The original project has the first-to-market advantage
The original is usually being given away free
So unless your version is significantly better than the original, you're not going to get much uptake or make much money out of it. If your version is significantly better, then go ahead!
From the original developer's point of view, the power of the GPL is that it forces such clones to share any improvements with the rest of the world, so they can be incorporated back into the original.
Generally, my read of the licenses is:
You can make a derivative work of any project based on one of the popular licenses (i.e. GPL, LGPL, Apache, MIT, BSD).
You may charge money for at least the distribution & packaging of your derivative work.
Depending on the license, you may also have to distribute your modifications in source form and/or include notices in your distribution.
So to your question about Apaxe: yes, you can do this as far as I know. I believe that the Oracle HTTPD server is actually derived from Apache, and it's definitely not free!
Here's my 10,000 foot view of open source licenses:
"Real" open source licenses (eg: MIT, BSD, Apache I think, etc.):
You can do whatever you want with licensing derived works. It can be closed, open, etc. The license places no restrictions on your licensing of derived works.
"Restricted" open source licenses (eg: GPL, LGPL):
Derived works must include specific license restrictions; for example, the GPL requires derived works to be GPL-ed. Essentially your rights are restricted for derived works.
Charging for products is separate from either of these; neither type restricts charging for products, although some licenses place restrictions on the rights you can retain and/or must convey to receivers of your software (ie: the "Restricted" licenses).
Hope this helps.
Edit: Changed by original "DRM" term for GPL type licenses to "Restricted", cause some people attach negative connotations to DRM, and/or cannot grasp how the GPL restricts your rights for derived works in an almost identical way to any other type of DRM (ie: controlling what you can do with it). Seriously, you can be a FSF supporter and still grok the concept that the GPL is more restrictive than "real" open source licenses. The question is not about which type is right or wrong, it's about what the difference is.
Red Hat (and most of the other Linux vendors) charge for support, not for their software - which is primarily how companies can make money off of code that is GPL licensed.
It really depends on the license the open source project uses.
Disclaimer: I am not a lawyer; you should always read the license for full details.
If a project is under the GPL, then anything you derive from it must also be released under the GPL (or a compatible license, and if it is released at all). You're still allowed to charge money for it, but anyone who buys it has to be provided with the full source, and you can't prevent them also selling it, or giving it away for free.
If a project is under the BSD license, you can do pretty much anything with it including incorporate it into a proprietary closed source product. There is BSD code inside Windows!
Other licenses fall somewhere in between.
look at MyEclipse, its really just eclipse+free plugins+myeclipse's plugins and it cost some money.
What prevents from similar ( clone ) products from appearing in the market?
Nothing. The real question is: How can a similar cloned product get more popular than the original product?
Some cases where somebody might clone/fork a project:
Picking up a dead open source project and continuing its development. If the new derived product is maintained regularly and it gets more updates than the original version, then people will start using the new version. This is one of the big benefits of open source - good software does not need to die, just because the original developers stop developing it, but someone else can continue from where they were left. One example of such a project (which I've used) is that the development of Turck MMCache had died out in 2003, so eAccelerator forked it and continued its development in 2004. I'm sure there are lots of other examples.
There is a disagreement in the developer community of an open source project, and the project splits into two. That's why it's best to strive for a common understanding in open source projects, so that the community would not be split needlessly. If a project is split, the projects may continue living if they managed to attract enough developers and users, but otherwise they may slowly die. In general, splitting should be avoided, because it makes the community more fragmented and weaker. IIRC, in the video presentations of Producing Open Source Software (good stuff!) they mentioned a case where the original developer of some project wanted to take a completely new direction in the development, but the community of other developers wanted to keep the old direction. The result was that the original developer was kicked out of the project, so he created a fork of the project, while the rest of the community continued the development of the original project.
A commercial closed source derivative of an open source project which was released under a permissive license (for example BSD). The derived product would need to be considerably better in features or in support than the original product. Otherwise people will prefer using the original open and free product.
Isn't that essentially what red hat does? Even though they have fedora, they are charging money for their linux distribution. Granted, they've written a lot of code for it, it's still based on open source-stuff.