Swarmops is approaching launch. This is the back-end software that allowed the Swedish Pirate Party to beat its competition using less than one percent of their budget, but now generalized for any organization’s use – business or nonprofit. It’s also the only software in existence to do bitcoin-native automated accounting and cashflow.
I believe that adding shiny happy blinking gadgets isn’t the crucial thing to make an operation competitive: instead, it’s removing the old painful obstacles that makes the big difference to competitiveness.
When I founded the Swedish Pirate Party, I had a simple philosophy: the many people shouldn’t have to deal with pain points at all. If there was anything boring and painful, it would be touched by as few people as possible. There was no organizational software that met this simple principle – instead, all back-end software seemed to require the many people to do as much work as possible for the accountant. Just creating an expense report was usually a nightmare.
So I started writing the back-end software for the Swedish Pirate Party myself. It turned out to be absolutely instrumental. (To reclaim an expense in Swarmops, you upload a receipt, fill in its amount and what it’s for, and that’s it.)
Along the same vein, I wanted decisions to be made as far out to the edges as possible, where the most tactical information was. As long as everybody has bought into the overall vision, the best decisions are made at the information sources. There was no software for this either. Swarmops does that too.
This software turned out to be absolutely instrumental in allowing the Swedish Pirate Party to win in 2009, despite having less than 1% of the budget of the competition. The philosophy – in management, organization, and software – had literally made the organization two orders of magnitude more cost-efficient.
Lawrence Lessig famously stated that Code is Law. I’d say it is much more than that: any organization is confined to what its internal processes can handle. The processes determine what must be done, and what can’t be done. And those organization processes are usually determined by very old-fashioned back-office software. Conversely, those who don’t have the painful back-end accounting and bookkeeping can’t do simple but powerful things like delegate budget responsibility or refund simple expenses.
I set out to change that.
Writing accounting and activist/personnel software sure doesn’t sound very sexy. Then again, neither does expense reporting. Despite that, Expensify was a company that set out to remove that pain point from organizations with the simple mission of making expense reports not suck. It’s now a dominant player.
There are many of these old problems lying around that we just don’t consider because we take the pain they bring for granted, and get all giddy when we see new shiny things instead. But removing that pain from an organization is what gives it speed and agility – not to mention let the energy go toward the organization’s mission instead of to old-fashioned pain.
(There was even an insanely successful Kickstarter campaign for more efficient shoelaces the other month. Imagine that. Anybody who says there aren’t any old pain points to solve is simply wrong.)
[youtube h0bvdFwY2Ls]
So what does Swarmops do?
Swarmops enables tens of thousands of people in an organization to cooperate with little friction, and is geographically aware to boot, so you always have local points of contact. Those people can be volunteers, members, whatever. “Participants.”
Swarmops decentralizes authority to the edges of an organization, where the best decision-making information is available.
Swarmops makes accounting not suck by automating it and doing it all in the hidden background. It was never rocket science anyway.
Swarmops makes an organization transparent by providing real-time data on its health to everybody in the organization. No more waiting several weeks for the quarterly statement. This is realtime stuff.
Swarmops does bitcoin-native cashflow on full auto.
If this sounds familiar and I’ve spoken about some of it before, it’s because I have. It’s the administration system for the Swedish Pirate Party, which was absolutely crucial in allowing us to decentralize to the point where we became the biggest party in the most coveted demographic, despite having less than 1% of the competition’s budget. At that point, it was known as PirateWeb, and was a strictly internal tool.
Some two years ago, I started generalizing it under the name Activizr. However, I realized that in order to make it usable, there would need to be a whole lot of back-end work – installability, maintainability, getting rid of proprietary packages – before that could happen. That’s what I’ve been doing since I first mentioned Activizr, now Swarmops. Now it installs with a standard apt-get, and loads all its data as needed.
But I can’t do this alone.
I’ve been taking this to baseline production level. Now, this needs to scale up if it is to complete and go from good to great.
It’s getting decent attention, but development is going too slow, and Swarmops needs a richer skill set. In particular, I’m not a UX engineer and usability is absolutely key to take a system like this from good to great. (As is mobility, but that’s on the roadmap.)
There’s a crowdfunding going that will enable Swarmops to go from good to great. And yes, of course there are perks for contributing.
Do take a look at the development sandbox to get a feel for it! All the data there is reset every night, so play away. The Swarmops code is also available on Github, and needless to say, it’s public domain.
At this point, Swarmops needs:
- Pilot installations. There are a few organizations wanting to take Swarmops for a test drive, and more are welcome. It needs exposure to the famous “real-world conditions”.
- Developers developers developers. The code is on Github and any contributions are welcome. Most development is in JavaScript and jQuery, with minor additions to a C# backend.
- Funding! The case for going from good to great involves getting some full-time support staff, and design! Do visit the ongoing crowdfunding and consider pitching in?
- Design and UX. Going from good to great, or even from useful to great, requires design and usability skills in amounts that Swarmops has not had access to.
Do you want to be a part of this? There’s a group on Facebook named Swarmops Developers – drop on by!
You could see Swarmops as the software counterpart to the book Swarmwise.
Photo by Anna Jumped from the German Piratenpartei’s General Assembly.
This sounds all and good, one nagging detail though;
How come you took the brain-dead decision to use C# as your language-of-choice on the backend? C# is in many ways still a walled garden and basicly unfit to everything but the world of Windows and XBox. On Linux it requires the installation of a software stack not commonly found (e.g. mono). In light of this, it might have been a better choice to go with Python, Java or maybe if you’re insane enough, PHP.
Granted, there are poorer choices out there, Visual Basic springs to mind. The technical aspects of C# may make it worth it to install yet another bug-ridden platform alongside Java, PHP and Python. Still, the fact that it is in C# makes me less interested in checking out the software.
The use of C# is not exactly a deal-breaker, but… How should I put it? It’s like you’ve been dating this AMAZING woman for the past few weeks and then you realise she has a fetish for, say, taking a dump in public places with people, e.g. you, watching. Not exactly a deal-breaker, but definitely off-putting… 🙁
Yes, I feel exactly the same way about that. I was pretty excited when I saw the announcement of Swarmops on Rick’s Twitter but when I noticed the language statistics on GitHub, my head just exploded. That bit about “90% of development happening in JavaScript” in project readme on GitHub just adds insult to injury for me.
BTW, the IT department of PPCZ has already looked at Swarmops and agreed unanimously that they won’t touch it with a 10 foot pole. The choice of C# for Swarmops backend will be the single biggest obstacle to both adoption by its target audience and attracting new developers.
Ah, but that’s the case. The backend is solid. The development takes place on the frontend, as you can also tell from the commit history (don’t know if and how you can see that, now that I think about it), so about 90% of the development cycles are spent writing JavaScript and jQuery front-end stuff.
Also, do you have a technical reason to discard a piece of software like that merely on the basis of its source language? C# has been one of the top five languages for the past decade, and one of the top two strongly-typed and leak-resistant languages for the past decade. It’s not exactly unused, nor uncommon.
When that much development happens exclusively in JavaScript, it basically means that the website is completely unusable when you turn JavaScript off. I *HATE* websites like that. JavaScript is supposed to be an extra convenience layer on top of something that works well enough without it.
Yes, I do. The technical reason is that there is a single commercial entity which owns the source language and can kill it at any point in the future. Microsoft has already done that to several languages in the past: FoxPro, “classic” Visual Basic and ASP and probably some other more obscure languages as well. The future of Mono also depends on the outcome of Oracle’s copyright lawsuit against Google over Java APIs.
In other words, I refuse to waste time on building a skill set which could become obsolete pretty much overnight. That also applies to Java BTW. And if I don’t have the necessary skills to fix bugs in something, running it on a server as a public network service is out of the question.
And as for popularity of C#: Sure, it’s popular in the Windows world because Microsoft pushes .NET everywhere. But adoption on Linux is negligible, most likely for the reasons stated above and also because Linux has lots of other good languages that are very well integrated into the base system. For example, on Gentoo, only 75 packages out of over 17000 have any dependency on Mono (including just optional dependencies).
I’m sorry, but this is just factually incorrect.
First, the requirements for a complex huge system like this means that strong typing and leak-resistant environments are more than desirable, they’re practically a requirement to minimize risk. At the time this started development, that left two choices – C# or Java.
Java was, and is, awful on Windows _and_ as runtime on GNU/Linux. Tomcat is horrible.
But as for the Mono stack not being common, that’s just plain wrong. Looking at server deployments, about two-thirds of GNU/Linux servers today are either Debian or Ubuntu servers (with the third third being CentOS and then a bunch of minor distros). Swarmops installs straight from the stock distro and gets its dependencies with apt-get install on the two most common server deployments.
I do agree that Mono has its share of problems, mostly very very subtle bugs that differ in behavior from other .Net implementations, but MS opening up their own stack in 2015 is going to mitigate that.
Also, a major factor in choosing C# was that it seemed future proof in terms of talent supply, which was correct. It has remained one of the five most popular languages every year for the past decade.
Just to let you know a little of my thinking. PHP and other dynamically-typed languages would not have been an option for a system that needs to be as reliable as this.
Cheers,
Rick
PS: Some complain about C# saying “but it was developed at Microsoft!”. Thanks for not bringing that up, that means I won’t have to counter with all the other languages that were developed at various companies 🙂
Resource leaks are a complete non-issue on the web. Properly configured Apache server runs multiple worker processes and periodically recycles them specifically to clean up any leaks.
Strong typing, especially combined with compile-time type checks, is a nice feature to have. But it’s not a substitute for thorough unit tests with code coverage analysis which renders the benefits of strong typing moot. And since Swarmops is supposed to do accounting on very large amounts of money, you have to do proper unit testing anyway.
Here are some interesting statistics about language usage on GitHub: http://githut.info/ The open source community around Python is about 4 times larger than around C#. PHP is 3 times larger than C#. Python is probably the best choice because it’s also technically superior to PHP.
(Note: I didn’t have time to learn Python yet and I use PHP for web development. But PHP has terrible security track record which matters a lot for this kind of system.)
This is incorrect for three reasons.
First, you’re assuming that there’s only a front-end process. Swarmops has a front-end interface and back-end daemons. Of course leaks are going to be relevant on the backend, where the actual work happens.
Second, memory managed environments don’t just prevent leaks. They also prevent buffer overruns, which is an absolutely critical attack surface for web frontends.
Third, accepting memory leaks with the argument that “the environment will take care of that anyway” is horrible code hygiene. It may work for a while, until you’re deployed in an environment (like fastCGI) which does NOT recycle its threads regularly.
Yes, I was speifically referring to catching type- and misspell-errors at build time, rather than at runtime (or at all).
But no QA is a substitute for another QA. And there are plenty of errors which a unit test WON’T catch, since it tests a selection of input/output cases rather than the underlying fundamental semantics.
To give you one tangible example: implicit casts. Converting a string to a datetime might work perfectly in all unit testing. Then, somebody installs the software in a different locale and/or culture, which has a different datetime representation. BOOM, transactions get timestamped wrongly. This is caught by strong typing, but not by unit testing (even when cleared by code coverage metrics).
Github did not exist when the decisions to build Swarmops was made, for perspective. Despite that, C# has remained one of the top environments since then.
I’m not. Is there any reason to keep those daemons running 24/7 instead of making them, say, an hourly cron job? Or maybe launching them as needed through the web interface? Because you see, this is a really cheap design choice that can improve reliability by a few orders of magnitude.
FYI, both Python and PHP are also memory managed environments so we’re talking only about leaks and buffer overruns that would be present in Mono itself or the Python/PHP interpreter. But then again, you can create memory leaks even in managed environments: http://thedailywtf.com/articles/Visionary-Leak
Recycling threads does not clean up any resource leaks. You have to shut down the entire process. Which BTW happens even in FastCGI environment. By default, Apache restarts idle FCGI handler processes which have been running for more than an hour.
And I never meant it as an excuse for bad code hygiene. I’m simply saying that you need to practice good code hygiene anyway for much more important reasons so this will be taken care of regardless of language choice.
That’s actually called “static typing”. Strong typing means that the language doesn’t make aggressive implicit type casting (e.g. implicit string to number casts etc.). Statically typed languages give you compile-time error, dynamically typed languages will throw exception or otherwise barf at runtime.
Well, I don’t know any programming language that would convert strings to dates by default (other than SQL, but if you pass date strings straight to SQL, you’re bypassing all type checks anyway). But if we take decimal points in numbers as an example, Python is strongly typed so it won’t let you do arithmetic operations on strings. You have to convert the string explicitly. PHP will silently convert it to number, which is still slightly better than JavaScript’s 1+1=11.
Let me clarify what I mean with commonly available; since it is a webservice, I assume that the service can be run on a standard web server without the need to install additional software.
That basicly leaves three commonly installed environments – php, python, and java. Sure mono is one apt-get away but is it really worth it to install yet another software stack and thus increase the attack surface of the server? And what If you du not have root on that server then what?
C# is unfortunately not a language i can reccomend in a linux environments at the moment though that may change in the future
..
I don’t quite see why you hate C# that much. Especially since MS is starting to cooperate with mono devs to tackle the last portability issues (which is in their best interest anyway, so no reason to suspect a PR move).
Sure, I prefer plain C++ for my own projects. But these don’t have a codebase too large to be known by any single person and a decentralized team of coders working on it, and they don’t have to handle finances reliably on the Internet. What plain C++ really has going for it are IMHO three things:
– It’s damn fast and efficient (which is at best a secondary concern for the back-end and utterly pointless for the front-end)
– You can throw in bits of C and even ASM to make the system do precisely what you want (a non-issue unless you’re writing device drivers, OSes, heavily optimized stuff or anything else close to the metal)
– It’s supported by even the most arcane hardware combinations out there (another non-issue; Linux, BSD and possibly Windows are enough)
Reliability and stability are king here, and this makes C# a pretty solid choice with Java being the only true contender.
Personally, I’d also consider functional languages for exactly these reasons. In these, whole classes of errors are almost impossible to make (even without strong typing), and functions can be checked “by sight” for correctness because the syntax is very clear and annoying gotchas like side-effects and internal state are removed (unless you make them explicit via monads).
My first suggestion would be F# if you want to stay inside .net, even though I personally prefer Haskell (and to a lesser extent Erlang). However, I do admit that it’s hard to find good coders in these languages, and they take some getting used to if you come from an imperative (or OO) school of thought.
LOL when I read this! The fairly small company I work for recently bought a system for the accounting and such for several hundred thousands Swedish Crowns. And a monthly fee of several, maybe tens of thousands, calculated by the number of employees if I’m not mistaken.
It also handles the payments for the working hours, everyone logs in in the morning and out in the afternoon and it automatically subtracts lunch and coffee breaks, and has options for overtime and vacation and such. Does your program have that function?
If this becomes a hit it will be good advertisement for you and the Pirate Party!
Not all of that, not yet, but it’s fairly trivial to add. The problem is making it generic enough so that you’re not locking in the payroll processing to the rules of any one specific country.
Swarmops does do payroll processing. It pays my own salary and taxes (running on the think-tank that is my formal employer). So what you’re asking for is not completely unthinkable – it already does part of it, but for monthly salaried people and not hourly wages (yet).
On the company I work the pay is per month, but with a “komptid”, a time bank of sorts, I don’t know what it is called in English. Full monthly pay if you work less but have hours left since previous overtime, otherwise less paid. But as you say, the more adaptable the program is, the better. But of course keeping it easy to set up and use.
Unfortunaltely I am quite sure the rules for parties e.g. in germany do not allow such a process or put it as a big liability on the legally required heads.
And I am quite sure that is not completely unintentional.
———
How hard would it be to implement other (mor then one) cryptocoins?
I am asking especially for gridcoin, if it depends on type of coin.
I can’t see such an uncommon altcoin in the stock distribution, but you could conceivably do that with a plugin to external asset tracking once those hooks are in place.
[…] Swarmops Approaching Launch. Want To Be Part Of It? Fund It Maybe? […]
❤ You are so great it hurts my head. Thanks for everything you do & write, seriously. I wish I had more to contribute, or that I could program/develop, because I’d jump on this in a heartbeat. I hope others that are able will find their way to it & realize the potential & want to help.
Keep doing what you do & never stop. With people like you in the world, there’s almost hope for it not falling into chaos, oblivion & complete, utter insanity of the highest degree, even if we are teetering on the edge. ….