Slashdot Mirror


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

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?

16 of 87 comments (clear)

  1. What's your audience? by scsirob · · Score: 5, Insightful

    '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.

    --
    To Terminate, or not to Terminate, that's the question - SCSIROB
    1. Re:What's your audience? by jellomizer · · Score: 2

      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 company/government/Not for Profit may pay you to make this software for them, as they may need it for their business however don't really wish to sell it, as software may not be their business.

      However when ever you get funding from a different group you loose your creative freedom. Because if they are paying your bills it needs to be done their way.

      --
      If something is so important that you feel the need to post it on the internet... It probably isn't that important.
    2. Re: What's your audience? by guruevi · · Score: 2

      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 source software and am not needing to beg for food. Red Hat, IBM, Google, Facebook are largely writing, using and distributing open source software, it is entirely possible to set up a Facebook or Google clone, CentOS and Fedora give you access to the entire Red Hat ecosystem free. Even Apple and Microsoft have significant portions of code publicly released. Putting the open source systems together and associated support and inertia are making them rich.

      --
      Custom electronics and digital signage for your business: www.evcircuits.com
  2. That's easy to answer by OzPeter · · Score: 2

    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?

    --
    I am Slashdot. Are you Slashdot as well?
  3. Service Support by martiniturbide · · Score: 2

    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.

  4. An Open Source Developer? by tomhath · · Score: 4, Insightful

    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.

  5. Our profession has evolved by Qbertino · · Score: 4, Insightful

    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.

    --
    We suffer more in our imagination than in reality. - Seneca
  6. Personal experience as someone willing to pay by argumentsockpuppet · · Score: 4, Interesting

    The company I worked for was starting to look for a replacement for Lynx, and I was in the position to choose OpenFire. 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.
    1. Re:Personal experience as someone willing to pay by aaarrrgggh · · Score: 2

      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 as commonplace as Asterisk I end up with consultants trying to gouge for a fairly generic installation. That isn't a sustainable business model. I am also sick of generalists-- I know because I am one.

  7. Work for Microsoft - Seriously by mykepredko · · Score: 2

    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...

    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.

  8. The business model depends by hey! · · Score: 5, Interesting

    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".

    --
    Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
  9. The same you make a small fortune! by petes_PoV · · Score: 2

    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.

    --
    politicians are like babies' nappies: they should both be changed regularly and for the same reasons
  10. Re:Not only that the question is wrong by greenfruitsalad · · Score: 2

    You are mostly right but there are still some ways to make money out of FOSS. From experience: nobody's gonna pay for software support if it's a one-man-show. When I want paid support, I want it available 24/7 with short response times.

    The advantage of a one-man-show company is flexibility. Existing users may be willing to pay to implement a feature they want in your software. So I'd run a sponsor-a-feature programme. Perhaps patreon.com?

    Other than that, the only way forward I see is to grow and start with paid premium plugins.

  11. Shared Source Short Copyright by Target+Drone · · Score: 2

    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.

  12. Payment in advance WITH success criteria by shanen · · Score: 2

    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.

    --
    Freedom = (Meaningful - Coerced) Choice != (Speech | Beer^2), and sad sock puppets' bad mods avail them naught.
  13. Re:Not only that the question is wrong by scdeimos · · Score: 2

    Perhaps patreon.com?

    I've seen people try this. Not everyone's successful with it but it's a step up from a "Donate" button on your project's home page. With the recurring billing on a monthly basis you're more likely to get a revenue stream just from people's apathy towards having to login to cancel it.