Hacker News Reader

Comment by marquis | Hacker News Reader

>not releasing the source is evil

I believe it's a cultural necessity given how we make money as software developers. Hardware developers have a buffer in terms of actual production, which requires significant investment. You can reverse engineer any hardware you have in your hands but it's unlikely given 2012 technology that you can mass-produce it and steal revenue from the copied source (patents notwithstanding). I can't imagine a global business environment environment in which open source software is the norm, but I would really to hear some theories - can you imagine how wonderful it would be to be able to explore the source code of say, SpaceX?

View on HN

Some areas where open source software is the norm:

1) Web servers

2) compilers for UNIX and embedded application development

3) ISP infrastructure

I am sure there are plenty of others. My business is trying to bring LedgerSMB to this area regarding mid-range accounting and ERP.

Open source can be effectively monatized in more ways than proprietary software. As LedgerSMB 1.4 comes along we'll be shifting from consulting company to start-up offering subscription services to do things that open source economics doesn't pay for very well. The software will still be open source but it will be monatized through subscriptions (think RHEL) which come with value added components updated in a timely manner. However the fact that it is open source also allows for me to off-set some of the development costs via consulting services (those aren't going away, but they are being de-emphasized a bit).

No I don't mind sharing the plans here. There are reasons why the revenue for these solutions, even if people know what the problems and solutions are, cannot be stolen from me. Open source is just a different game and you have to figure out what the rules are.

For the record the major areas we are going to focus on will be payroll and electronic submission to government agencies. These areas are frequently updated and the issue is that you don';t want to be the first one to ask for the feature and thus pay for everyone else's use. A subscription model lets us spread the cost around. People could try to jump in but I have a head start and a place of great privilege in the market. It would take a long time for someone to be able to challenge me.

In open source the way you get to a point where you can monetize the user base is by maximizing your downstream market (that's those who use your services and your customers' services). The closer you are to the center, the larger that base is. If anyone here says "oh that's a great idea" and tries to do this in LedgerSMB, you'll be starting near the outside, while I have the entire community as a potential user base. And if you go out and find lots of new customers, those are also potential customers for me. I win there too.

The real reason for proprietary software is that it is one way of spreading around the cost of development. You have to do it differently in open source software, but there are actually a larger number of ways of doing it than are possible in the standard COTS world.

Not coincidentally, those are also areas where there's basically no longer any profit to be made. No one makes money selling web servers or compilers for Unix, because it's not possible to compete on price with "free".

The businesses that make money from open source typically do so by selling something else on top. Google doesn't sell open source. They sell services. Red Hat doesn't sell open source. They sell support to large businesses. ISPs sell bandwidth. Etc.

> No one makes money selling web servers or compilers for Unix, because it's not possible to compete on price with "free".

That may or may not be the case. However, it certainly doesn't stop high-quality compilers and web servers being written for Unix.

I never said it did.

Well, here's the approach my business is taking:

1) You can bill up-front for major features development. If someone wants a major feature they can may for it. This reduces the risk of software development because much more of the development is being paid for up front. However the revenue doesn't scale and it's subject to boom/bust problems. This being said it's a great strategy to mitigate financial risk in product development.

2) You can find areas where #1 doesn't work and come up with some sort of customer agreement that does scale. The nice thing is that if that area really doesn't work (updates to payroll for example) for reasons inherent here, then you won't have someone else release something like it fully on an open source model and have to compete with free.

So the way I look at it is that I get some things for free (financing for development), my customers get some things for free(software, upgrades on main packages), and this then creates a market for services I can charge more for because the overall package is less expensive.

ERP is huge business but the thing about it is that going with an open source approach brings benefits to smaller businesses that are currently reserved for huge businesses. A multi-pronged approach to revenue here (consulting, subscriptions, support contracts), allows you to take advantage of network effects between these things, cut risk, and still maintain general scalability of revenues.

If others want to do this with LedgerSMB I would generally advise against competing with core, long-term members of the community. You are more likely to succeed if you carve out a niche for yourself in an area that's not being done or is underdeveloped (MRP would be a good example with LedgerSMB).

Too: proprietary solutions cannot (at a sustainable price point) compete with the quality of free.

As someone noted -- there's a development model which shares the load among many eyes, and produces higher quality work as a result.

There are a few other mechanisms at work, but the upshot is that for utility, and even a fair amount of specialized software, there's no longer a marketplace for the software itself.

>Too: proprietary solutions cannot (at a sustainable price point) compete with the quality of free.

That depends entirely on the community behind the free solution, and what class of software it is. For instnance, I'm not aware of a FOS document management system which would compete with, say, Paperport or DevonThink (Windows and Mac systems, very proprietary).

I didn't say in all cases. Specialized, very high-value, and vertical tools particularly.

But generally the trend is that, starting with OS, development and management tools, and commodity software, Free Software is taking the financial value out of software sales.

For your example, OpenKM and LogicalDoc turn up for searches on "document management open source", though I couldn't say how they compete on functionality, scale, ease-of-use, stability, and/or management.

To shift spaces slightly: there's a pretty small market for proprietary Wiki software. Atlassian and Microsoft Sharepoint would be two that I'm aware of, though alternatives, especially MediaWiki, are very widely used (internal to the CIA even).

What's becoming more common is a service model based on free wiki software. Jimmy Wales has a startup based on offering MediaWiki pages, there's a similar offering based on TWiki that I'm aware of. I'm sure there are others. Similarly, blogging engines as-a-service. The software's free, but the service offering drives revenue.

