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...
This list looks very appropriate. I would add:
> 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 difficulty4. For accounting applications, people expect to be able to load their bank records, not only for reconciliation, but also for automatic posting
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'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).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
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.
We are still hitting more bugs in Starman than running directly under Apache -- will try to capture more of those to report.
+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.
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?).
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.
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.
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...
> 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?
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
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.
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.
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 ;-)
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.
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?and2. 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...
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.
------------------------------------------------------------------------------ Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical & virtual servers, alerts via email & sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
_______________________________________________ Ledger-smb-devel mailing list ..hidden.. https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel