Attracting more attention to the LedgerSMB project: chicken and egg

Hi all,

The core committers were (unintentionally) having a discussion in private which we feel should have been on the public mailing list all along.

The subject of the discussion is drawing more attention to the project. Being discussed is how to get this attention, but even more importantly, *when* to get it and which message to get across.

On Sun, Jun 28, 2015 at 6:14 PM, John Locke <..hidden..> wrote:

On 06/28/2015 02:27 AM, Erik Huelsmann wrote:

... but one thing I would suggest we do is get more publicity about the project, at least some, before a major crowdfunding effort [gets started].

>
> And that could lead to a lot more users banging on the project, hitting a lot more of the bugs/rough edges that otherwise need a lot of help.

While I agree that we need to get a lot more attention to our project, the timing for drawing that attention is vital: drawing attention when the software isn't in a great or even good state, has the potential to back-fire. The result will then be that people don't want to use the software and with the damage done, aren't likely to try any time soon again.

I think that's a segmenting issue though to some extent. It affects our pitch. We should say who we are good at helping, and be willing to admit where the problems are. I think right now part of the problem is we don't have a firm enough idea.

Agreed that we don't have a firm enough idea. To that extent, we can't really blame those who try to use the software without a good match (and get disappointed), because they probably didn't get the right message. (And yes, to some extent, there will always be disappointed users.)

Yes, I think this is a very tricky issue -- drawing attention to the project at the right time, with the right expectations in place.

I don't really have much to offer here -- the people on my team touching the bookkeeping systems all have complaints, so it makes me not that confident in promoting heavily until the experience is much better -- but putting all that on the two of you seems to be a lot, we could use more hands if they fit in well...

Absolutely agreed in the sense that there's a lot to be done and that more hands will help realise that faster. But as you point out: existing users have one too many complaints about the system as it is. That doesn't mean we're not getting any new users, but we're probably not gaining wider use as fast as we want to, or as fast as we would have been able to if our UI was working better.

My idea to address this point is to invest in two things:

(1) documentation to help those who want to help out [coding, testing, anything really] up to speed in our sources, procedures, processes and design [so people feel confident to take the first step]

(2) fixing the most immediate problems which prevent people from satisfactorily using the existing and most vital functionalities

> So I would think the place to start is FLOSS Weekly, a podcast that highlights/interviews one project each week. I think that alone would get the project on a lot more open source people's radar. (And the main host, Randall Schwartz, will be very tickled to have a Perl-based project to highlight!)

That's a vey good point. So as soon as we are in a state that we can convincingly sell the world, we should definitely go down that path. However: are we in a state that we can sell ourselves to the world?

Peersonally, I think 'master' is in a better shape (UI experience-wise) than 1.4 can ever be and 1.4 - although technically an improvement over 1.3 - is a regression in UI experience: in 1.3 when a form submission failed, one could simply "back-button" to the previous page; in 1.4 - due to Dojo's page rewriting - this still looses all entered data. This regression has been solved in 1.5 by presenting errors as popups over the entered data.

What needs to be done to get into that state in your view?

I think there are a few things people expect for good usability:

1. Errors get checked and reported asynchronously (keeping data in tact)

2. The application should "look nice"

3. The application should work with minimal configuration or difficulty

4. For accounting applications, people expect to be able to load their bank records, not only for reconciliation, but also for automatic posting

This list looks very appropriate. I would add:

5. Fix entirely crappy existing workflows (batch locks, reconciliation)

We don't do (1) at all on 1.4 [because submitting and getting an error looses data]; we did better in 1.3, because the back-button would get you your data back. In 'master'/1.5, this is supposed to be fixed.

Does using 1.5 require any back-end changes? Is it possible to switch back and forth from 1.4 to 1.5, or is that a 1-way trip?

I'm not 100% sure, but I think there are currently no irreversable schema changes yet. Earlier today, I discussed this with Chris and we'll set up a 1.5/master demo next to the 1.3 and 1.4 demos we already have in place. That might be a good way to get some feedback on the track we're on now.

With respect to (2) things have improved a lot in 1.4 by using the Dojo theme and I think they even improved further in 1.5 by using more dojo components all around.

As for (3), it's my experience that Starman gets us a long way both for quickly getting started/evaluation purposes as well as having a simple Apache setup. However, at this point, we have little to no documentation on how to get it to work. What would be required to fully satisfy this point, I'm thinking about these functionalities:

* Create an 'install.pl' web interface which checks prerequisites and reports missing ones [and what to do to add them to the system and which functionalities fail to work without them]

* Extend setup.pl to provide seamless integration with install.pl and make it an integrated user experience so that once the system (OS) setup is acceptable, we proceed to create a company and help the user to get a minimal setup for System->Defaults, to prevent hitting errors the first time he/she opens the invoice entry screen; maybe add a configuration guide to the mix? (people simply don't get what all these parts of the system do, and I don't blame them)

* Create instructions to install LedgerSMB on Debian/Ubuntu and Fedora -- if we want to support Windows, provide instructions for that, or officially declare it dead
I'd be willing to create an "official" Docker image, which could greatly help this. Would need to get #1297 and #1302 fixed for this -- make sure all templates are in the database, not requiring you to edit files on the disk. And would also need to work out what variables to support in container startup (mainly local printing config, anything that might need to change in ledgersmb.conf).

