Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Open Source Businesses Software

Ask Slashdot: What's the Best Business Model for An Open Source Developer? 87

An anonymous reader writes: I'm interested in creating really good open source software. However, unless programmers have an incentive to work on their projects for long periods, many projects are be abandoned.

There's many business models surrounding free/libre open source software: support (pay for help, or additional features), premium (pay for more advanced software), hosting (pay for using the software on someone else's servers), donation (two versions of the same app, pay because you want to be nice to the developers), etc. Not all of those business models align the interests of the developer and the customer/user in the same way: support-based models for example, benefit developers who introduce certain mistakes or delay introducing features. (In the short term. In the long run, it opens a door for competitors...) Which of those align the interests of both?

The original submission also asks if any of these models are "morally questionable" -- and if there's other business models that have proven successful for open source software. Leave your best thoughts in the comments. What's the best business model for an open source developer?
This discussion has been archived. No new comments can be posted.

Ask Slashdot: What's the Best Business Model for An Open Source Developer?

Comments Filter:
  • by scsirob ( 246572 ) on Sunday September 17, 2017 @09:35AM (#55213715)

    'Really good open source software' doesn't say much. The business model, if there is one at all, depends very much on the audience you target. Enterprise companies will have different incentives to pay you than school kids do. There's quite a difference between making money from the 1000th Flappy Birds clone, or from some financial statistics system that may change a business forever.

    Perhaps if your goal is to make a living writing software, get yourself a well-paying job as a developer or start your own closed-source business, and make open source programs on the side without a business model.

    • Different models work for different software.

      For the good old boring B2B (Business to Business) software. Normally you can give away the software but pay for consulting and support services to keep it running. As the product is sufficiently complex enough that your expertise as the creator will be able to help customers implement it.

      Other approaches is having the software in the cloud, where people pay for the software as a service.

      Other approaches is if you could get some sort of grant for development. A

      • Sounds like the right direction. Some companies pay to have open source developed (or more often: improved) because they want the functionality and are happy to pay for it, but they don't want the hassle of continued support or licensing issues that come with bespoke or proprietary software. In that case, buying into a viable FOSS community is a good choice.

        If you, as a developer, want to make money building extensions for such companies, you will need some credibility with the communities to which you s
    • by Anonymous Coward

      > Perhaps if your goal is to make a living writing software, get yourself a well-paying job as a developer or start your own closed-source business, and make open source programs on the side without a business model.

      Is that the real state of things? That's rather telling. I've been writing software as a living for 20+ years now, and still to this day I probably couldn't put together a convincing argument (meaning: it needs to convince *me* first and foremost) that I could ever make a living working on

      • That's because most people are misinterpreting open source. Open source doesn't mean you are obliged to redistribute the code to the world for free and rely on hobbyist communities to support your software. It simply means that your clients can take your code elsewhere if you disappear or fuck them over. If your clients keep leaving you, you're simply not offering value and it doesn't matter whether your license is open or not, if it's not, it simpy means they will feel more screwed.

        I write exclusively open

    • Correct - get well paying job with a company that allows you to support some of the open source stuff that trips your trigger. Or, find something in the company that just bugs the living shit out of you, re-write it in something open (on your own time!) and release it as an open source project.
  • by OzPeter ( 195038 ) on Sunday September 17, 2017 @09:38AM (#55213725)

    You choose the one that pays the most money for the least effort.

    However finding the model that best suits a particular client and developer is a totally different question and (IMHO) can not be answered without knowing specific details.


    And a note to the "editor" . What's the point of deleting a clause from the original submission if you only turn around and then repeat it in full, albeit with some additional text saying that the OP also originally asked this clause? Is this some sort of power trip to show that you actually "edited" the submission? Or is it some sort of "style" that demands this slice and dice?

    • Whatever model you choose, make it easy for the customer to spend their money with you.

      Here's a useful trick that I learned. To cut down on contracting costs with larger institutional customers:: use task order contracts. A task order contract is a blanket contract for quantity of future services the customer will request at his own discretion. This solves the problem that there are many times the customer needs a little bit of your time but it's really impractical to contract for $100-$1000 of work. With

  • by martiniturbide ( 1203660 ) on Sunday September 17, 2017 @09:41AM (#55213735) Homepage Journal
    Maybe (personal opinion) the best business model for open source software is "service support" for whatever software he develops. But it depends a lot of what kind of software you are developing. If it is a Game it will be hard to try to get funds for support, but if it a software that can be used on the enterprise it may be interesting to offer professional serious support for the one paying a subscription. If your software if targeted to the enterprise it can be interesting to review Redhat's business model.

    If your software is more focused on the "end user" (non corporation) you will have to do continuous campaigns for raising money like using Patreon, requesting money goals for new functionality and asking for donations to continue development.

    But no matter if it is open source or close software raising money is always a nag.
    • And by the way "morality" is a thing of people, not software.
    • by hord ( 5016115 )

      Pretty much sums my opinion up but I wanted to add one thing: Eat your own dog food.

      Whatever software you build, make it useful for yourself and actually use it. It will always be part hobby but using it seriously will force you to either abandon it or enhance it. If it solves a problem and you are enhancing it you can get paid for this because other people that find the software useful are probably lazy. If no one else finds the software useful, you still have a very good tool.

    • by Kjella ( 173770 )

      Maybe (personal opinion) the best business model for open source software is "service support" for whatever software he develops. But it depends a lot of what kind of software you are developing. If it is a Game it will be hard to try to get funds for support, but if it a software that can be used on the enterprise it may be interesting to offer professional serious support for the one paying a subscription. If your software if targeted to the enterprise it can be interesting to review Redhat's business model.

      No, don't go comparing yourself to a billion dollar company. How much they're willing to pay is directly related to how critical the system is. They can charge the prices they do because if shit really hits the fan and your business is crippled they can throw a 24x7 team of engineers at it. I've been through one such incident in my career (not related to Red Hat) when the end of month financial processing would fail and we had support teams in California, India and France working around the clock to find th

  • An option I didn't see is to consider selling the compiled program, and release the source code for free. People who wants to support your project will buy the compiled version, and hopefully not release the compiled version for free on an alternate mirror (which would would be like pirating). People who care about the source code, and wants to modify it, they can get it for free and do it and compile it themselves.

    Has anybody ever tried this model? Indeed, as someone has already said, it depends a lot
    • That's not pirating at all, that's the nature of open source. For example, take a look at RHEL and CentOS.
    • by hord ( 5016115 )

      I'd argue OpenBSD does this (along with many Linux distributions) by selling pressed CDs of their OS. At one point they even copyrighted the ISO layout to prevent duplication shops from legally making copies. The sources (and binaries) have always been available online. I stopped buying them but I have to admit that I really liked having a collection of physical OpenBSD CDs with nice art (and even music!).

    • by nomadic ( 141991 )

      "and hopefully not release the compiled version for free"

      I think I found the flaw in your plan...

  • by tomhath ( 637240 ) on Sunday September 17, 2017 @09:56AM (#55213785)

    It sounds to me that you have to separate goals: 1) work as a free lance developer 2) work on an open source project.

    Either one of those is pretty easy to accomplish on its own (assuming you're a good enough developer to get hired to do the work someone else wants, or a good enough programmer to write a popular open source project).

    But combining the two will be very difficult (not impossible, but very difficult). Being paid for support means you must develop and market a product to someone who is willing to write checks. That alone is a huge challenge. Doing it on your own when your customers will have the source code makes it even more difficult.

    • It sounds to me that you have to separate goals: 1) work as a free lance developer 2) work on an open source project.

      Those are definitely not mutually exclusive.
      I've developed a system (hardware & software - for monitoring and automation of hydroponic growing) based completely on open source/open hardware components, and as soon as I get around figuring out what I'm doing wrong with Github will have it open sourced myself. Software code, circuit diagrams, and probably even the PCB designs.
      In the meantime I'm talking to some people on commercialising the whole thing.
      My business model is two-fold. I'm available for hire

  • by Qbertino ( 265505 ) <moiraNO@SPAMmodparlor.com> on Sunday September 17, 2017 @09:58AM (#55213799)

    AFAICT our profession has evolved. The sole developer doesn't exist anymore, at least not for longer than a project solving a specific problem. That means that the tasks we do as a computer expert vary very much throughout the course of our assignments. Most mundane stuff is automated and the practive of sharing code via the free open source is so commonplace, that most problems can be solved by downloading a lib from the interweb in 5 minutes.

    All in all this means, for me, as a freelance developer with strong ties to FOSS, that I bill my hours and let the customer decide with my consultation where I'm best suited to bring in my moneys worth.

    I've discovered that simply charging by the hour is the easyest and fairest for all involved in the long run. So that's what I do. I offer to do anything that falls into my wide field of IT expertise, decline any useful help for things I'm not good at and ask 65 - 70 Euros per hour. End of story.

    • You're right, BUT, I think it is your career that has evolved, you've become a consultant. Not a bad thing, bill the hours and any code (or not - end product may be advice to buy X or configure Y to do Z) is a side effect. You may also be able to release code/solutions for free, unsupported, off the back of paid work - many customers don't care as long as they get their solution and (non-exclusive) rights to any custom code in it. Exclusive rights cost more - because you can't use the knowledge gained or

  • The best business model is busking.

  • You can't say "unless programmers have an incentive to work for long periods" and " benefit developers who introduce mistakes or delay features" at the same time.

    OSS might take advantage of the free contributions that developers are willing to give, but that's where the free ends. If you want to create a product that requires more contribution than you can get for free, that's the very part that you need to charge for -- by definition.

    There's no "morally questionable" surrounding needing to get paid to giv

  • by Anonymous Coward

    Getting hired by RedHat is by far the best model that I know.
    Their business is growing. They pay well. The other guys there are smart, hard working. They change the world.

    Smaller companies could be a good situation too, but there is a bunch of risk. Even well-established companies doing F/LOSS have a hard time. Most eventually sell out so they can pay their employees.

    There are many F/LOSS-based companies that do the less-than-nice open-CORE model. Basically, the F/LOSS stuff is only good for toys, not f

    • Customising a CMS for the needs, tex, workflow of a specific company had nothing to do witn FLOSS. It is live thevdifference between a builder and his tools. Everyone knows how to use a hammer and saw.

      The design of these things is pretty much OSS ( ok, OSH) but a specific building? Not so much. But it is OK since I don't care about other peoples websites. I care about the quality of the tools that are used to build my website.

      That is where the 250K goes

  • by Anonymous Coward

    Q: How many programmers does it take to change a lightbulb?
    A: Only one, but first I need five weeks to undo everything the last idiot did.

    That's my business model. Cleaning up after idiots who were using FOSS tools they didn't understand, and whose sins have found them out.

  • by argumentsockpuppet ( 4374943 ) on Sunday September 17, 2017 @10:25AM (#55213873)

    The company I worked for was starting to look for a replacement for Lynx, and I was in the position to choose OpenFire [igniterealtime.org]. I wanted to find a host, someone that would offer configuration services and a host for it. I reached out to the various listed supporting companies at the time and got nowhere. I would have been happy to pay someone for a dozen hours worth of configuration support. Instead I ended up setting it up and working through all the issues myself, but that was my least preferred option. There would have potential for ongoing reconfiguration assistance. Eventually we switched back to Office 365's (renamed) Lynx system. That's thousands of dollars I would have been happy to redirect to an open source support company if I'd been able to find one.

    If there's a lesson to be learned there, it's that there is money to be had if you can find the demand.

    What software you develop will determine what service you can offer for it. What I want to see more of is:

    • * Open source software for free
    • * Configuration support for a fee
    • * A hosted server with support as a service.
    • As a consumer much like yourself, I can agree.

      However, I fear that with the approach of free software with configuration fees, you will get into the ballgame that is <sarcasm>"sure you can defend yourself in the court of law", or "sure you can do your own taxes", or "sure you can ..." </sarcasm>

    • Hands down agree! I want to pay experts to do the dirty work on systems they are intimately familiar with. I am willing to pay a modest ongoing retainer (~1 hour per month) to support general upkeep, plus another hour or so for patching and minor fixes. I want the expert to tell me how the system should be set up, what I can expect from it, and what I can't, up front. I don't want to be locked out of making minor business as usual updates.

      I hate subscription fees, because it decouples value.

      Even things

  • by mykepredko ( 40154 ) on Sunday September 17, 2017 @10:38AM (#55213915) Homepage

    The obvious answer on how to survive on writing open source is to work for a large company that will pay you to do it. My first thought was:
    - IBM
    - Redhat
    - Oracle

    Doing a quick search on who are the biggest corporate contributors to open source software, the first thing that came up was this article: https://www.infoworld.com/arti... [infoworld.com]

    IBM, Redhat and Oracle are also good choices - if you don't want to starve and you understand how the open source ecosystem works, go corporate.

  • by hey! ( 33014 ) on Sunday September 17, 2017 @10:41AM (#55213927) Homepage Journal

    on the nature of your customer and the type of software. When you talk about 'business models', before you get into any kind of complicated strategy, the important thing to fix in your mind is that you have to answer this question: where is the cash going to come from?

    Let's say your software is a version of Tetris. In that case you don't have many places to get cash from. What you'd do is to find sources of revenue that were so small that it really isn't worthy anyone's time to download the source code from github and build it themselves. Put it in the app store and charge $0.99, or throw up an occasional ad. Just avoid being too greedy, and people will be OK with the bargain. And make sure the app is relatively bug-free, because people will simply stop using it if it frustrates them and there goes your ad revenue.

    Tetris represents one end of the spectrum along several dimensions: it is simple in concept and use; it is as non-critical as any app can be. Now I spent a decade as a lead developer in a small company with a product that was the exact opposite ends of the spectra. It was highly complex, took training to operate and administer; had many, many components to install and configure, and was mission critical. This software happened to be proprietary (not my choice, at the time many of our customers had "no open source" policies, strange as that may sound), but the practicalities from the customer perspective would have been the same either way.

    License fees were only a tiny fraction of our revenues; in order of size our revenue streams were (write this down): day-to-day technical support, on-site installation and training, software customizations, hardware sales, license fees (in a distant fifth), and finally advanced training. From a revenue standpoint we probably might as well have been open source. There is one thing that being proprietary protected us from: competition. You will have to consider the question of why your customers will turn to you when they could in theory turn to anyone. Competition from other developers is the single biggest problem for any open source business model.

    So on either end of the complexity or mission-criticality scale, to make money with open source you've got to be the most convenient way of getting things done. For simple apps, keep them cheap and reliable. For complex apps, you have to sell yourself, and that means being pleasant and professional. If you build a team, don't fill it entirely with grouchy genius slobs; make sure you have people on the team who are young, attractive, and personable too. If you've never tried it, you'll be amazed. If it's just you, well you might not have much to work with, but you should spruce yourself up a bit. Maybe not a suit -- customers will see that as phony if you're not the type -- but maybe throwing a blazer over your jeans and t- shirt will hit the right note.

    As for technology, if you have invested a lot of your life in developing a product you'll want to avoid becoming commodity (i.e., easily replaceable) labor after it's finished. That means you need to select your platforms carefully. Avoid the latest "golden hammers" that everyone's learning. Instead look for good projects that make your job easy and have enough of a user base that support won't go away overnight. Think "Scala" rather than "Node.js". Again -- this is from the developer's standpoint. If you're a customer paying someone to develop a system that you will open source, think "Node.js" rather than "Scala".

    • It's not strange to have a no open source policy. Using open source is the opposite of buying IBM: people can and have been fired for choosing it. If you buy proprietary software and it goes tits up, it's on the supplier. If a FOSS product breaks, it's on you. Worse: the same goes for patent and IP infringement suits: a client of mine has been on the receiving end of one of those.

      With that said, there are mitigations for that and companies have come around to being open to open source
      • by hey! ( 33014 )

        The scenario you spin posits that you're working for an incompetent. Which is a common use case, I grant you, but not universal.

  • Print "Hello, World!" *Posts on Github*
  • As commented in a previous thread, I think that big companies are mostly using open source as a secondary marketing resource. Why not using it as a real technical resource? At the start, perhaps only for innovative, future, R&D projects, but actually-relevant ones. Treating open-source development as the in-house one, by allocating good enough resources to it (e.g., knowledgeable and motivated managers, realistic/adaptable milestones, adequate promotion of new projects, etc.). The prize? Getting a knowl
  • by petes_PoV ( 912422 ) on Sunday September 17, 2017 @11:56AM (#55214191)

    I'm interested in creating really good open source software.

    What differentiates "really good" software - open, free, libre, whatever - from all the rest has little to do with the code (so forget about the programmers, they're the easiest part) it is the design, support, the testing, the integration, the documentation, the UI design, the publicity and user-community.

    If you want those to be "really good" then none of it comes for free. It is easy to get people to write code. But it is virtually impossible to get a good, free, user interface. The design is drawn out, the focus groups are hard to organise, the features that allow for disabled users need thought and experience, making it cross-platform is tricky and making it intuitive needs a huge amount of talent.

    As for documentation. That needs a lot of work by a lot of people. It's dull, often sets the authors at odds with the developers and takes effort to keep up to date.

    Add in all the other factors, running a community, testing, integration - and you have little chance of getting anything out of the door by relying on "free" help. So the only workable business model is to make sure you start your project with a great deal of hard cash. Then, when all the work is done and all your life savings spent - then, you will have some "really good" software that you can give away, for free.

  • Open software's main benefit is the ability to easily fix and customize it yourself, and to make it possible for other developers to fork custom versions. For many professional users, the gratis feature is just a bonus.

    So just remove Freedom 0 [gnu.org], and use a licence that requires users to pay if they make (production) use the software. Have the source and build exposed, and allow anyone to sell forks, but have the licence say that users of those forks still pay you, while fork developers can charge a premium

  • What follows assumes a B2B or B2D (D = developer, which is a unique creature in its own right) product.

    Host a multi-tiered version of your open source software. The value add for which people will pay is twofold:
    1. The stack from infrastructure to business software is taken care of and presumably "just works";
    2. The subject matter expertise required for accommodating advanced or nuanced use cases.

    Tier A = Free, Tier B = $[x] per month, Tier C = $[y] per month and so forth.

  • Release it under AGPL. If anyone wants a more permissive license (that is, if they don't want to release their own source code), then charge them for that.

    LZO does similar things [oberhumer.com], but also has some enhancements over the open source version. The open source version is still very good.
  • An often looked over option is that you can sell the software. There's no provision whatsoever in any of MIT, BSD, GPL, and numerous other licenses against selling the software.

    In the event you're selling to consumers rather than developers, it doesn't matter the slightest if you make the source code available. The bulk of your clients either won't know how to install from source, or won't bother if you're asking for a reasonable amount to keep the lights on.

  • Then the answer is that you're asking the wrong question. Look for a company that writes OS software and work for them.

    The odds are really good that if you want to start a business, you're not going to be a programmer. You're going to be a business person.

    While it certainly is possible you're one of the very rare folks that wants to and can do both business and program, the odds are against it. And if you're coming here to ask this kind of question, that pretty much seals the deal.

  • How about offering premium developer support in a 1-1 video conference? There's an app for that... https://bigsmall.io/ [bigsmall.io]
  • by Target Drone ( 546651 ) on Sunday September 17, 2017 @04:30PM (#55215365)
    I'm not sure if anyone has tried it but perhaps a good compromise between open and closed source would be:

    1) Publicly available source code - so that customers have the option to fix bugs or apply patches made by the community
    2) Proprietary license - customers pay an annual fee and in exchange get all bug fixes and new releases
    3) Short Copyright - after 6-24 months the software reverts to a BSD style license. The term is meant to be just long enough that customers want to pay you for a more up to date version. However, it's short enough that you aren't locking customers in.
    4) Free for personal/non-profit use - This is optional but it might make sense to only charge businesses since they have deeper pockets and are less likely to pirate the software

    The idea is to try and strike a balance between making people pay you to write code, collecting code submissions for the community, putting together builds, etc. yet still have the code return to the public domain so that people are free to fork it and start an open source project or competitive business.
  • by shanen ( 462549 ) on Sunday September 17, 2017 @06:31PM (#55215883) Homepage Journal

    I feel like a sucker rising to the bait again, but...

    How about if you, as an OSS programmer, prepared a description of the work you are going to do, how much money you feel you should be paid for doing that work, and the criteria by which the success of your work would be evaluated? Then people who want you to do the work could buy "charity auction shares" in your project, and if enough people agree, then you get the money, and afterwards (according to the schedule and budget included in your project proposal), the results would be available to the world. (Don't want to run your own project? A proposal for a larger project should certainly include funding to hire additional programmers.)

    Oh! You say you are not an expert in preparing project proposals or managing projects? You're just a good programmer, eh? Well that's why the "charity share brokerage" (CSB) should help with the expertise of making sure that the project proposals are complete and feasible. The CSB would also be responsible for trying to reach prospective donors and for evaluating the results in accord with those success criteria. They should also maintain the website where the donors can look over all the projects they'd supported, see what nice results they'd helped, and thereby be motivated to donate more money for other projects.

    This idea differs from all of the crowdfunding websites that I know of by limiting the donations to clearly defined projects and by focusing on accountability and results. The CSB would earn a tithe from funded projects by providing real project management support, whereas all of the crowdfunding websites I've studied just take the money and run away.

    By the way, the same mechanism can easily be adapted to handle the ongoing costs incurred by projects that have already completed their development goals. One obvious way is to ask the people who want to use the project's product or service to help donate for the ongoing costs, with special incentives if the current ongoing-cost project expires before the next one is fully funded.

    LoDSAUPR, atAJG. However, at this point it would take a bit of doing to convince me that you're sincere, and more doing than that to convince me of your power to implement. I don't think there are many such people left on today's Slashdot.

  • In terms of the "best" business model, OSS is no different than closed source, in that there is no one absolute "best".

    What you need to do is determine what your specific business priorities are and which approach to business is most in line with them. Are you in it to maximize profit? To be able to work on interesting things? To advance a social good? Etc.

    Each of those goal has a different "best" model.

    If you're like most entrepreneurs, your goal is most likely a mix of things, which complicates the equati

I've finally learned what "upward compatible" means. It means we get to keep all our old mistakes. -- Dennie van Tassel