Creating and Selling Software Tools based on Tiddlywiki

[Mohammad]

1. Do you think Tiddlywiki is enough mature to create applications (Apps) based on it for commercial use cases?
2. Do you think it is possible to sell such applications  for commercial use cases (not for academic or individuals)?

[TonyM]

1. Yes, however building a set of tools and practices to support rapid and structured development is nessasary, it would also help to reduce maintenance costs later.
2. Yes, at least directly to the customer but not as shrink wrapped software yet in my view, however I don't think that is too far away.

There are great plusses to building solutions on open source, but not everyone understands the benefits or obligations.

Regards
Tony

[Mat]

Interesting question.

I'd guess "Yes" but then you'd have to come up with applications that are implementable with TW. My point is that modern applications are quite sophisticated in what they do (...multi user, login in via facebook account, "does it work with our intranet?", etc etc).

Of course, Jeremy does use TW as commercial applications (...as far as I know) but my guess - not based on anything - is that they're tweaked quite a bit to suit the customer. The only example I know of is the Ambit project (unsure of url for their tiddlywiki).

<:-)

[@TiddlyTweeter]

Mohammad

Yes. Absolutely.

But the "product" on sale is not off-the-shelf software. Its a software framework that a developer sells and develps into a context for a purpose.

That is exactly what Jeremy did and does. 

So in a way your question is misleading, as if it were now "mature enough", as if it wasn't before. 

In fact, its commercial application and development (for instance for British Telecom in the past) has fed back and helped the develpment of the free version.

TBH, I don't think the issue is "maturity of product" at all. The maturity is well there. 

Its more normal commercial things like: What is my market? Who am I selling to whom for what? 

In other words about PEOPLE who would know how to leverage it for commercial aims. Jeremy is one of them.

Best wishes

Josiah

[@TiddlyTweeter]

Ciao Mohammad again ...

Its a very interesting topic.

I was trying to think out a very simple way of presenting the issue ...

•  I do think its about people. 

Being able to identify and develop markets is not the same thing as being a good coder.

So maybe the question could be: What are the market needs where TW PLUS a good developer could solve real world problems?

Best wishes

Josiah

[@TiddlyTweeter]

TonyM wrote:

   ... There are great plusses to building solutions on open source ...

Absolutely true. 

If one looks at the real history of TW its been a back-n-forth fruitful confluence between commerce and open-source.

I doubt Jeremey could ever have done it otherwise. I mean, who'd pay for his work?

Best wishes

Josiah 

[@TiddlyTweeter]

Ciao TonyM

TonyM wrote:

1. ... however building a set of tools and practices to support rapid and structured development is nessasary, it would also help to reduce maintenance costs later.

I'm not sure about that in one way. And I think its worth saying.

What I mean, is you refer to the tools not the person making them for their purpose. 

TW is an animal that can live a thousand ways so my, feeling, maybe wrong, is that YOU (the person) have a vision, know it, and pursue it in the context of your practice. I think that is very healthy. 

But I'm a bit doubtful it will generalise because I'm not sure what a generic "structured development" for TW could be other than what it is already. Which is so open to possibles its a kinda endless mess of diverse intent. There is nothing wrong with that. 

But its bricolage, not Henry Ford.

In brief: commercial gains, I think, come from matching ones skills to markets for whom YOU develop structure.

Just thoughts

Josiah

[passingby]

Hello Mohammed,

Disclaimer: I am not a programmer, and have no experience from real world pov. 

Maybe we need some advanced tools like:

1. An advanced plugin which will turn TW into a RAD environment for CRUD applications. Easily customization of forms for entering, editing data. Displaying data in tables, graphs, pie charts etc.

2. Easy integration of CSS and javascript libraries

3. Advanced SQL like capabilities for complex data situation in multi level parent child relationships.

4. easy Spreadsheet functions in tables.

5. Pagination

2. Better integration or connecting with other platforms out there such as social media.

[Jeremy Ruston]

Hi Mohammad