But a big benefit of this approach is that a Dockerfile becomes a very clear recipe for installing all dependencies that can tie directly to our documentation for a regular install. (I would probably do the install on a Debian Jessie base image).

This could make installation a 2-line process:

> docker run --name=postgres -e -e POSTGRES_PASSWORD=mysecretpassword -d postgres
> docker run --name=ledgersmb --link postgres:postgres -p 80:5000 -d ledgersmb

... that would create a new Postgres database container, set the Postgres password, create a new LedgerSMB container, link it to the Postgres container, start Starman, and connect it to port 80 on the host machine, pulling the container images from the official repositories for each project.

That sounds like a huge step forward. It's definitely one of the things that users are currently fail to deal with correctly, dismissing LedgerSMB as an alternative, because they fail to install and thus evaluate it.

[ snip ]

We are still hitting more bugs in Starman than running directly under Apache -- will try to capture more of those to report.

Please do! I'm running all my development with 1.5/master under starman and have not seen any issues that I didn't have under Apache, so, please do keep them coming!

And (4) is a long-standing problem too. What I mean by that is: it's all too easy for technical consultants to get reconciliation working, but the majority of our users don't have a technical consultant available when they try out the application. What's more: people simply want to upload the bank transactions and either match them with system transactions *or* have unmatched transactions turned into (matched) postings then and there. This functionality is completely absent right now. What would make LedgerSMB even more appealing is if we could process/match transactions which don't have the same amounts, posting the amount differences as banking cost or leniency/discount (do you want to go after the last 30 cents entered incorrectly by your customer?).
+1. Yes, this is the biggest "missing feature" by far -- I don't even want automatic reconciliation, I really want automatic upload of bank transactions, so that reconciliation is easy.

Right. My point is - but I think we mean the same thing - that one needs to write a (5-line) script for bank uploads to work: all of the machinery is there, but it needs coding instead configury to work. This is a very weak point since many alternatives (commercial cloud hosted alternatives, that is) come with bank imports out of the box.

The reconciliation workflow is another area that is far worse in 1.4 than it was in 1.3 -- in 1.3, if you were missing some transactions, you could add them in a different browser window and "update" to pick up everything changed. In 1.4, you have to start an entirely new reconciliation to pick up changed transactions -- even re-opening already started reconciliations won't let pick up anything added.

I know you've been complaining about this issue, but in defense of the current situation: Chris looked at this problem (even recently again), but isn't able to reproduce. Could you please get into contact with Chris (or me) off-list so we can determine a precise reproduction recipe? We want to close this item rather sooner than later.

And another really broken workflow -- the "Batch lock" functionality causes more harm than it helps. Once you've printed any checks or received any payments through Cash -> Vouchers -> Receipts/Payments, you cannot add anything further to that batch, regardless of whether you go to the transaction approval screen or not. Each batch is a single pass -- and it breaks at the worst possible time. E.g., open a "daily check printing batch", print a few checks. Re-open batch to do some more, enter check numbers, print, get to the approval page, and save. Error! Batch is locked. Uh, oh, you already put the checks in envelopes, now what checks did I print? I need to go back and create a whole new batch, find the starting check number, remember exactly which checks I printed, and save again.

And the "unlock batch" on the transaction approval appears to have no effect whatsoever -- the batch immediately locks again before you can do anything.

Ok. Haven't looked at this one yet. I know you mentioned it before, but I see it's not in the ticket tracker. I've just added it as https://sourceforge.net/p/ledger-smb/bugs/1377/

> That would be a good venue to discuss the fund-raising effort, and any other kind of help we might be looking to recruit.

Agreeed. So, lets forget about my previous point and assume that we're successful at attracting new users and contributors. How do they know where and how to contribute? Are we ready to start accepting new contributors? Do we have the capacity to start helping them out so as to prevent their contributions ending in deception?

I guess the first question is who are the contributors we want to attract.

That's a good point. I really have no idea; in the sense that I think it's easier to learn the coding part than it is to learn the accounting part. For now - without any kind of automated UI testing - I'd already be happy if someone just wanted to contribute manual testing capacity.

Do we want seasoned developers? People who are learning the field? Both? These are likely to have different needs. I am already offering one apprenticeship and would be open to others, but for other developers, maybe they start off at a different level.

Right. More seasoned developers are more likely to start contributing as part of their own needs, if there's enough documentation and structure to point them in the right direction. A question that's now popping up in my mind is whether we want the effect of a pitch want to be to explicitly attract new developers, or that we want to have a structure which facilitates for seasoned developers to start contributing; like a document which helps them find their way.

I'm thinking that by saying we have large parts of the code base that need to be rewrittten, we're not really inviting people to come and join in; rather, they may be waiting for us to complete the rewrites required and *then* start to contribute. However, if we're able to say what we want the new structure to look like, which functionalities should be there and which processes should be supported, then maybe experienced developers looking for a challenge would be willing to take on part of the work here?
Totally agreed. Looks like this is started in the "Development" section on the website, under Community -- I'm thinking we should add a link to this in the "Contributor" menu, and flesh this out as you've described...