Could be a way into the docs management market as well.

It is interesting that you should bring up SpaceX. If SpaceX used the GPL, there is nothing to say that you would ever get to explore that source code. The only time you would be guaranteed the source is if you have a rocket of your own and are using their control system, which is arguably when this becomes more than just a wonderful curiosity and becomes truly important.

The GPL doesn't stop software developers from making money, only certain software developers that would like to market their software software in certain ways, like sell it as if it is a scarce commodity when it is not. Although I'll have to take his word for it, RMS is quick to point out that the vast majority of software is produced under private contracts or internally. Under these situations, the GPL has no "not getting paid" issues for developers as the software you produce under contract is the companies to distribute under the GPL or not distribute. In fact, the FSF has an explicit statement that NDAs for contracted GPL work are acceptable (https://www.gnu.org/licenses/gpl-faq.html#DevelopChangesUnde...). RMS doesn't have a problem with companies keeping their secrets or with developers not allowing you to see the source code they write so long as it isn't on your computer. The flip side is that he does have a problem with the independent developer that wants to write a closed source program and milk it for all it's worth by selling it by the copy or the subscription to end users. Admittedly this is a well represented group on Hacker News and amongst entrepreneurs in general, probably because copying bits can be a quick and/or easy way to make money when compared to getting paid for the actual development directly.

To his credit, RMS has been fairly clear (at least recently) that writing GPL software to sell copies is not a viable business model. And no, I don't think that developing proprietary software so that you can force a false scarcity should be called evil, but perhaps immoral is not too far off, and certainly sketchy.

edit: Actually, on second thought, I think RMS hasn't been clear on this; he seems to refuse to answer the question because it is irrelevant. If the business practice is immoral, it doesn't matter if it is viable. I took his silence as conceding the point.

>It is interesting that you should bring up SpaceX. If SpaceX used the GPL, there is nothing to say that you would ever get to explore that source code. The only time you would be guaranteed the source is if you have a rocket of your own and are using their control system, which is arguably when this becomes more than just a wonderful curiosity and becomes truly important.

I've been trying to figure out a good way to post this. It's simply a problem with the market that the code is intended for.

On one hand, you have applications like Office-style programs and web browsers. Every single computer user in the world uses those types of applications. So for those applications, the code has tremendous value as Open Source. Lots of people can go in and improve on it.

SpaceX's code, on the other hand, is incredibly specific for it's purpose. It's intended to be used with a specific hardware configuration, with users that have been trained to a high level with it's use. It's less valuable to the public, because the only people that can really make good use of the code are SpaceX engineers. Even the orbital guidance code is not that interesting, because variations of it have existed for the last half century, and it's equations and algorithms that just about any serious amateur astronomer should be aware of.

> It's intended to be used with a specific hardware configuration

It's that way because the Boeing CST has its own software, as does the Lockheed's Orion and the Soyuz and every unmanned spacecraft ever developed. Development costs and quality could be greatly improved if all of them shared a single codebase.

If more designs shared the codebase, it would end more modular, more maintainable and better tested.

>It's that way because the Boeing CST has its own software, as does the Lockheed's Orion and the Soyuz and every unmanned spacecraft ever developed. Development costs and quality could be greatly improved if all of them shared a single codebase.

No, it's that way because nobody else in the world is using the specific hardware that they're using in the exact same configuration. Nobody is using the same input sensors. Nobody is using the exact same engine configuration or power.

Nobody has the same amount of fault tolerance or backup hardware.

That's what I meant.

Compared to a browser, where most of the more tricky hardware configuration issues are handled entirely by the OS.

I agree with you - the hardware and its configuration is very different between all of them. Yet, the basics are the same and a lot of code could be shared between the different spacecraft if they builders agreed on a certain level of commonality (and it doesn't even need to be a high one).

And yes - a common OS for spacecraft would be a giant leap forward, abstracting the differences in hardware and providing a unified interface for everyone using them.

The strongest barrier against sharing development is the security concerns. Nobody wants people to build missiles with that.

http://www.openpilot.org/ has, so far, avoided these problems.

Not true.

A number of years ago a friend of mine took the largest 10 software companies by revenue, and broke out their software revenue according to whether it was from sales of software, or from consulting.

Microsoft was the only one who made more from sales than consulting. Every other one made more from consulting. Generally at least an order of magnitude more.

I am sure that a similar exercise today would produce similar results.

This fact strongly suggests that copyright protection is not essential for the livelihoods of most software developers.

I question whether revenue is the right metric given that Microsoft's profit from software sales over the last 20 years probably exceeds the profits from consulting of the other 9 companies.

Also, I question whether the 10 largest companies are representative of the industry as a whole.

If you go to the bottom end, I suspect that there are a lot more 1 man consulting shops than 1 man software development shops. Yes, there are a lot of app developers out tere (a new phenomena that you didn't see much of 10 years ago), but there are a ton of people who do contract work for companies with one-off needs. Software that typically never is seen outside of the organization that asked for it.

As for the top end, Microsoft is a monster. But their model has not proven replicable by anyone else.

The ascendancy of consulting over software sales is also rooted in history. The first pure software company was the Computer Usage Company, in 1955. They were a consultancy. So was every other software company that followed for a decade. It was not until 1965 that Applied Data Research offered AUTOFLOW for sale. (The company was predominantly a consultancy.) And it was not until they filed a lawsuit that forced IBM to unbundle software from hardware that the industry as a whole accepted that software was something that could be sold. (Previously you bought hardware and software came with it.)

Reply on news.ycombinator.com