1. Do you think Tiddlywiki is enough mature to create applications (Apps) based on it for commercial use cases?

Yes. For the last three or four years I’ve been supporting myself by performing custom TiddlyWiki development on a commercial basis through Federatial (https://federatial.com/).

I suspect the maturity of TiddlyWiki is indeed a factor in its credibility for clients.

2. Do you think it is possible to sell such applications  for commercial use cases (not for academic or individuals)?

In the traditional shrink wrapped, off-the-shelf software sense, I think such a business can only be sustainable if the product is targeted at an incredibly tight niche, and carefully solves all the needs of those users. So, it seems to be possible to make money selling software to, say, orthodontists in western europe, but very hard to sell something as generic as “note-taking software”. Hence the travails of Evernote.

I think that the primary opportunity that TiddlyWiki offers us all is pretty good: to sell our time customising it for those customers that are able to pay, but to collectively keep the value that we create so that it benefits everyone. The clients get the benefit of getting software that does exactly what they want, with no fiddling about, and the community benefits from the increasing capabilities of the platform that we share.

Best wishes

Jeremy

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/578ff2ca-0716-4385-99e4-3e20db92ad3b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[TonyM]

Jeremy,

I am committing to tiddlywiki to support my consulting services, building a wiki for a client and looking forward to future applications and solutions. As you suggest this drives my passion and contribution to community and as my tiddlywiki5 maturity grows I will pass more back into the community and development.

I like virtuos circles.

While tiddlywiki aims to be valuable to the casual user and a wide user base it is very extensible people who want to do it themself can. But I believe there are a lot of people who want someone to do it for them. Those who want to service others needs, with tiddlywiki will benefit from an open forum and are both obliged and will benefit from sharing back and where appropriate into development.

I believe we have desktop and server implementations mostly there. Progress is being made on mobile but we need a white label method to package tiddlywiki into native apps that can be sold in app stores.

In Australia we have a shortage of applications developers and app development providers are too far from the needs.

And thanks once again Jeremy for starting this delightful journey.

Regards
Tony

[TonyM]

Post Script

If we an get tiddlywiki to obey Progressive Web App standards we will be on a winner for distribution and saving.

Regards

Tony

[Mark S.]

A vertical market application for the desktop is unlikely. But I can imagine a wrapper kit for Android that would allow any mobile-themed

TW to be turned into an application. The problem is, there are just so many apps already.

But if some small family business wanted to make an a Menu app for their Falafel and Pizza shop, that might be the ticket. 

[Mat]

Announcing TiddlyWiki365! It features: an editor for tiddlers, it can calculate a number, it can present one tiddler after the other.

This will revolutionize the corporate world!

<:-)

[passingby]

Something like data entry for small business, which can be export data to quickbooks might be an option. This might prove attractive to the small business owner/operator by saving monthly costs for bookkeeping. They can periodically export for emailing the file to their accountant.

[Jed Carty]

I made some tools to track expense reports and make invoices that can be nicely sorted and spit out weekly/monthly/yearly reports.

[@TiddlyTweeter]

Mark S. wrote:

... I can imagine a wrapper kit for Android that would allow any mobile-themed TW to be turned into an application.

The problem is, there are just so many apps already. 

I think that astute. 

Its true Android is a swamp of apps. But TW is particularly strong on flexibility of function. And Android users are not looking for bells and whistles, but much narrower functions than weighty desktop software, I think. 

I suspect in the hands of someone who understands Android usage turning out TW's with simple functions could work well.

Anyway, as far as "shrink-wrapped" goes, Android looks like a possible market, despite competition. 

But its a "penny economy". Your app needs thousands of users to afford to maintain it.

Best wishes

Josiah

[@TiddlyTweeter]

Mat wrote:

Announcing TiddlyWiki365! It features: an editor for tiddlers, it can calculate a number, it can present one tiddler after the other.

This will revolutionize the corporate world!

I take that with a pinch of salt :-) 

[@TiddlyTweeter]

