The Home Stretch
-
Amongst other things, I've also noticed that instead of "You were granted Nice Post" it now says "Earned Nice Post" since 1.0.
That's the kind of quality improvements that pushed them over that 1.0 hump.
-
Amongst other things, I've also noticed that instead of "You were granted Nice Post" it now says "Earned Nice Post" since 1.0.
Which is a step back I think. "You were granted" is undoubtedly true; "you earned", not so much.
-
Which is a step back I think. "You were granted" is undoubtedly true; "you earned", not so much.
As a general rule, they should rewrite all the text on Discourse to be as non committal as possible.
"You got a badge, for some reason, unless it's not showing up, or it breaks the site, in which case you didn't. Well done! Or not."
-
The RWTF is, of course, that they are undermining their own productivity (by overworking their production staff) while at the same time damaging their client credibility (by promising unreasonable release dates). The result is that the release will never, ever occur, and the company will tank.
Get out while you can, before your career is destroyed by guilt-through-association.
Actually, I take the first statement back. The real RWTF is the broken economic model of software development in the first place. There are basically five (HEAHD) models of software compensation or lack there of (open-source, bespoke, bundled, off-the-shelf, and subscription), none of which really work.
Of them, the most lucrative - and ironically, least effective - models are the two-headed monster that is bundled and off-the-shelf, mainly because they give the ordinary consumer the comforting illusion that software is just a commodity like tissue paper or ice cream bars. Indeed, with bundling, most PC users are unaware that they are paying for their software at all, and most don't really grasp the difference between hardware and software - a dangerous, but highly profitable illusion fostered by the likes of Dell and Microsoft. The reason it is broken is because it means that you have to shell out for 'upgrades' again and again, to no one's benefit but the owners of the software companies, and not even them in the long run since it is an unstable model, which only remains working because of customers' ignorance and lack of alternatives.
Open-source is nearly as bad, economically, since there isn't any real profit to be had in it - that is, after all, the whole point. A model that depends on ego satisfaction and public standing replacing greed is only going to work if the developers have another source of income that doesn't interfere with their ability to work on the software. While it is a 'gift economy', as ESR puts it, the problem is that gift economics only work when the gifters are financially secure in other ways - the classic examples of gift economies all worked because the labor for basic necessities was done as an obligation to the feudal lord, leaving the upper echelons free to focus on 'what can I do for you' rather than 'what do I need to do for myself'. Gift economies are inherently parasitic on physical economies based on unpaid labor by individuals other than those involved in the gifting activity.
Bespoke development fails because most software is generic; truly specialized development is rare, and most 'custom' work is either a derivative of some existing open-source system where the incentive to improve it voluntarily is lacking, as an alternative to a proprietary system whose owners cannot or will not provide the needed functionality for the customer, or - and this is the most common reason - because the company wants something done in-house, for no better reason than because they can. While there is a fair amount of work done in bespoke software, the majority of it is redundant - it literally shouldn't be done in the first place, because there are existing options which are almost always better.
Finally, the subscription model is probably the one which will work in the long run, but it too is flawed - it really only is suited to very small applications where the majority of users are willing to pay a nominal fee, and where the user base is broad (there are thousands if not millions of users) but shallow (that is, most users are casual users and not dependent on the software for any real needs). It works very well with mobile apps and casual gaming, but not at all for larger mission-critical projects.
Unfortunately, there really aren't any new economic models of software development on the horizon, so we are all stuck with a broken system for the foreseeable future. Fnord.
-
Is it just me who keeps misreading the topic title as "The Home Stench" ?
Of course that is somehow even more appropriate ...
-
Open-source is nearly as bad, economically, since there isn't any real profit to be had in it - that is, after all, the whole point. A model that depends on ego satisfaction and public standing replacing greed is only going to work if the developers have another source of income that doesn't interfere with their ability to work on the software. While it is a 'gift economy', as ESR puts it, the problem is that gift economics only work when the gifters are financially secure in other ways - the classic examples of gift economies all worked because the labor for basic necessities was done as an obligation to the feudal lord, leaving the upper echelons free to focus on 'what can I do for you' rather than 'what do I need to do for myself'. Gift economies are inherently parasitic on physical economies based on unpaid labor by individuals other than those involved in the gifting activity.
That depends on whether you count the support side of things. The software itself might be free, but support usually isn't (it incurs real costs and usually has a more tightly defined schedule, so it requiring being paid for is unsurprising). OSS also usually doesn't deliver end-user software. If you think that means it is missing out on a majority of software, you've lead a very sheltered life.
In fact, reading your whole post again I think that is what you think. Wow…
-
Today is D-day. Not that any of our customers give a shit, the first one is lined up for several weeks from now. But it is very important that everything be installed, switched on and validated functional today. Why? Dunno.
Of course, we haven't had the go/no-go call yet, so we aren't allowed to touch the production boxes (which sit completely virginal without even a prereq to speak of).
The last time I set up an environment from scratch, it took 4 days.
This one is twice the size.
-
Yay, and Friday is the perfect day for that!
-
Yay, and Friday is the perfect day for that!
Friday, 3 o' clock. The witching hour for software. Where even the most heavily tested code happily breaks upon deployment!
-
OK, I'l confess, I deliberately downplayed that aspect of it, even though it could, in principle, be a source of financial security for the OSS industry. Why? Because for every open-source project with a significant paid support service, there are tens of thousands that don't. Of course, that's partially due to Sturgeon's Law at work on an exposed base of works - probably only one OSS project in a thousand gets past setting up a repo on GitHub or Sourceforge, never mind releasing a product, and while it does not reflect on the overall value of open-source software, it does make it clear that there is a lot more ambition than actual time and motivation.
But I digress. The question was, why didn't I factor in support? Because an OSS project has to already be stable and growing in use for the support base to be viable as an income source, and it has to have either a very large user base (e.g., Canonical, Cygnus when it was a separate company) or a steep pricing structure (e.g., Red Hat, Oracle's OSS projects) to make it possible to support further development, and even when it does, only a handful of core developers are sustained. The majority of OSS development is always done by the end users, whether they are a hobbyist working on GIMP or a corporate DBA running MongoDB over a Beowulf cluster. Again, that is part of the point of open source - 'with enough eyes all bugs are shallow', etc., but it is also a weakness of it - without a critical mass, no OSS project can succeed, even if it is desperately needed by some clients.
As for whether I believe all software goes to an end-user, no, not in the sense you mean. Most OSS is tool oriented - the 'end users' are themselves OSS developers, or work as developers on bespoke software which applies an OSS tool. HOWEVER, the market for any given development tool is small and self-limiting, and more importantly, few development tools are of such scale as to be able to have a viable paid support structure, unless they are part of a larger toolchain. Indeed, binutils and the related GNU tools are virtually unique in this, mainly because Red Hat covers so many different tools that they can generate a broad base.
Customer training is probably a more viable a model of payment than support, realistically speaking, but only Red Hat and ORA have made serious efforts in that direction to the best of my knowledge. I suspect that a bias against non-technical users is at work there. However, even that can only generate enough revenue for a small core team, if that.
In any case, the biggest need is for ways to support the developers in the critical months before a large enough user base have developed. They almost invariably need to work a regular paid job elsewhere first, slowing development down, or else need to turn to vulture capital, which isn't really compatible with the OSS philosophy. Kickstarter and similar crowdfunding sites are one option, but convincing enough supporters that there is a real need for your particular software to reach your funding goal is nearly impossible.
Note that I am not denigrating OSS itself; I would be thrilled to see a viable funding strategy be developed for it. I am myself struggling to get a significant OSS project off the ground myself (or rather, at this stage, a subsidiary project needed to complete the main one), but I am far from getting even a critical mass of co-developers so far, never mind finding users who will want it when it is released. I just don't see any of those which have been tried to date being really viable for more than a handful of operations.
-
Note that I am not denigrating OSS itself; I would be thrilled to see a viable funding strategy be developed for it. I am myself struggling to get a significant OSS project off the ground myself, but I am far from getting even a critical mass of co-developers so far, never mind finding users who will want it when it is released. I just don't see any of those which have been tried to date being really viable for more than a handful of operations.
It's very difficult to get a project started, to get the first tranche of funding or the critical mass of co-developers. (That's also true for non-OSS.) My recommendation is to make a first draft that does a tiny key little bit of what you want to achieve so that you can tell/sell it to others through demonstration. It's much more rewarding to work on things once you're past that key roadbump.
The next big problem is finding a true sustainability model. Again, that's very difficult, and it's very difficult for non-OSS too.
I note that you're working on (yet) a(nother) language. Here are my big hints.
- Make sure you've got a bridge into existing libraries written in another language (whether in C/C++, Java or C#; pick according to what runtime you're targeting). This saves a lot of effort during the bootstrapping of the project, no matter how impure it makes you feel.
- Get a REPL going ASAP if you're not going down the full-compilation-only route; life is much easier once you can try things out immediately.
-
Bespoke development fails because most software is generic; truly specialized development is rare, and most 'custom' work is either a derivative of some existing open-source system where the incentive to improve it voluntarily is lacking, as an alternative to a proprietary system whose owners cannot or will not provide the needed functionality for the customer, or - and this is the most common reason - because the company wants something done in-house, for no better reason than because they can. While there is a fair amount of work done in bespoke software, the majority of it is redundant - it literally shouldn't be done in the first place, because there are existing options which are almost always better.
You're making the buttumption that software only supports generic 'business' functions in a business (i.e. accounting, customer management, document management, payroll, inventory/supply management, Web frontend functions). Code that directly supports line-of-business functionality (whether it be moving financial transactions at a bank, or moving trains and sorting cars at a RR) is going to be far more specialized/limited-market, if not fully bespoke, just because so many fewer people need it. Then again, it takes quite an intelligent company to build 'bespoke' software that is generic enough that they can simply use the extensibility hooks they've built to tailor it to a customer's needs, instead of having to rewrite the package for each customer they take on.
Filed under: how many people can you sell the vital interlocking program for Kedzie to?
-
Then again, it takes quite an intelligent company to build 'bespoke' software that is generic enough that they can simply use the extensibility hooks they've built to tailor it to a customer's needs, instead of having to rewrite the package for each customer they take on.
Theoretically so. In reality, you get SAP.
-
Or PeopleSoft, or Oracle Apps or any one of those horrific abominations we (corporate employees) all have to use to submit timecards.
-
Oh god. I was trying to forget Remedy ARS. AAaaaaargh!
-
Theoretically so. In reality, you get SAP.
SAP is a problem because its trying to be all non-line-of-business things to all businesses. Same with PeopleSoft, etal.
My argument was that a semi-custom approach is generally best for line-of-business apps provided you have the brains to pull it off without creating too many WTFs along the way.
Oh god. I was trying to forget Remedy ARS. AAaaaaargh!
Also, what's with the idea that tech support should use some sort of half-butted 'ticket system' instead of something more bugtracker-ish?
-
Had the go/no go call. Going forward. It was quite awkward when I had to explain that no actually work would be hitting manufacturing as a result of the deployment (because we need customer implementations. The first of which is weeks out yet).
Apparently my managers never really got the VP to understand we truly built a platform, as opposed to a "platform".
-
Had the go/no go call. Going forward. It was quite awkward when I had to explain that no actually work would be hitting manufacturing as a result of the deployment (because we need customer implementations. The first of which is weeks out yet).
Apparently my managers never really got the VP to understand we truly built a platform, as opposed to a "platform".
Apply LART (or equivalently, clue-by-four) to Veep. Repeat until he runs for door, or you can invoke the chunky salsa rule.
-
Apparently my managers never really got the VP to understand we truly built a platform, as opposed to a "platform".
Platform as in shoes, or platform as in trains? (That is, something that you just stand on but lets you see further, or something that helps you go places.)
-
-
Prod servers have some bullshit encryption software called Entrust Groupshare.
Protip: it isn't behaving even remotely similarly to when we tested with it briefly. (And we only tested with it briefly because we can't actually encrypt the test environment because then we'd need to buy users for all 9 billion people who need fingers in test.)
-
Why? Because for every open-source project with a significant paid support service, there are tens of thousands that don't. Of course, that's partially due to Sturgeon's Law at work on an exposed base of works - probably only one OSS project in a thousand gets past setting up a repo on GitHub or Sourceforge, never mind releasing a product, and while it does not reflect on the overall value of open-source software, it does make it clear that there is a lot more ambition than actual time and motivation.
That's missing a big point about open source.
A lot of people, who actually work in industry, are willing to release tidbits of code so that other people can help maintain it. The idea is that I, as an entrepreneur, make a stupid Javascript/ruby/whatever widget for my business. And if it's generic enough, I'm willing to share that with others, because:
- If it gets any adoption at all, I'll get bug fixes for free
- If it gets any adoption at all, I've increased the utility in the world at no marginal cost.
- Goodwill, github karma.
It doesn't matter if the open source stuff doesn't get turned into a product. It's already used in a product.
-
Oh, I quite agree, but the problem I was specifically addressing was, how does one make a living as an open-source developer, or failing that, make a living that allows one to have the time and energy left over to contribute even a modest amount to a project? I know that the majority of OSS contributions are freely offered by volunteers; I am counting on that myself, if by some miracle my own projects get enough of a head of steam to keep going. I have no expectation of making a living at it myself, but of those who have tried to do so, only a handful managed to.
The real point I am making is that OSS alone can't make for a stable software industry, and the other options are, while occasionally lucrative for a time, not really any more stable either. The industry desperately needs to develop a novel model for funding and supporting itself, or else it will grind to a halt eventually.
-
The three routes are paid services (typically support), paid customisations and specific licensing deals (especially if you're GPL or similar and you have customers wanting to link your code in non GPL projects)
-
And your point is? For 90% of OSS projects, large or small, those payment mechanisms aren't an option for a stable operation, because they won't bring in a living wage for even the core team.
I repeat what I have said already: I am not critiquing OSS itself, but the pragmatics about how it is funded and operated. Ideally, it should be possible for all projects necessary for a healthy software ecosystem to have a wide enough volunteer base that the issue would never come up. That simply isn't the case, however, and most projects need at least one full-time developer and maintainer to be viable. Unless that developer is independently wealthy, they will need a source of income, and most of the time, the income models for OSS fall flat. As things are already, the majority of OSS 'funding' comes in sideways, via student grants and loans to graduate students who work on the projects as an adjunct to their thesis work, much as Linus did.
Until a new model of funding - or a way to avoid the need for it - is invented, OSS will always live in the shadow of proprietary software. I wish it were otherwise, but that's the truth.
-
So where's Atwood getting the money to build Discourse from? Is it just the hosted service he's selling?
-
So where's Atwood getting the money to build Discourse from? Is it just the hosted service he's selling?
Are you joking? You know how much VC money did Stack Overflow take? And he was like a 50% partner in that.
-
Are you joking?
No.
You know how much VC money did Stack Overflow take?
No.
And he was like a 50% partner in that.
Ok?
Now maybe want to type something that answers my question?
-
He's funding it from his own money for now. And obviously hoping to earn more by selling it as hosted platform.
https://payments.discourse.org/buy/Oh and how much VC money did Stack Exchange take? Hundreds of millions.
-
Setting aside the question of the funding for Discourse specifically for the moment, I want to express some surprise at the resistance I am seeing to the notion that our current economic models of software development are flawed. Why would we expect otherwise? New fields - and a mere sixty years is nothing in the larger scheme of things - almost always require new approaches to such matters. Claiming that the funding models for software development are mature is as absurd as suggesting that software development itself is a mature field (when in fact it won't be for at least the next five centuries - which is not unexpected, given that it is at least an order of magnitude more complex than any other form of engineering save perhaps genetics).
-
Wow, I should start my own project for my running club. I only handle the site in my own city, but there are 2-3 thousand groups around the world. I could make a killing.
-
There's probably two trains of thought.
-
"Software development will never come to a halt". They don't believe your conclusion.
-
"Software development will come to what amounts to a halt." Whether this happens or not is irrelevant to whether the economic models are efficient. Indeed, if the models are efficient, we'd expect software development to stop when it starts being useless. Discourse is proof that we are near the end.
-
-
I suspect there's something off in the reasoning, but not necessarily that this means the reasoning is wrong when applied to Discourse.
My observation is that truly long-lived software tends to be that which attracts small businesses to build on top of it. (blah blah pig committed blah blah) The key thing is that small businesses can't switch technologies easily, so if they depend on something, they're likely to be willing to pay to keep it going.
Big business, though it can deliver a lot more money, is also a much more fickle friend. (And government is effectively the very biggest of big business, at least from this perspective.)
-
Wow it works much better when you give answers instead of asking questions you assume are hypothetical, but I genuinely do not know the answer to!
EDIT: How the hell does SO make money? Just the stupid jobs page? I can tell you that ain't lucrative business.
-
They also do very targeted advertising on stackexchange, serverfault, and another one. But geeks are such a fickle bunch, I don't see that being lucrative either.
-
Wow it works much better when you give answers instead of asking questions you assume are hypothetical, but I genuinely do not know the answer to!
Looks like, at least in the past, the answer was mainly "job listings and advertising."
-
SOLVED
-
See how easy it is?
-
Wow it works much better when you give answers instead of asking questions you assume are hypothetical, but I genuinely do not know the answer to!
You could have quickly googled it up and pretended to be on top of things. But now the chance is gone and your know-it-all troll veneer is crumbling. It will never be the same again.
EDIT: How the hell does SO make money? Just the stupid jobs page? I can tell you that ain't lucrative business.
Why don't you ask Alex the TDWTF owner. He's doing their business / advertising side (at least he did a few years ago).
-
I don't think software development will come to a total halt, but I expect that the frenetic, running-in-place pace of the field will slow to a crawl for a few decades, starting some time in the next five years or so, unless dramatically new approaches to both development and funding arise.
Let me reiterate my earlier point: process engineering (to borrow a term from Hal Abelson) is still in its infancy, and will be for some time to come. While a number of approaches to developing software have been tried, they have been more speculation and dogma than real engineering. Even the two big developments of the 1990s and early 2000s, open-source development and Agile development, are less models of software creation than they are workaround to the fact that we don't have any working models of software development (and the one which was previously claimed to be the 'classic' model, Waterfall, was never an actual development model in the first place - it was really the classic strawman argument which everyone compared their 'new ideas' to - and despite many claims to the contrary was never used in practice, as it was unworkable and deliberately so).
To use a comparison I've often made, we are still at the 'mud hut' stage of the field's progress, though we have made some forays into the 'pyramid building' level at times. For a field this young, this is actually remarkable progress, but when you get down to it, pyramids, while immensely labor intensive and breathtakingly imposing, are not really all that great an engineering challenge. We might - might - reach the 'Acropolis' level sometime in our lifetimes, but I am certain that the 'Roman aquaduct' level is a few (human) generations away, never mind the 'Gothic Cathedral' stage. Real process engineering is far of over the horizon and will remain so in your great-great-great-grandchildren's lifetimes (I say 'your' because I have no expectation of having any children, and depending on some decisions I may make in the next few years, will probably be unable to relatively soon).
This shouldn't surprise anyone. Process engineering is the second most difficult field known to humanity (the most difficult is Psychology, which is about five millennia from being a real science). Expecting that we can master it in such a short time is simply unrealistic.
-
You could have quickly googled it up and pretended to be on top of things.
A lot of blakey's problem with understanding shit seems to stem from an ongoing failure to Google.
-
We are quickly getting to the point where there are more "solutions" than actual problems, when it was the opposite in the past.
-
He likes his ideas to just Bing.
-
To use a comparison I've often made, we are still at the 'mud hut' stage of the field's progress, though we have made some forays into the 'pyramid building' level at times.
Well, part of the problem with your analogy is that it grossly mischaracterises the costs. Right now, for many engineering fields it is the cost of production that dominate; the costs of the prototype are small by comparison. With software engineering, the costs of production (i.e., of making a copy of the prototype) are minuscule, so much so that they are functionally free, and so the costs of the prototype completely dominate. When combined with the widespread ability to patch things up in the field for reasonable cost, the traditional engineering approaches end up looking exceptionally slow and costly.
Weird stuff happens when a technology sets certain multipliers to zero. ;-)
The big change of the past quarter century has been the switch to componentization of software, from making it all yourself to massive reuse of others pre-packaged systems (libraries, frameworks, VM images, etc.) Though there was some of that back when I started programming (and much serious debate about how to encourage far more code reuse), it was as nothing to now. It's like the switch from artisan-based smithing to using machine-tooled standard parts.
Having higher level tools lets you tackle higher level problems.
-
Reminds me of waaaaay back when I was in school, a classmate told me that his aunt had a disk of all the code that she liked to reuse, it was a lot of her work that she used in all of her project. Man, how times have changed.
-
So. Let's say you're evaluating compatability with a disk encryption product.
Using an interactive interface (i.e. Explorer) you create some shit, delete some shit, move some shit around, and everything works great.
And then you run a bunch of automated tests that do much the same things.
And then it turns out, after you actually install software on top of it that Directory.CreateDirectory() creates directory entries that don't have any fucking NTFS permissions (like they are LITERALLY missing - can't view, edit, take ownership, ANYTHING. Because the permissions metadata just isn't fucking there. If you want to delete anything you need to run fucking Checkdisk, which creates the appropriate metadata). The directory was created, so it passes the "Is there a directory there?" test script, but you kind of took for granted that the fucking directory would be usable because IT'S A BASIC FILESYSTEM FUNCTION.
Are you at fault for not checking, or is the vendor at fault for writing a piece of garbage that borks the filesystem?
While we're at it, lets say you're an enterprise IT security goon. The network share encryption product you have on the approved list is supported by a barebones IP holding company, has no night and weekend support, and is being withdrawn from the market. It is however, quite inexpensive. All 3 implementations of it have encountered some sort of problem. The nearest competitor is a reassuringly expensive IBM product. It ain't your budget that has to pay for it. Which one do you require they use?
-
If you want to delete anything you need to run fucking Checkdisk, which creates the appropriate metadata
That's pretty impressive--something extraordinary must be required to prevent standard perms.
Takeown+icacls probably would've fixed it, though.
-
Nope. takeown even failed. Can't recall the error, I'll grab the details on Tuesday when I can actually get the vendor on the phone.
This product also borks filesystem transactions. Bunch of Windows services involved in the Application Server and IIS roles won't start. So you have to do a registry tweak to tell it not to intercept filesystem calls to the C drive (yes, even on servers that are client-only without any locally stored encrypted data). From what I can tell, it was designed at best to be used by interactive users sharing an adhoc fileserver.
-
Nope. takeown even failed.
Well, like I said, that's pretty impressive. What's this product, so I can avoid it?
-
Don't want to namedrop them (a second time) until this storm blows over. Googling them and looking for people having problems reveals disturbingly few issues. Don't want this popping to the top of the results for obvious reasons.
LMGTFY - Let Me Google That For You