Would be great to start by calling out some of the areas we expect people to develop for custom use:

* Custom tax modules
* Writing a reconciliation import module

Ok. I wrote one of these for my own use (CSV). I can certainly write the document to detail the recon import module requirements and example code.

* Payroll

[Chris writes:]

I would like to also suggest that we may want to at some point start up a ledgersmb-masters list or something where people who have become firmly planted in the community can share business updates, projects, and so forth, and recruit help on things. That could be a way of offering mutual support on a more formal level than we have now. Until we have more real players in the market, I think we can keep these discussions here, but it would be a good idea I think to have a list at some point of proven, trusted contributors where we can plot world domination without spamming everyone else.

I'm not sure I see the need for "yet another list"... I do think this list would be appropriate, and I don't necessarily see the need for limiting it to just the core contributors with commit access to the official repos.

Personally, I think that this list [i.e. the public developers list] is more appropriate than the core committers list, because there's hardly anything confidential about someone wanting to understand the structure of the code. Rather, with other people reading in on the list, we're helping grow common understanding of the code structure without spending dedicated time to write documentation.

I'm just thinking about what might be sensitive that we would want to keep private, and the only thing I can think of might be security-related issues that we need to embargo until we have a fix -- maybe we should establish a private security list for that purpose, and a corresponding announcement-only list.

In the Subversion project - and many Apache projects - I know there's a list of big parties being maintained (Debian security team, Hosting providers, Consultancy firms, ...); people who can quickly act and reach a large number of the available installs without spreading the word about an upcoming security fix publicly. If there are any parties who run large numbers of LedgerSMB installs, then yes, I think we should do something similar.

Otherwise, with the github pull model already opening us up more -- nice to see some pull requests from outside the core -- I'm not seeing much reason to keep our conversations private. Maybe just move this list to ledgersmb.org and open it up to anyone who actually wants to discuss these issues...

At least while our community is so small! We could end up with more lists than active contributors ;-)

Right. More lists don't necessarily bring us more contributors. I think we should look really hard at what obstacles a beginning contributor or wannabe contributor runs into and aleviate those. My current thinking is that the volume of traffic on this list isn't the problem, safe it being too little.

[Erik writes:]

Conclusion: I'm wondering what we can do to get full public exposure and *not* get compete deception. (see the latest review of the project on SF's project front page for LSMB...)

I think the first step is to ask two questions:

1. Who can we help today effectively?

and

2. How should we pitch to them.

I think right now the answer to #1 is:

For companies that want to invest in free and open source software, we can provide a customizable platform.

Completely agreed here. We are not in a state where you can set up LSMB as a non-tech user and run off and be happy forever without at least *some* setup consultancy.

And so I am not opposed to pitching on FLOSS weekly. But I do think we need to prepare as a community and try to get the message right.

Agreed. But then the big question becomes: how do we explain that without selling ourselves short. Remember: everything stays on the web forever, so if we think we have a much better proposition in 6 months, we might be better off building our image 6 months from today with the broader market definition that we envision to be having at that time...
Well, in spite of all the warts, I think if we want the project to succeed we have to attract a broad base of users, developers, contributors, and should do the marketing at the same time as doing the work, not later. Seattle is a big startup community, and a huge number of them are "Stealth" -- it's in vogue to be secretive and mysterious about what you're working on. And I think that's just plain silly -- the only "stealth" startups I see succeeding are those that have virtually limitless funding -- the ones started up as a side project by an established enterprise. Otherwise developing the audience and user base is every bit as important as developing the codebase.

Fully agreed there. Then we get back to the original question: how do we communicate our current proposition *as well as our ambitions and targetted situation* effectively?

So we should start that now, not in 6 months. I do agree that we should clarify our vision, and set appropriate expectations from the start, so we get the right contributors who won't get pissed off now. But let's get at least that vision up on our website home page as quickly as we can work it out, and then get on the Floss Weekly schedule -- it'll probably get scheduled 2 or 3 months out, and we'll probably get mentions in all of the preceding shows as the date approaches.

Hmm. I'm not sure if our vision is unclear. What I do know is that we're not helping people getting started: there's hardly any documentation regarding code patterns we use and deem "good". There's also hardly any documentation regarding the "old code" of which we complain it's not transparent enough -- if people want to fix a bug in this code without completely rewriting it immediately, we'll need to provide that kind of documentation. We're not helping people getting started by indicating which parts should be easy to work on and which ones are considered harder. I could continue like that for a while :-)

My problem is: lets assume I have enough time the coming month to address a few of these issues -- I have no idea what I should be working on in terms of priority, in terms of where to put it (can people find it?), etc. How do we get this organized and - if efforts are already on-going which I may not know about - centralized.

As for where to centralize things: I think that anything that has to do with managing the community can be on the development list, with the exception of things that John already addressed that are required to stay private, such as pre-public-announcement discussion of security issues and pre-invitation discussion of the addition of new community members.

Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.

Robust and Flexible. No vendor lock-in.