Mark S. wrote:

... I can imagine a wrapper kit for Android that would allow any mobile-themed TW to be turned into an application.

The problem is, there are just so many apps already. 

I got to thinking about "Quinoid". Its an example of "enabling software." A wrapper for TW that can give added functions and could potentially be expanded

Its, I think, a good example of where the money may be. 

FWIW, amongst the most profitable businesses in the mobile phone sector are the companies who manufacture the boxes for phones.

I'm NOT suggesting Quidoid is that, But its an example of you "need a wrapper" for best presentation. You need Quidoid + the App(s). That's a product.

Thoughts

Josiah

[TonyM]

Folks,

Can I respectfully suggest Once we have the software platform and the distribution mechanisms in place all that remains is imagination. I have dozens, if not hundreds of ideas for apps and solutions.

Quinoid and Tiddloid are great "wrappers" of tiddlywiki, but they list one or more wikis and they need a wiki installed. This is perfect for TiddlyWiki enthusiasts. It is not what we want for application deployment everytime. Mobiles apps often fit a defined need, this need should be reflected in the name/icon so it is simple to click when needed. A way to package a single wiki (Progressive Wed app is one way), users do not need to know the back story, they need to know what it does, but this will be acknowledged in the apps.

I think the current lack of applicability of mobile apps to desktop apps and visa versa is not due to a lack of user need but a lack of imagination or capabilities of the app developers. who would not like to capture ideas for their book on their phone then write a chapter on their desktop or tablet?

If you design a good app, and sell it for a few dollars, if that is popular you can start a business. For get the swamp, make a mangrove tree.

It is also the period in time where businesses not only need a website but need an app or they do not exist in many peoples mind. Similarly people "understand" apps now they are learning what to ask for in an app, and even bespoke needs can be catered for. Far too often an app solution is hidden in indecipherable code so if you commission one you have to return to the original developer or get a new one, TiddlyWiki allows them not to trust the developer, because they can resort to open source code fixes, curiously they trust developers more who offer them this flexibility.

If you do not know what is behind the PWA or Progressive Web App I urge you to find out. It is possibly the most important recent trend and defines what people will expect.

If you ask me TiddlyWiki was born to succeed in this.

Progressive web applications (PWAs) are a type of mobile app delivered through the web, built using common web technologies including HTML, CSS and JavaScript. They are intended to work on any platform that uses a standards-compliant browser. Functionality includes working offline, push notifications, and device hardware access, enabling creating user experiences similar to native applications on mobile devices. Since they are a type of webpage or website known as a web application, there is no requirement for developers or users to install the web apps via digital distribution systems like Apple App Store or Google Play.

While web applications have been available for mobile devices for as long as mobile devices have existed, they had generally lagged behind native apps in terms of speed, features, and user adoption, especially on mobile devices. Direct access to hardware and the ability to work offline, previously only available to native apps, allows PWAs to perform much faster and to provide more features in line with native apps.

PWAs do not require separate bundling or distribution. Publication of a progressive web app is as it would be for any other web page. PWAs work in any browser, but "app-like" features such as being independent of connectivity, install to home screen and push messaging depend on browser support. As of April 2018, those features are supported to varying degrees by the Microsoft Edge, Google Chrome, Mozilla Firefox and Apple Safari browsers, but more browsers may support the features needed in the future.^[1][2]

Regards

Tony

[Jed Carty]

I am a bit lost about what we would gain by adding the parts of a progressive web app as defined on wikipedia to what already exists with tiddlywiki. 

Progressive enhancement doesn't fit very well with tiddlywiki as the framework for the wiki has to be loaded before content can be displayed, 

responsiveness is already part of tiddlywiki even if it could be improved, 

tiddlywiki has always been connectivity independent, in fact adding service workers would make it more complex and I don't see what they would add

applike is already true, fresh is a concept that assumes that there is a remote server providing updates and doesn't really apply to tiddlywiki

