Before you start writing software, have at least one
clear objective. You might call this a requirement, a
user story, or a specification. Give the developers a
target to shoot at. Otherwise, you will be swimming
upstream.
Prototypes and research give you a target, even though they aren't "formal" (by some definition) requirements.
Even producing the prototypes meant you probably had some objectives unless someone just typed something out one day entirely on a whim.
There is monopolistic/market manipulating behaviour going on - it's basically an oligopoly, and the barrier to entry into the mobile telecoms market (ie building your network) is only growing.
It is _amazingly_ expensive to start building a network.
There's about 4 vendors providing the gear needed for a large scale cell network. And they're not bothering talking to you unless you want to buy a lot of gear.
Then you need spectrum licenses. And since you're placing cell towers around, you're either going to rent rather expensive towers, or build your own, which requires permits and a lot of civil engineering.
It's a bit easier today, as there's more infrastructure in place - but you may very well end up needing to provide the network backhaul from a cell site, somehow get power lines to the cell site. And that cell site might need backup power, which require refueling and maintenance every now and then, you might need to build a small cabin to house the gear, and you might need to hire helicopters to fly in that gear.
When you get this far, you need a marketing department, so people can actually buy connectivity, refill cards, sim card distribution, and similar.
At some point you might need roaming agreements with others as well. If your're lucky the government requires you to have agreements with other operators in your country - important enough, cause unless you have greate coverage people won't bother if they can't use their phone. If you want your customers to use their phone while abroad, you get to make individual roaming agreements with all those other operators in other countries.
Grassroots sounds nice, but the hard work isn't writing the code - it's convincing those within government that user-centered services and open source are the way to go. I believe that this can only be achieved given a strong mandate, from within government itself.
Based on my experience in Italy - with my former employer we did some work with public administrations - my idea would be to start with cash-strapped local administrations and the most forward-looking of their suppliers.
These administrations basically have all the same needs, but many of them are served by small suppliers that always have to reinvent the wheel with some half-cooked proprietary solution.
If there was a well-designed, free open source GPL solution that already coverered 80% of the requirements, that could give a competitive advantage to those who based their offer on that solution. They would then compete only on service and customization.
As I see it, the problem would be mostly to kickstart the development of that GPL platform - no for-profit company could do that, it would be against their interest. But if a big and committed enough community started it, then it could create a positive feedback loop that could be very difficult to stop. IMHO this could be a field where the GPL could give its best (I'm not pasdaran of the GPL, and released my own little open source contributions as MIT).
Well, the GOV.UK code (https://www.github.com/alphagov) is your 80% (or more likely higher) solution. It's based around many micro-services that integrate over HTTP, so it's extremely extensible.
However, even with the software being perfect, you still have very high barriers of entry to overcome:
1) the local authority is likely to be locked into a 5- or 10-year contract with its current supplier
2) the choice of supplier is rarely (if ever) based on technical excellence/licensing strategy. Usually the people commissioning the IT don't tend to have a very deep understanding of technology, licensing, etc
If the gov.uk code covers a lot of the requirements for local administrations in continental EU, that's terrific. Honestly, for now I'm just thinking about this idea, but I don't have the time to study it.
As for the contracts, at least in Italy I've never seen one longer than 3 years, and practically by law the deciding factor is, most of the time, price (which is a big problem on its own).
Well ok, the GOV.UK is the 80+% solution for publishing; transactions is another matter, although hopefully when the Digital by Default Service Standard starts kicking in (specifically the open source provision: https://www.gov.uk/service-manual/digital-by-default#criteri...) then a lot of code around transactions should start appearing.
> I even considered not submitting this comment, for fear of anyone misunderstanding or taking this the wrong way, and the inevitable "open source is a responsibility" responses.
I'm glad that you did, thank you for taking the time to respond.
> The thing is, you're actually implying more than you're saying. What you really mean is, "You could always have the courtesy to acknowledge the bug or PR I’ve submitted as soon as I submit it."
While I've definitely been guilty of impatience in the past, now I try to measure the response against some kind of "OSS time", which is a lot more forgiving. I appreciate that people are likely to be busy, or away with their kids in Hawaii for the past two weeks.
Having said that...
> The maintainer may just be really busy this month. Or maybe they've been really busy for 6 months.
I think one month is a bit long to have to wait for a response. 6 months: most certainly too long. In those cases, the "pull request hack" [1] may be the way forward.
> I think one month is a bit long to have to wait for a response.
You're certainly entitled to that opinion, but the amount of time that is "acceptable" is completely subjective and relative. Holding someone else to your own arbitrary standards of acceptability is exactly what I'm referring to when I say these sort of complaints usually ignore the possibility that someone else's life is different than one's own.
I can see how a month would seem like a long time, it used to seem like a long time for me too. But for someone running a company, someone with a crazy family life, someone maintaining several projects, someone getting married or divorced or having kids, someone buying a house or selling a house or moving, someone in school, someone having financial troubles, etc., etc.; a month can be a blink of an eye. You, of course, are welcome to your opinion. I try to avoid holding people for whom I know nothing about to my own arbitrary standards, and try to withhold indignation if they don't live up to them. I admit it takes effort; I often find myself doing exactly that. I just have to remind myself that I can't really know them to the extent that I know myself, and thus it's not always fair to expect that their situation lends itself to meeting my standards.
EDIT: All that being said, I think the pull request hack could be a potential solution. It does however bring its own potential problems. You're basically putting your reputation in someone else's hands, whom you don't know. Of course that may be preferable to what you're doing to your reputation by taking a long time to respond to requests. I'm certainly considering it for a couple projects.
> Holding someone else to your own arbitrary standards of acceptability is exactly what I'm referring to when I say these sort of complaints usually ignore the possibility that someone else's life is different than one's own.
I agree with the spirit with what you're saying, this is indeed all opinion.
I see it like this; if you're walking along and say "hi" to your neighbour, he doesn't have to say "hi" back, but it's nice, 'sall :)
I agree. I certainly don't feel like we're arguing, just adding more pieces to both sides of the puzzle.
I guess what I'm saying is, if the neighbor doesn't say "hi" back, it might be for reasons you haven't considered, and it might not be as simple as asking them to just say "hi" back.
Context and scale are extremely relevant here. I can say "hi" to every stranger I pass while hiking on a remote forest trail. However, I cannot say "hi" to everyone I pass walking down the street in Manhattan. Snubbing the passerby in the forest would feel rude. Ignoring the passerby in the city is normal.
I definitely didn't want to imply that "you should merge any ol' crap".
I was commenting more on how maintainers communicate (or don't communicate) their feedback. I see no problem with saying "please add tests", or "don't break the existing tests". Some of that can be managed automatically with the likes of Travis, other stuff like "I only accept code that's coffeescript" can be mentioned in the CONTRIBUTING file, and your reply to the PR can just point to the rules. I don't have a problem with any of those cases; it's stony silence that gets me.