Tiddlywiki is independent of the mechanism used to read it, so the safe component is part of the server used and you can't set https as a universal component of tiddlywiki, and it has no real meaning when you are using a local file

Discoverable doesn't have much meaning for a local application like tiddlywiki

Re-engagable is something that will result in a rather long rant from me about the relationship between people and technology and privacy. The short bit is that in my opinion push notifications are one of the worst parts of the current iteration of the internet. Also tiddlywiki doesn't have events that would use push notifications without some significant changes and a server implementation beyond what currently exists.

Installable already fits

linkable doesn't have meaning if it is a local file, otherwise it is already true.

So everything in that list is either already part of tiddlywiki or doesn't apply to tiddlywiki as the core wiki. I don't know what benefit we would be getting by adopting 're-engagable' as part of the core with push notifications other than me forking the project to remove push notifications. The same for service workers, there is no reason to make tiddlywiki dependent on a remote server and that would just put limits on it.

[Jeremy Ruston]

I fear the discussion has slightly been sidetracked into gnarly technical considerations, but it’s hard not to take the bait!

Personally, it’s pretty clear that PWAs are not a universal panacea for TiddlyWiki. Everything about them is designed to work as a cache for an online service, with some limited and crazy support for going offline. So they could have a role with an online TW5 service like Xememex, but don’t help the single file configuration. As I have to say regularly, there’s no way on earth I would commit anything important to browser local storage, nor could I in all good conscience recommend it to anyone else.

I don’t think the heart of it is even a technology problem. It’s a much deeper philosophical question. In the deepest possible sense, TiddlyWiki is the way that it is because of the context in which it was built and used. It is designed from the ground up as an open source application trying to accommodate the needs of hundreds of thousands of diverse users. Almost every decision I’ve ever taken about TiddlyWiki’s development would have been completely different had I been working on a commercial shrink wrapped product.

What I’m trying to say is that the technology and the business model of TiddlyWiki are intimately intertwined. Change the business model too much and suddenly many of those technology choices become liabilities.

For example, TiddlyWiki allows deep customisation by end users, down to adding new JavaScript modules. The only way to get that level of customisation on a commercial service would be to buy a low level service like a virtual machine, and run something like TiddlyWiki within it. For a business model like, say, Evernote’s it is completely impractical to offer that level of customisation while taking care of security and keeping support costs reasonable.

I can and do imagine building a shrink wrapped, mass-market product that did what TiddlyWiki does, but I’m pretty confident that it’s not possible to turn TiddlyWiki 5 into that product in any direct way.

So, that’s why I’m so keen to focus on the opportunities presented by the architecture we have now, and the investments we’ve made in it to date. In particular, TiddlyWiki 5 has shown how people who are not conventional software developers can create intricate custom applications that meet the needs of arbitrarily specific niches.

Best wishes

Jeremy

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/00c864c9-185a-40a1-9613-6e3860034e46%40googlegroups.com.

[passingby]

Out of the many plus points of tiddlywiki, I want to point out these:

1. Subscription based software: Everything today has become greedier than before. Every software out there is subscription based now. If I have to use MS Office I pay around a CAD 100 and this when I am not even using it for business.

2. Data with corporations: One not only buys the service but hands over the data

Now there is a Tiddlywiki developer. You pay him, he hacks out a solution for you. One time fee. You keep the app. If you wish you can hack it yourself but if you want a professional job you pay a one time fee to a developer.  

There should be a market for this in small business sector. Especially in context of monthly subscriptions which a small business takes on.

On Thursday, July 4, 2019 at 4:36:43 AM UTC-7, Mohammad wrote:

[Mohammad]

Thank you all for your time and useful points!

It seems the conclusion by now is

Sell your time, it is hard if not impossible to sell TW based apps.

Best

Mohammad

[TonyM]

Folks,

Jeremy and Jed specifically. When I mentioned Progressive WebAps, I think you took me too literally, perhaps that comes with the territory from coders.. My point is there is an expectation building and tiddlywiki is already well setup to respond to these expectations. Here are the key functionalities and I would find it hard to imagine you think any of these are not worthy aims.

I must say I am nervous speaking my mind here, but please consider what I am saying with the generosity in which it is offered. I may just have something worth listening to.

When I mentioned PWA's it is with a view to capabilities for example;

• Progressive — Works for every user, regardless of browser choice,
• Responsive — Fits any form factor: desktop, mobile, tablet, or forms yet to emerge.
• Connectivity independent — Service workers are one way but we do not need them do we? allow offline uses, or on low quality networks. But there are uses out there for which we have methods such as using servers, and tiddlywiki naturally uses the browser cache, and offline works.
• App-like — Feels like an app to the user with app-style interactions and navigation.
• Fresh — Always up-to-date (this is a designers choice) and less important when we do not use a server backend, or a continuous deployment method. 
• Safe — Served via HTTPS to prevent snooping and ensure content hasn't been tampered with.
• Discoverable — Identifiable as an “application” by manifest.json^[13] and service worker registration (if it necessary?), and discoverable by search engines (good idea if it means can be appified, optional extra)
• Re-engageable — Ability to use push notifications to maintain engagement with the user. Nice optional extra can be implemented via various means 
• Installable — Provides homescreen icons without the use of an App Store. Important in today's world.
• Linkable — Can easily be shared via a URL, and does not require complex installation. Almost there except for savers, would if we adopted the approach.

On the subject of Local Storage, I do not care what the technology is called, we need to allow people to obtain this with the minimum effort. The current best method for me is Using Timimi and saving files, but since there is an increasing dependency on locally stored content, I am sure the solutions either are, or will be there for persistence even if there is a interactive step that demands authority to do so. Even just an easy install node package effectively grants this persistence, not to mention tiddlyserver, desktop and Bob, and we can move between folder and file versions.

Personally, it’s pretty clear that PWAs are not a universal panacea for TiddlyWiki. Everything about them is designed to work as a cache for an online service, with some limited and crazy support for going offline. So they could have a role with an online TW5 service like Xememex, but don’t help the single file configuration. As I have to say regularly, there’s no way on earth I would commit anything important to browser local storage, nor could I in all good conscience recommend it to anyone else.

I not sure anyone, especially me suggested it was a universal panacea for TiddlyWiki but we do depend on the computers local storage. You may have good reason not to trust this mechanism but surely if we find an effective solution all the better. Imagine for example, just to propose and exception, we packaged a Pouch DB server for every OS and the ability to point any wiki to a named database, whilst also able to export to a single file. This would provide a reliable and persistent "local storage", one that could be connected to from any wiki at any url if desired.

 

I don’t think the heart of it is even a technology problem. It’s a much deeper philosophical question. In the deepest possible sense, TiddlyWiki is the way that it is because of the context in which it was built and used. It is designed from the ground up as an open source application trying to accommodate the needs of hundreds of thousands of diverse users. Almost every decision I’ve ever taken about TiddlyWiki’s development would have been completely different had I been working on a commercial shrink wrapped product.

On this I agree, I am not contesting this, and that is what we should stick to. 

 

What I’m trying to say is that the technology and the business model of TiddlyWiki are intimately intertwined. Change the business model too much and suddenly many of those technology choices become liabilities.

I agree and do not suggest anything differently, You continue to maintain this and make the technology choices. What I am talking about is the capabilities, addition not subtraction.

 

For example, TiddlyWiki allows deep customisation by end users, down to adding new JavaScript modules. The only way to get that level of customisation on a commercial service would be to buy a low level service like a virtual machine, and run something like TiddlyWiki within it. For a business model like, say, Evernote’s it is completely impractical to offer that level of customisation while taking care of security and keeping support costs reasonable.

Keep, keep, keep, Allow easy distribution of TiddlyWiki solutions, no business model changes proposed.

 

I can and do imagine building a shrink wrapped, mass-market product that did what TiddlyWiki does, but I’m pretty confident that it’s not possible to turn TiddlyWiki 5 into that product in any direct way.

I can see a solution being popular, just as amongst many Tiddlywiki itself is, But consider TiddlyShow, Cardio etc... if there was reduced barriers to discovery and adoption they could find themselves in a mass-market.

 

So, that’s why I’m so keen to focus on the opportunities presented by the architecture we have now, and the investments we’ve made in it to date. In particular, TiddlyWiki 5 has shown how people who are not conventional software developers can create intricate custom applications that meet the needs of arbitrarily specific niches.

Of course. But you do realise it is hard to address a niche within another niche, At present if I have a niche solution, I must persuade people into the tiddlywiki niche environment first, If I could provide a niche solution to someone that they could acquire simply, they would use the niche solution (based on tiddlywiki) to meet their needs, then develop their understanding and need for TiddlyWIki.

I respect the whole communities contributions, and Jeremy, Jed and Mario in particular their technical know how deliver so much, you and others are the "holders of the flame", and I want this to continue, but I must ask you think a little more progressively (pun Intended). It is those close to you, who need the most latitude in speaking to your power and expertise on Tiddlywiki, because those with some distance, simply choose another solution and we never hear from them.

I have developed a simple yet effective Evaluation or decision making tool on top of TiddlyWiki why should it not become popular in an app store?

Yours Sincerely

Tony

[Jed Carty]

Tony,

Which of those things (which I addressed in my previous post) is both 1) not already part of tiddlywiki and 2) something that would be done in the tiddlywiki core?

What is preventing your evaluation app from being successful in an App Store?

As an aside:

localStorage that we have been talking about isn't persistent memory on a device, it is a specific browser technology that can be used for temporary caching. It can be cleared or overwritten at any time and is explicitly not for persistent data. Saving to localstorage will not work as a saving solution. This is completely different from what the node-based servers (including Bob) use. The two things have absolutely nothing to do with each other. Progressive web apps explicitly list localstorange, which is, as noted before, explicitly temporary caching used by browsers to hold temporary information. They have no special access to the file system aside from the very limited access provided by the browsers that we currently have and solve none of the problems tiddlywiki has with saving.

[TonyM]

Jed

With respect I wonder if you read my last post. I go to lengths to separate my comments from the PWA standard, I demonstrate I understand your perspective on local storage. Please try and read my words with generosity not just to prove me wrong.

Tony

[Jed Carty]

I am not trying to prove you wrong, I am asking what on the list is actionable. I don't see anything on your list that is both not implemented and doable within the framework of tiddlywiki.

If you are asking for features than we need to have a clear understanding of what those features are in order to do anything about implementing them. As it is I think that I am missing some fundamental part of what you are describing.

[TonyM]

Jed,

Then I am curious why you are not celebrating with me that there is nothing on my "list that is both not implemented and do able within the framework of tiddlywiki."

I believe, I did state clearly a range of features that we need. If you look into what I have said for example, you will see that If we can develop a manifest below that will enable tiddlywiki install to devices, we can leverage the universal install possibilities to mobile and desktop. If we can Get tiddlywiki to operate just as PWA's operate but under our terms, even without compliance we may have a better alternative.   

I am happy to develop the details more to generate actions but my first step was to point out this is where the technology is going and TiddlyWiki is in a great place to respond. It did not feel I had any supporters, only critics.

Regards

Tony

Manifest

The web app manifest is a W3C specification defining a JSON-based manifest (usually labelled manifest.json)^[13] to provide developers a centralized place to put metadata associated with a web application including:

• The name of the web application
• Links to the web app icons or image objects
• The preferred URL to launch or open the web app
• The web app configuration data
• Default orientation of the web app
• The option to set the display mode, e.g. full screen

This metadata is crucial for an app to be added to a home screen or otherwise listed alongside native apps.

[Jed Carty]

I think that this points to some fundamental philosophical disagreements about what we are trying to make with tiddlywiki that would take up more space than is appropriate here.